Announce: CastBridge = integrate Chromecast players with LMS (squeeze2cast)

[ian_heys]

and so on until in about 6 secs the URLS is readdy but then DASH player will move onto next URL of next segment which is not ready and so process will repeat.

I did see progress clock continually cycling through the last few seconds of the program after it went silent.

[philippe_44]

About the Get - normally the GET would either return with data or stay open until source (e.g. BBC) has data to send - either way there is a gap to allow other things to happen. With DASH URLs are allocated sequentially (unlike HLS where an updated playlist has to be fetched) so my player creates the next URL to become available but if player is very demanding (I need to look at squeezelite to see how it handles the thresholds) then URL is not ready and the GET is returned immeidately by BBC with a 404 but becuase player is aking for more data - another GET is scheduled asap so same invalid but it too will return in millisecs and so on until in about 6 secs the URLS is readdy but then DASH player will move onto next URL of next segment which is not ready and so process will repeat.

okay, got it. About squeezelite, it has a 3 buffers, one for streaming, one for decoding and one for outputting to the sound card. Each buffer is managed by a different thread. They work obviously in cascade flow control and the stream thread does not read the socket if the stream buffer is full. In my bridges, I only use the stream buffer but it is immediately flushed to a file (assuming the file size is below the set limit if any). That file serves as a source for the GET of the UPnP/CCA player.

[bpa]

I did see progress clock continually cycling through the last few seconds of the program after it went silent.

The WebGUI clock "ticking" as a measure is not indicative of anything but when there are sudden jumps forward or backwards - it means the server has done some action.

[bpa]

okay, got it. About squeezelite, it has a 3 buffers, one for streaming, one for decoding and one for outputting to the sound card. Each buffer is managed by a different thread. They work obviously in cascade flow control and the stream thread does not read the socket if the stream buffer is full. In my bridges, I only use the stream buffer but it is immediately flushed to a file (assuming the file size is below the set limit if any). That file serves as a source for the GET of the UPnP/CCA player.

I know squeezelite and understand how it works - I need to understand how it has been modfied for castbridge. I then need to think things through For exmaple If I introduce a delay in the plugin - it mightn't help if the player keeps asking for data it will soon catch up again and back to same problem. I need to reproduce the problem and then look at logs to understand BBC, LMS and player as a system not as pieces.

[philippe_44]

I know squeezelite and understand how it works - I need to understand how it has been modfied for castbridge. I then need to think things through For exmaple If I introduce a delay in the plugin - it mightn't help if the player keeps asking for data it will soon catch up again and back to same problem. I need to reproduce the problem and then look at logs to understand BBC, LMS and player as a system not as pieces.

Sorry, was not trying to be pedantic

So my changes with regards to flow control is then mainly what I described before. The stream process is unchanged except to make it multi-threadable. But as the streambuf is flushed almost immediately, it keeps demanding more data to LMS

[oyvindo]

hmmm ... not sure. You might have to run it from another place or run it as root at least for test

I finally made it run on my NAS using PuTTY console and the command exec ./squeeze2cast-armv5-static
It now plays just fine, but I have a PuTTY window which continuously spews out info, and it refuses to follow the playlist. I have to start the next song manually. It plays only a single track at a time.
Also, there is no albumart showing on my TV screen. There's just a black square with a progress bar in the base and the text [LMS to UPnP] followed by [no artist] and [no album]
But where do I go from here?

[philippe_44]

I finally made it run on my NAS using PuTTY console and the command exec ./squeeze2cast-armv5-static
It now plays just fine, but I have a PuTTY window which continuously spews out info, and it refuses to follow the playlist. I have to start the next song manually. It plays only a single track at a time.
Also, there is no albumart showing on my TV screen. There's just a black square with a progress bar in the base and the text [LMS to UPnP] followed by [no artist] and [no album]
But where do I go from here?

Do you have a password set on LMS ? On the "next track", does it do the same when you run it in Windows. Other than that, you can rename the squeeze2cast-armv5-static to squeeze2cast-armv5 an copy it in /var/lib/squeezecenter/Cache/Installed Plugins/Plugins/CastBridge/Bin (please adjust the exact path as I'm typing that from memory). Then you can manage everything from the LMS webGUI ... normally

[oyvindo]

Yes, I do gave a password on my LMS as it is available externally. Is that a problem?

Sent from my SM-G900F using Tapatalk

[philippe_44]

Yes, I do gave a password on my LMS as it is available externally. Is that a problem?

Sent from my SM-G900F using Tapatalk

Yes, my bridges will not be able to get metadata if LMS has a password. A lot of other features are awfully degraded. As an advice, I'm not sure you want to let your LMS accessible from the outside. The password protection is pretty weak, I think. If you want outside access, I would rather have a proper SSH access to my own network and rely on that piece for security, not on LMS password

[oyvindo]

Yes, my bridges will not be able to get metadata if LMS has a password. A lot of other features are awfully degraded. As an advice, I'm not sure you want to let your LMS accessible from the outside. The password protection is pretty weak, I think. If you want outside access, I would rather have a proper SSH access to my own network and rely on that piece for security, not on LMS password

I agree of course, but for now usernameassword is better than nothing and I haven't been able to figure out how to configure SHH through the router given to me by my cable provider. So let's leave it at that for a while. Maybe you'll figure out a simple way to deal with passwords sometime?

Anyway, it's now playing the whole playlist. But it is flooding my LMS logfile with tons of strings like these:

0381: [20:40:57.354616] CastSocketThread:620 [0x20b294]: type:MEDIA_STATUS (id:336) PLAYING
0380: [20:40:57.307831] SendCastMessage:277 [0x1ace6a0]: Cast sending: {"type":"GET_STATUS","requestId":336,"mediaSession Id":2}
0379: [20:40:57.159135] CastSocketThread:623 [0x20b294]: type:PONG (id:0)
0378: [20:40:57.158472] CastSocketThread:623 [0x20b294]: type:PONG (id:0)
0377: [20:40:56.291759] CastSocketThread:620 [0x20b294]: type:MEDIA_STATUS (id:335) PLAYING
0376: [20:40:56.247915] SendCastMessage:277 [0x1ace6a0]: Cast sending: {"type":"GET_STATUS","requestId":335,"mediaSession Id":2}

Is there a way to make it stop doing that?

[philippe_44]

I agree of course, but for now usernameassword is better than nothing and I haven't been able to figure out how to configure SHH through the router given to me by my cable provider. So let's leave it at that for a while. Maybe you'll figure out a simple way to deal with passwords sometime?

Anyway, it's now playing the whole playlist. But it is flooding my LMS logfile with tons of strings like these:

0381: [20:40:57.354616] CastSocketThread:620 [0x20b294]: type:MEDIA_STATUS (id:336) PLAYING
0380: [20:40:57.307831] SendCastMessage:277 [0x1ace6a0]: Cast sending: {"type":"GET_STATUS","requestId":336,"mediaSession Id":2}
0379: [20:40:57.159135] CastSocketThread:623 [0x20b294]: type:PONG (id:0)
0378: [20:40:57.158472] CastSocketThread:623 [0x20b294]: type:PONG (id:0)
0377: [20:40:56.291759] CastSocketThread:620 [0x20b294]: type:MEDIA_STATUS (id:335) PLAYING
0376: [20:40:56.247915] SendCastMessage:277 [0x1ace6a0]: Cast sending: {"type":"GET_STATUS","requestId":335,"mediaSession Id":2}

Is there a way to make it stop doing that?

It does not go into the LMS server logfile, it does to stdout, or you can redirect that to a file or to null.

[oyvindo]

It does not go into the LMS server logfile, it does to stdout, or you can redirect that to a file or to null.

How do I redirect it to null?

[bpa]

Sorry, was not trying to be pedantic

My fault, I didn't mean to sound abrupt.

So my changes with regards to flow control is then mainly what I described before. The stream process is unchanged except to make it multi-threadable. But as the streambuf is flushed almost immediately, it keeps demanding more data to LMS

OK I ran a test with my CCA and it stops playing after about 30 mins. It looks like castnbridge decided to close the connection because it got not no data in 7 secs - is there a timeout or some sort which closes the link if there is no data ?

[15-12-17 21:13:11.1008] Plugins::BBCiPlayer::DASH::sysread (781) sysread - checking chunks : 2played :226622939
[15-12-17 21:13:11.1481] Plugins::BBCiPlayer::DASH::__ANON__ (711) error fetching [226622940] error=404 Not Found url=http://as-dash-ww-live.edgesuite.net/pool_6/live/bbc_radio_fourfm/bbc_radio_fourfm.isml/dash/bbc_radio_fourfm-audio=96000-226622940.m4s
[15-12-17 21:13:11.5023] Plugins::BBCiPlayer::DASH::sysread (781) sysread - checking chunks : 2played :226622939
[15-12-17 21:13:11.5509] Plugins::BBCiPlayer::DASH::__ANON__ (711) error fetching [226622940] error=404 Not Found url=http://as-dash-ww-live.edgesuite.net/pool_6/live/bbc_radio_fourfm/bbc_radio_fourfm.isml/dash/bbc_radio_fourfm-audio=96000-226622940.m4s
[15-12-17 21:13:11.9056] Plugins::BBCiPlayer::DASH::sysread (781) sysread - checking chunks : 2played :226622939
[15-12-17 21:13:11.9567] Plugins::BBCiPlayer::DASH::__ANON__ (711) error fetching [226622940] error=404 Not Found url=http://as-dash-ww-live.edgesuite.net/pool_6/live/bbc_radio_fourfm/bbc_radio_fourfm.isml/dash/bbc_radio_fourfm-audio=96000-226622940.m4s
[21:13:12.179313] CastSocketThread:623 [0x6b0cc0]: type:PONG (id:0)
[21:13:12.182930] CastSocketThread:623 [0x6b0cc0]: type:PONG (id:0)
[21:13:12.192250] CastSocketThread:623 [0x6b0280]: type:PONG (id:0)
[15-12-17 21:13:12.3090] Plugins::BBCiPlayer::DASH::sysread (781) sysread - checking chunks : 2played :226622939
[15-12-17 21:13:12.3595] Plugins::BBCiPlayer::DASH::__ANON__ (711) error fetching [226622940] error=404 Not Found url=http://as-dash-ww-live.edgesuite.net/pool_6/live/bbc_radio_fourfm/bbc_radio_fourfm.isml/dash/bbc_radio_fourfm-audio=96000-226622940.m4s
[21:13:12.572542] CastSocketThread:623 [0x6b0cc0]: type:CLOSE (id:0)
[21:13:12.572580] sq_notify:1024 [0x657518] uPNP forced STOP
[21:13:12.575208] CastSocketThread:623 [0x6b0cc0]: type:RECEIVER_STATUS (id:0)
[21:13:12.595068] CastStop:209 [0x6b0cc0]: Stop req w/o session or connect

[philippe_44]

My fault, I didn't mean to sound abrupt.

no worries

OK I ran a test with my CCA and it stops playing after about 30 mins. It looks like castnbridge decided to close the connection because it got not no data in 7 secs - is there a timeout or some sort which closes the link if there is no data ?

Yes, the <max_read_wait> sets in 50ms increments a timeout afterwhat the CCA to bridge link will be closed by castbridge. We had the same discussion on the UPnP bridge thread and castalla got it solved by putting 600 = 30s timeout. In theory, I could change that and simply let TCP timeouts do their job

[philippe_44]

My fault, I didn't mean to sound abrupt.

no worries

OK I ran a test with my CCA and it stops playing after about 30 mins. It looks like castnbridge decided to close the connection because it got not no data in 7 secs - is there a timeout or some sort which closes the link if there is no data ?

Yes, the <max_read_wait> sets in 50ms increments a timeout afterwhat the CCA to bridge link will be closed by castbridge. We had the same discussion on the UPnP bridge thread and castalla got it solved by putting 600 = 30s timeout. But the timeout happens on the bridge <=> CCA side, not on the LMS <=> bridge side. Of course, closing one closes the other