Thank you all for the suggestions and help, in the last week I have been
playing with as many variables as I can think of from individual players
to groups to synchronisation and updating software where possible and
necessary.
In summary I can find no consistent reason for the occurrence it still
comeng wrote:
> Subsequent to above is there anyway I can monitor the state/status of
> synchronsiation between players to see if I can find and fix the problem
> child
> Maybe this should be a new thread?
Phillipe has provided 'an explanation here'
(https://forums.slimdevices.com/showthread.ph
Subsequent to above is there anyway I can monitor the state/status of
synchronsiation between players to see if I can find and fix the problem
child
Maybe this should be a new thread?
comeng's Profile: http://forums.slimde
Had reached the conclusion there was some disparity on the timings
between the stream and the players.
first thought was to increase Min Synch adjustment to 5/6 seconds but
max allowed appears to be 1000 ms
Have been thinking about this and looking at previous post, and at
screen
32863
and concl
Would the setting here (and maybe the box below) have any relevance ?
32856
ronnie
+---+
|Filename: sync.png |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=
comeng wrote:
> OK
>
> As usual spoke too soon had two incidents today at 14:08 and 15:14 I
> attach a log file
> The incident occurred as follows
> Sound stops
> On the player section (top 25% of right hand half of the screen) the
> "running time" counter keeps counting up for a few seconds e
philippe_44 wrote:
>
>
> Re HTTP 1.1 and DNS, I've made some changes recently on my CPlus and YT
> plugin related to that. The Cplus needs a socks proxy to work and doing
> HTTPS + socks with over dash/mpd was just way to slow, with a DNS query
> for each chunk that was leading to 2 or 3 redir
expectingtofly wrote:
> > bpa wrote:
> > Is the plugin not using HTTP 1.1 for DASH chunks where there is only one
> > TCP connection for multiple GETs - this hugely reduces the load on
> > processor (i.e. only one DNS call for a live stream, one TCP open per
> > live stream - not per chunk) a
comeng wrote:
> I am feeling particularly thick today so I am trying to get a simplistic
> view on this situation
> My thinking (which maybe wrong) was the LMS server says to each player
> here is what you are going to play, then says start now. After which the
> server steps back and allows the
I am feeling particularly thick today so I am trying to get a simplistic
view on this situation
My thinking (which maybe wrong) was the LMS server says to each player
here is what you are going to play, then says start now. After which the
server steps back and allows the players to do the busine
slartibartfast wrote:
> I just noticed 3 or 4 "dropouts" in a row on Radio 2 live.
>
> Sent from my Pixel 3a using Tapatalk
Not sure if this is related but this entry in the server log must have
been around the time of the drop outs
Code:
[21-01-05 10:45:57.6426] Plu
comeng wrote:
> Ok my system consists of one Pi 3 running PcP LMS and 3 Pi 2's all
> running PcP and Squeezelite these 3 being synchronised on Sunday and
> Monday I ran for extended periods with this configuration with no loss
> of sound output on either listen live or listen again.
> Today I ha
Ok my system consists of one Pi 3 running PcP LMS and 3 Pi 2's all
running PcP and Squeezelite these 3 being synchronised on Sunday and
Monday I ran for extended periods with this configuration with no loss
of sound output on either listen live or listen again.
Today I have had the 2 (now 3) inci
comeng wrote:
> OK
>
> As usual spoke too soon had two incidents today at 14:08 and 15:14 I
> attach a log file
> The incident occurred as follows
> Sound stops
> On the player section (top 25% of right hand half of the screen) the
> "running time" counter keeps counting up for a few seconds e
OK
As usual spoke too soon had two incidents today at 14:08 and 15:14 I
attach a log file
The incident occurred as follows
Sound stops
On the player section (top 25% of right hand half of the screen) the
"running time" counter keeps counting up for a few seconds estimate 5/6
then jumps back to
comeng wrote:
> OK
>
> So done various tests as my base I ran 8 hours solid music streaming
> from my NAS to the 3 synchronised Raspberry Pi's and as expected I got
> no drop outs or any other issues so internal networks and devices appear
> to be functioning correctly, then did the same with L
bpa wrote:
> From sometime in 2019 LMS SimpleAsynchHTTP got HTTP 1.1/ support ( I
> think via keep-alive)
>
>
That's good to hear, as I suspect I BBC Sounds will need to switch to
https streaming at some point, which will require HTTP 1.1, I believe,
to stop the TLS negotiation every time.
expectingtofly wrote:
> It is just using the standard LMS SimpleAsyncHTTP. I see no reason to
> change that part (it shares the same dash processing logic as Phillipe's
> You tube plugin). I've no idea if this standard LMS operation sets the
> protocol to http 1.1, but I doubt it.
>
> I'm s
bpa wrote:
> Is the plugin not using HTTP 1.1 for DASH chunks where there is only one
> TCP connection for multiple GETs - this hugely reduces the load on
> processor (i.e. only one DNS call for a live stream, one TCP open per
> live stream - not per chunk) and packets response times.[/QUOTE
>
expectingtofly wrote:
> but the way that the bbc streams in chunks with a new connection every 6
> seconds it becomes very visible.
Is the plugin not using HTTP 1.1 for DASH chunks where there is only one
TCP connection for multiple GETs - this hugely reduces the load on
processor (i.e. only
comeng wrote:
> OK
>
> So what has changed and the only thing I can identify is upgrading to
> Sounds 2.9.1.
> Thank you for help and as always in such circumstances I am frustrated
> that I cannot come up with an explanation or put my finger on one issue
> that could be further investigated.
>
comeng wrote:
> Thank you for help and as always in such circumstances I am frustrated
> that I cannot come up with an explanation or put my finger on one issue
> that could be further investigated.
I feeel the root of "drop outs" was these "long delay" packets. I think
it is has virtually dis
OK
So done various tests as my base I ran 8 hours solid music streaming
from my NAS to the 3 synchronised Raspberry Pi's and as expected I got
no drop outs or any other issues so internal networks and devices appear
to be functioning correctly, then did the same with Listen Again and had
no issu
comeng wrote:
> Ok I am going to a take a step back and enjoy the New Year as we enter
> it
>
> I need to repeat all the steps I have previously taken and leave it
> running for sometime.
>
> I have not had a drop out on Listen Again since I upgraded the plugin to
> 2.9.1 (I think)
>
> I will
Ok I am going to a take a step back and enjoy the New Year as we enter
it
I need to repeat all the steps I have previously taken and leave it
running for sometime.
I have not had a drop out on Listen Again since I upgraded the plugin to
2.9.1 (I think)
I will get back you all soon
Enjoy the 1
comeng wrote:
> I set the logging as Internet Radio is there a better option, with it
> set at that you would just get more of same
Those logging options are really only for standard HTTP streams. So it
is triggering for each chunk, each of which is a GET which requires a
DNS lookup. Each chun
OK forget Proxy that was me trying to answer 2 questions at once I
meant yes it is set to Proxy and I cannot remember why or where it came
from.
I set the logging as Internet Radio is there a better option, with it
set at that you would just get more of same
Reseting Logging
In the list of butt
Did you enable any logging for these "resolve" message to appear in the
log ?
Is this an edited log file with message or text removed ? if so then
please post unedited log file (zip & attach) as sometime the message
that are missing are important.
What do you mean "Yes I have proxy set because
Appear to have exceeded image nos > 10 so second email
Live
These seem to have a 6 second gap between calls
[20-12-31 17:02:14.7838] Slim::Networking::Async::DNS::resolve (43)
Using cached DNS response 176.255.218.225 for
as-dash-uk-live.akamaized.net
[20-12-31 17:02:21.3740] Slim::Networking::A
Sorry for delayed response
Now running Plugin ver 2.9.1
Looking at the logs there seems to be a timing difference between Live
and Non Live feeds see below not sure if this is significant
Non Live (Listen Again)
These can have 2,3,4 calls per second
[20-12-31 16:58:39.6030] Slim::Networking::
bpa wrote:
> "Direct" means a stream that a player can play direct (i.e. audio stream
> goes straight to player, no LMS audio involvement - stream metadata is
> sent back from player to LMS to display).
> The setting only applies to player which are not synced and the player
> can play direct (e.
d6jg wrote:
> Didnt know that. Thanks
"Direct" means a stream that a player can play direct (i.e. audio stream
goes straight to player, no LMS audio involvement - stream metadata is
sent back from player to LMS to display).
The setting only applies to player which are not synced and the player
bpa wrote:
> That setting makes no difference with BBC Sounds or BBCiPlayer or any
> plugin which is not a simple HTTP streams (e.g. HLS, DASH)
Didnt know that. Thanks
VB2.4[/B] STORAGE *QNAP TS419P (NFS)
[B]Living Room* - Joggler & SB3 -> Onkyo TXNR686 -> Celestion F20s
*Office* - Joggler
d6jg wrote:
> Are your players set to Direct or Proxied Streaming?
That setting makes no difference with BBC Sounds or BBCiPlayer or any
plugin which is not a simple HTTP streams (e.g. HLS)
bpa's Profile: http://forums.sl
Are your players set to Direct or Proxied Streaming?
VB2.4[/B] STORAGE *QNAP TS419P (NFS)
[B]Living Room* - Joggler & SB3 -> Onkyo TXNR686 -> Celestion F20s
*Office* - Joggler & Pi3 -> Denon RCD N8 -> Celestion F10s
*Dining Room* -> SB Boom
*Kitchen* -> UE Radio (upgraded to SB Radio)
*Bed
comeng wrote:
> Hi
>
> Live in UK, no VPN (Sky Broadband)
> I am most interested in Radio 2 Live so not not really explored others
> yet
> Server on static IP, others assigned by router
> When the dropout occurs program run time keeps incrementing with no
> sound, when connection remade timer j
Part 2
DACs
HiFi uses Hifiberry Digi Amp
Soundbar uses HiFiberry optical out
Samung is HDMI
All file formats as installed when installed/updated LMS so AAC is
native
Server Logs will follow just rebooted everything
Phil
c
Hi
Live in UK, no VPN (Sky Broadband)
I am most interested in Radio 2 Live so not not really explored others
yet
Server on static IP, others assigned by router
When the dropout occurs program run time keeps incrementing with no
sound, when connection remade timer jumps back to the point at which
Always good to detail the version you're running. If not the latest
version then it is hardder to give advice.
Are you using any special DACs or using any non default LMS settings
(e.g. disabling AAC native)
Are you in the UK or outside UK. If outside the UK are you using a VPN
?
More specif
Hi
I am having a problems with the BBC Sounds in terms of dropping out
fairly often.
My system includes a Pi 3 as PcP based LMS Server only hardwired and 3
Pi 2's all wifi various output options all using PcP have happily run
for a number of years streaming music from my NAS, did use BBC Iplayer
40 matches
Mail list logo
