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

[bpa]

HLS reports 339kbpS in LMS gui and DASH reports 320kbpS in LMS gui - I don't pretend to hear any difference obviously.

My mistake - I'm outside UK so was going on memory. I incorrectly thought HLS live stream were stuck at 128k

Live DASH through both squ2upnp and Castbridge stops a lot - HLS solid.

Is HLS slated to carry on in the future?

According to BBC HLS will stop - but it will depend on getting DASH support on iOS devices.

Please turn on logging for DASH - I think the issue is that the Castbridge is requesting a lot more data compared to a SB player and so is trying to get ahead of live streams - if that is the case there will be a lot of failed http fetches with 404 as DASH plugin is trying to get audio which has not been broadcast yet - this could create a load which slows LMS down (i.e it hasn't time to send audio). No problem with Listen Again since there is an "end" to a saved program.

[philippe_44]

First of all this an observation and not a complaint or request for assistance. Chapeaux to bpa and phillipe.

I have both squeeze2cast and squeeze2upnp and both of them are having difficulty when trying to play high bite rate live DASH streams from bpa's latest BBC iPlayer plugin. Music (FLAC) plays fine on all devices.

I have changed the max_read_wait parameter on both the castbridge and upnpbridge xml files to 350 and this improves matter slightly but the live streams on both devices still stop after a short time.

Changing bpa's plugin selection for live streams to: HLS>DASH> whilst leaving on demand streams at DASH results in rock solid performance from both.

I should say that both options work fine when listening on Triode's local player which is on my LMS server PC but the "virtual" upnp/cast players are connected through a homeplug network or are very close (1ft) to a wifi router.

I'm in the UK and using the high bit rate options of both HLS and DASH.

Is there a fundamental difference in the way the chunks are assembled/dis-assembled in these two protocols?

Do you see a problem with squeezelite or is this only with my bridges ? Any chance to capture a log when the problem happens ? If there is a timeout within the bridge, I could probably see and fix that but I need to know if the player is starved of the bridge is starved

[ian_heys]

Do you see a problem with squeezelite or is this only with my bridges ?

Trying to log at the moment but hasn't stopped for last 35 minutes.

Never seen it happen on squeezelite.

If I do get a log I'll try to send you the relevant part.

[castalla]

Do you see a problem with squeezelite or is this only with my bridges ? Any chance to capture a log when the problem happens ? If there is a timeout within the bridge, I could probably see and fix that but I need to know if the player is starved of the bridge is starved

Sounds similar to my Pure upnpbridge problem. However, with max read at 600, a dash stream is still playing at over 50 mins.

[ian_heys]

Stopped after about 40 minutes. I think this is the log from the time it stopped.

[14:47:55.343] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:47:56.249] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2299,"mediaSessio nId":1}
[14:47:56.280] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2299) PLAYING
[14:47:57.280] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2300,"mediaSessio nId":1}
[14:47:57.311] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2300) PLAYING
[14:47:58.311] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2301,"mediaSessio nId":1}
[14:47:58.343] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2301) PLAYING
[14:47:58.405] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:47:58.405] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:47:59.343] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2302,"mediaSessio nId":1}
[14:47:59.374] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2302) PLAYING
[14:48:00.374] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2303,"mediaSessio nId":1}
[14:48:00.421] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2303) PLAYING
[14:48:01.421] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2304,"mediaSessio nId":1}
[14:48:01.452] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:01.452] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:01.452] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2304) PLAYING
[14:48:02.452] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2305,"mediaSessio nId":1}
[14:48:02.483] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2305) PLAYING
[14:48:03.483] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2306,"mediaSessio nId":1}
[14:48:03.530] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2306) PLAYING
[14:48:04.530] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:04.530] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:04.546] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2307,"mediaSessio nId":1}
[14:48:04.577] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2307) PLAYING
[14:48:05.577] SendCastMessage:277 [006ADD50]: Cast sending: {"type":"GET_STATUS","requestId":2308,"mediaSessio nId":1}
[14:48:05.608] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:2308) PLAYING
[14:48:06.124] CastSocketThread:618 [0048E7BC]: type:MEDIA_STATUS (id:0) IDLE
[14:48:06.124] SyncNotifState:366 [0048E7BC]: Cast stop
[14:48:06.124] sq_notify:988 [004A628C] uPNP notify STOP
[14:48:06.889] CastSocketThread:621 [0048E7BC]: type:RECEIVER_STATUS (id:0)
[14:48:07.593] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:07.593] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:10.655] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:10.655] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)
[14:48:13.718] CastSocketThread:621 [0048E7BC]: type:PONG (id:0)

[bpa]

Stopped after about 40 minutes. I think this is the log from the time it stopped.)

Any chance of logging DASH to INFO at the same time ?

edit:

Does castbridge send transcoded to Flac or does it send AAC to CCA ?

[ian_heys]

Any chance of logging DASH to INFO at the same time ?

Thinks I have the concurrent LMS log but having a struggle getting it into a message.

Any chance of PM'ing me your email?

[oyvindo]

This is an ARMv5 and the build for this proc version are the ones I can't test. WRT directories, the plugin simply uses LMS recommendation, it is possible that you have some links between the 2 path you listed. Can you SSH/Telnet to your NAS ? If you can, launch the squeeze2cast-armv5 "manually" and see what happens. It seems that is crashes

[edit]: the crash is the reason why you don't have a config file generated ... it crashed before it is generated. I think now that you would need a static build as some NAS using 'old/simplified' Linux distribution require libraries to be statically linked. Unfortunately, I'm not able to create these build on armv5. I might do that, but not sure

I can SSH into the NAS, and I will try that - but not until I return from the Holidays.
However, I fail to understand your logic about the failure to generate the config file. My understanding from the config page, is that the plugin is not running unless the Run box is ticked, followed by "Apply" (?).
Now, since the "Generate" button is there whether "Run" is ticked or not, I assumed that it would work. Does this mean that the "Run" box implies running a different thread? Or does sq2c have to "Run" in order to be able to "Generate"?
All the "Crashed...Restarting" errors in my LMS log appears only after I tick "Run" + "Apply". If I only press "Generate" the following is entered into the log:
Plugins::CastBridge::Squeeze2cast::start (150) /opt/ssods4/var/home/SqueezeboxServer/slimserver.pl: exec failed: No such file or directory
Doesn't that indicate that the directory structure is wrong? I have SSH'ed into the NAS and the path /opt/ssods4/var/home/SqueezeboxServer/ does exist, but there is no slimserver.pl in there...

Please remember that i'm a newbee :-)

[bpa]

Thinks I have the concurrent LMS log but having a struggle getting it into a message.

Any chance of PM'ing me your email?

Copy log file into a text file , zip it and attach to a post.

[ian_heys]

Copy log file into a text file , zip it and attach to a post.

[philippe_44]

My mistake - I'm outside UK so was going on memory. I incorrectly thought HLS live stream were stuck at 128k

Live DASH through both squ2upnp and Castbridge stops a lot - HLS solid.



According to BBC HLS will stop - but it will depend on getting DASH support on iOS devices.

Please turn on logging for DASH - I think the issue is that the Castbridge is requesting a lot more data compared to a SB player and so is trying to get ahead of live streams - if that is the case there will be a lot of failed http fetches with 404 as DASH plugin is trying to get audio which has not been broadcast yet - this could create a load which slows LMS down (i.e it hasn't time to send audio). No problem with Listen Again since there is an "end" to a saved program.

There are 2 independant "processes" in castbridge (or upnpbridge):

- the modified squeezelite that receives the stream (GET) from LMS and stores it in a local buffer, so data are received whenever LMS sends something. There is no other timeout than the TCP one (I think, I need to re-check)
- the UPnP webserver part, that receives a GET from the UPnP player and responds in chunks or not. Whenever something is available in the buffer, this part forwards it to the player. This is where there is a timeout <max_read_wait> where the bridge closes the connection if the buffer is empty for too long. Of course, the player always has the possibility to close the connection if he wants to on his own timeouts

I don't know where I would put a larger constraint on LMS compared to native squeezelite. Do you think of a special case ?

[bpa]

[ATTACH]19475[/ATTACH]

First - that's a tiny log - not enough to make a diagnosis. What happened to the rest of the log file ?

You need to create a text file and then zip thre text file and then attach to a post.

What snippet is there is very very strange - it looks like the wrong URL is being used or else some sort of weird caching has taken place - that is why the rest of the log is important.

[bpa]

I don't know where I would put a larger constraint on LMS compared to native squeezelite. Do you think of a special case ?

Before we chase arounbd - the log file was very very strange - I can't see how any stream could work even normally. This may be UK thing. I need a proper log file before going further.

[ian_heys]

Have a longer log file but it ends in the same place.

[philippe_44]

I can SSH into the NAS, and I will try that - but not until I return from the Holidays.
However, I fail to understand your logic about the failure to generate the config file. My understanding from the config page, is that the plugin is not running unless the Run box is ticked, followed by "Apply" (?).
Now, since the "Generate" button is there whether "Run" is ticked or not, I assumed that it would work. Does this mean that the "Run" box implies running a different thread? Or does sq2c have to "Run" in order to be able to "Generate"?
All the "Crashed...Restarting" errors in my LMS log appears only after I tick "Run" + "Apply". If I only press "Generate" the following is entered into the log:
Plugins::CastBridge::Squeeze2cast::start (150) /opt/ssods4/var/home/SqueezeboxServer/slimserver.pl: exec failed: No such file or directory
Doesn't that indicate that the directory structure is wrong? I have SSH'ed into the NAS and the path /opt/ssods4/var/home/SqueezeboxServer/ does exist, but there is no slimserver.pl in there...

Please remember that i'm a newbee :-)

'Generate' stops the instance if it is running, launches it again with a special command line parameter to only discover players and then exit. It then restarts in normal mode if it was previously running

Hope this helps