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

[mikk64]

Hi to everybody!
big fan of this plugin! It saved my listening pleasure!
now, my problem...i have 1 chromecast audio, 2 nest audio and 1 nest hub, in my bedroom...and the last is the weak point
all of the others are well going, without any problem, the nest hub, almost each time i start playn' (let's, each night, one time a day, and each morning as an alarm), it stops about few seconds after, let's say usually 15-30"...and at the second attempt usually goes without any other problem (even not always)
this problem occurs 9 times on 10, so, as a workaround, as alarm, i set two alarm and the second do the job...
any idea?
i am on the last LMS, 8.4 always updated, picore player, wifi at home and CCB 2.2.6
thanks for helping!

[SamY]

I should have asked this before but didn't. How long do you give the restarted bridge before you decide it isn't going to detect any devices? Until recently I was restarting every couple of days, and it wasn't unusual for it to take 5 or 10 minutes before the first device was detected.

There's no indication that Philippe has seen my most recent post yet, but I'm confident that what I say there is correct. The bridge has been running successfully for more than 100 hours now, with all but one of my devices disabled through config.

Whenever the bridge is started (except when the problem is occurring, in which case I have to reboot), the devices are detected immediately. At the moment, the plugin has been running successfully for 7 days without a reboot, which might be a new record for me. During that time, however, I rebooted my router which is something I rarely do. The next time the CC devices go missing, I'll check the config file per your post.

[edw5]

I don't know how odd it is but I've also never experienced a problem like this with the UPNP bridge or with any other Windows app --- LMS plugin or otherwise. I wish my problem only required restarting the bridge instead of rebooting the machine though. I envy you.

I should have asked this before but didn't. How long do you give the restarted bridge before you decide it isn't going to detect any devices? Until recently I was restarting every couple of days, and it wasn't unusual for it to take 5 or 10 minutes before the first device was detected.

There's no indication that Philippe has seen my most recent post yet, but I'm confident that what I say there is correct. The bridge has been running successfully for more than 100 hours now, with all but one of my devices disabled through config.

[SteveBamber]

Thanks - no luck with or without transcode set, it's a bit of a head scratcher

It was some kind of issue with the Nest Mini - not sure what, but a full factory reset seems to have fixed it.

It's now happy to cast with 2.2.6 - when in doubt hit it with a big stick...

[SteveBamber]

Same firmware for me. I also have transcode set to FLAC and flow mode enabled if that makes a difference.

Thanks - no luck with or without transcode set, it's a bit of a head scratcher

Nest Mini - fail

[15:08:37.003345] CastLoad:177 [0xb3fc20]: Queuing LOAD
[15:08:37.003359] sq_callback:336 [0xb3fc20]: current URI (s:0) http://192.168.0.10:37521/bridge-1.flac
[15:08:37.003367] process_start:1245 [0xaa5260]: codec:f, ch:0, s:0, r:0
[15:08:37.003424] sendSTAT:159 [0xaa5260]: STAT:[STMc] msplayed 0
[15:08:37.003453] sq_callback:389 [0xb3fc20]: LMS volume (0..128) 2 => CC 0.0600
[15:08:37.060311] SendCastMessage:125 [0x7fb58002cfc0]: Cast sending: {"type":"LAUNCH","requestId":1,"appId":"46C1A81 9"}
[15:08:37.060335] CastSocketThread:631 [0xb3fc20]: Launching receiver 1
[15:08:37.088794] CastSetDeviceVolume:375 [0xb3fc20]: Queuing SET_VOLUME
[15:08:37.088832] CastPlay:264 [0xb3fc20]: Queuing PLAY
[15:08:37.119698] CastSocketThread:603 [0xb3fc20]: type:LAUNCH_ERROR (id:1)

Chromecast Audio - no issues

[15:11:59.433600] SendCastMessage:125 [0x7fb5800317a0]: Cast sending: {"type":"LAUNCH","requestId":1,"appId":"46C1A81 9"}
[15:11:59.433621] LaunchReceiver:188 [0xb40950]: Launching receiver 1
[15:11:59.433640] CastLoad:177 [0xb40950]: Queuing LOAD
[15:11:59.433645] sq_callback:336 [0xb40950]: current URI (s:0) http://192.168.0.10:58795/bridge-1.flac
[15:11:59.433650] process_start:1245 [0xaa9f98]: codec:c, ch:0, s:0, r:0
[15:11:59.433699] sendSTAT:159 [0xaa9f98]: STAT:[STMc] msplayed 0
[15:11:59.433728] sq_callback:389 [0xb40950]: LMS volume (0..128) 5 => CC 0.1000
[15:11:59.448718] CastSetDeviceVolume:375 [0xb40950]: Queuing SET_VOLUME
[15:11:59.448741] CastPlay:264 [0xb40950]: Queuing PLAY
[15:12:00.851231] CastSocketThread:603 [0xb40950]: type:RECEIVER_STATUS (id:1)
[15:12:00.851288] CastSocketThread:659 [0xb40950]: Receiver launched
[15:12:00.851365] SendCastMessage:125 [0x7fb5800317a0]: Cast sending: {"type":"CONNECT","origin":{}}
[15:12:00.851403] ProcessQueue:485 [0xb40950]: Processing LOAD (id:2)
[15:12:00.851499] SendCastMessage:125 [0x7fb5800317a0]: Cast sending: {

[slartibartfast]

If it was the network then you would expect it to affect the Chromecast Audio as well - but that has no problem launching the new app.

It's only the Nest Mini that's affected - presume your Nest Mini is running the same firmware version ?

Same firmware for me. I also have transcode set to FLAC and flow mode enabled if that makes a difference.

[SteveBamber]

Me too - may be something to do with your network setup?

If it was the network then you would expect it to affect the Chromecast Audio as well - but that has no problem launching the new app.

It's only the Nest Mini that's affected - presume your Nest Mini is running the same firmware version ?

[The Groundsman]

My Nest Mini seems to be fine with 2.2.6.

Me too - may be something to do with your network setup?

[slartibartfast]

I'm having trouble getting a Nest Mini to work with the new 2.2.x version

A separate Chromecast Audio works great with 2.2.x but the Nest Mini won't play anything, consistently reports a launch error trying to start the new CC app

[08:13:44.846933] SendCastMessage:125 [0x7f4cf002cfd0]: Cast sending: {"type":"CONNECT"}
[08:13:55.874108] SendCastMessage:125 [0x7f4cf002cfd0]: Cast sending: {"type":"LAUNCH","requestId":1,"appId":"46C1A81 9"}
[08:13:55.943777] CastSocketThread:603 [0xb3fc20]: type:LAUNCH_ERROR (id:1)
[08:15:42.008275] SendCastMessage:125 [0x7f4cf002cfd0]: Cast sending: {"type":"LAUNCH","requestId":2,"appId":"46C1A81 9"}
[08:15:42.070500] CastSocketThread:603 [0xb3fc20]: type:LAUNCH_ERROR (id:2)

It's been power cycled many times but doesn't seem to want to play ball

Cast firmware 1.56.348702
LMS 8.4.0
Chromecast bridge 2.2.6

Any ideas why the Nest Mini would object to the new CC app ?

At the moment still having to use 2.1.16 in order to cast to the Nest Mini

My Nest Mini seems to be fine with 2.2.6.

[Paul Webster]

Perhaps should make it possible to disable the sending of the JavaScript app to the ChromeCast device just in case this becomes a feature on other Google devices after a firmware update.

[SteveBamber]

I'm having trouble getting a Nest Mini to work with the new 2.2.x version

A separate Chromecast Audio works great with 2.2.x but the Nest Mini won't play anything, consistently reports a launch error trying to start the new CC app

[08:13:44.846933] SendCastMessage:125 [0x7f4cf002cfd0]: Cast sending: {"type":"CONNECT"}
[08:13:55.874108] SendCastMessage:125 [0x7f4cf002cfd0]: Cast sending: {"type":"LAUNCH","requestId":1,"appId":"46C1A81 9"}
[08:13:55.943777] CastSocketThread:603 [0xb3fc20]: type:LAUNCH_ERROR (id:1)
[08:15:42.008275] SendCastMessage:125 [0x7f4cf002cfd0]: Cast sending: {"type":"LAUNCH","requestId":2,"appId":"46C1A81 9"}
[08:15:42.070500] CastSocketThread:603 [0xb3fc20]: type:LAUNCH_ERROR (id:2)

It's been power cycled many times but doesn't seem to want to play ball

Cast firmware 1.56.348702
LMS 8.4.0
Chromecast bridge 2.2.6

Any ideas why the Nest Mini would object to the new CC app ?

At the moment still having to use 2.1.16 in order to cast to the Nest Mini

[edw5]

The bridge failure is caused by the number of chromecasts that are visible on my network and enabled (or to be accurate, not disabled) in the config file.

I have at least 5 and sometimes 6 chromecasts on my network at all times. I only use the bridge on 2 of these, so I had the others disabled in the config file. About a month ago, I removed the network connections from 2 TV's with chromecast built-in and replaced them with streaming sticks. At almost exactly the same time, I upgraded the bridge. The key point is that I regenerated the bridge config from scratch and did not disable any devices in the config.

This is when my problems started, and nothing I could do, including reverting to 1.82.2, would fix them. The bridge always failed in less than 48 hours, even after I moved it to a different machine.

It finally dawned on me the other day that the config file change was potentially significant. I disabled all but one device in the config and restarted the bridge. More than 72 hours later, it is still running.

The bridge can clearly handle 5 or even 6 devices -- it doesn't fail immediately it detects them all. I suppose it's possible that there's a failure after a set number of add/remove operations, but that also seems unlikely. I haven't looked at the source, but a race condition seems most likely to me -- either between multiple instances of the add/remove code, or between that code and something else.

I hope this helps.

[edw5]

Have you tried switching to the other version of the application? static v non-static

On X86_64 I have tried both versions a number of times; on aarch64 (the pi) I haven't tried that yet. The failure I'm seeing typically occurs in 36-48 hours, which is frequently enough to be annoying, but also infrequently enough to make identifying the root cause by changing parts of my setup very time-consuming. I'm currently trying to figure out if I have enough unused equipment to set up an isolated network to experiment on, in case my ISP-issued router is the problem.

[SamY]

It's not quite either. For me, the bridge continues running, but after a period of time all of its network operations fail, making it effectively useless. It never actually crashes though, and I only have to restart the bridge, not the host machine. Also, all my machines are running Linux. What's really odd, as I've mentioned a few times, is that the upnp bridge continues to run successfully on the exact same machine.

I don't know how odd it is but I've also never experienced a problem like this with the UPNP bridge or with any other Windows app --- LMS plugin or otherwise. I wish my problem only required restarting the bridge instead of rebooting the machine though. I envy you.

[Paul Webster]

Have you tried switching to the other version of the application? static v non-static