Chromecast Plug-in - Beta Testing

[ServiceXp]

More of the same

Woke up this morning with all 3 groups down (I restarted the PI after the above post)

I noticed something today that I hadn't noticed before. 2 of the groups are utilizing the same IP. I think these are 'pseudo' IP address that the PI creates for groups and typically contain the actual IP of one of it's child members.

Not sure how the PI uses those group IP's, but this morning I noticed the PI returning the same refused error IP's (different ports) for 2 completely different groups (See log screenshot below).

Screenshot 1: Shows the IP duplication across 2 failed groups.
Screenshot 2: Shows the IP duplication across 2 connected groups after PI restart.
Screenshot 3: Shows my routers static IP assignment for the actual speakers.


I have attached 4 sets of logs. Any connection entries are me using the devices connect button in an effort to connect or raise a log error. I can't find any other way to know if the PI will connect (because on occasion it does if it's not in this refuse state) or not.

There was NO attempt to connect in the overnight log file.

[spud]

Woke up this morning with all 3 groups down (I restarted the PI after the above post)

I noticed something today that I hadn't noticed before. 2 of the groups are utilizing the same IP. I think these are 'pseudo' IP address that the PI creates for groups and typically contain the actual IP of one of it's child members.

Not sure how the PI uses those group IP's, but this morning I noticed the PI returning the same refused error IP's (different ports) for 2 completely different groups (See log screenshot below).

Screenshot 1: Shows the IP duplication across 2 failed groups.
Screenshot 2: Shows the IP duplication across 2 connected groups after PI restart.
Screenshot 3: Shows my routers static IP assignment for the actual speakers.


I have attached 4 sets of logs. Any connection entries are me using the devices connect button in an effort to connect or raise a log error. I can't find any other way to know if the PI will connect (because on occasion it does if it's not in this refuse state) or not.

There was NO attempt to connect in the overnight log file.

I haven't looked at your logs yet, but I can see how having some groups which share chromecast devices can be a problem because the plugin always try to maintain a connection to each group, and a chromecast device can't be actively part of two groups at the same time.

I will try to test that on my system, but could you delete temporarily your whole house group (and any other group where there would be a possible overlap) to see if that improve things.

Also, once a device is disconnected using the connect button is very likely to fail. The connect/disconnect should really only be used in very rare cases, for example if bonjour is not able to see your chromecast because they are on a subnetwork.

[ServiceXp]

I haven't looked at your logs yet, but I can see how having some groups which share chromecast devices can be a problem because the plugin always try to maintain a connection to each group, and a chromecast device can't be actively part of two groups at the same time.

I will try to test that on my system, but could you delete temporarily your whole house group (and any other group where there would be a possible overlap) to see if that improve things.

Also, once a device is disconnected using the connect button is very likely to fail. The connect/disconnect should really only be used in very rare cases, for example if bonjour is not able to see your chromecast because they are on a subnetwork.

Will do.

Can you add error notification to the root? So instead of 'Disconnected' use some other verbiage or state when an actual fatal error is raised?

[ServiceXp]

Removed all but the "Whole House Audio" Group, and problem persists.

Lost that group at some point last night.

There is some strange things going on in the logs, like volume changes during time frames when no one would be using the system, and a bunch of parsing errors.

Over the course of a few hours yesterday (during the day) I was moving some stuff around and had to unplug the CCA a few times for the "Living Room SPKR" I noticed every time the PI had no problem reconnecting.

It's seems like groups are what is at issue.

Logs attached.

[spud]

Removed all but the "Whole House Audio" Group, and problem persists.

Lost that group at some point last night.

There is some strange things going on in the logs, like volume changes during time frames when no one would be using the system, and a bunch of parsing errors.

Over the course of a few hours yesterday (during the day) I was moving some stuff around and had to unplug the CCA a few times for the "Living Room SPKR" I noticed every time the PI had no problem reconnecting.

It's seems like groups are what is at issue.

Logs attached.

I think I found the problem thanks to your logs, please test version 3.0.0.18 available in first post of this thread.

[ServiceXp]

I think I found the problem thanks to your logs, please test version 3.0.0.18 available in first post of this thread.

Thanks Spud, I'll upgrade tonight and report back.

[DMT]

I think I found the problem thanks to your logs, please test version 3.0.0.18 available in first post of this thread.

I too have had an ongoing problem with group disconnects. Good to see a potential fix in version 3.0.0.18. I will update and test. Also thanks to ServiceXp for all the diligent work in providing the logs.

Regards,

[ServiceXp]

No joy on build .18. It does seem better, I only had one of these episodes during the night.

The log entries were created by the PI. I didn't make any attempt to connect manual.

Upstairs Audio is a group
.

[spud]

No joy on build .18. It does seem better, I only had one of these episodes during the night.

The log entries were created by the PI. I didn't make any attempt to connect manual.

Upstairs Audio is a group
.

Could you post the debug logs?
thanks

[ServiceXp]

Could you post the debug logs?
thanks

I didn't have debugging turned on (dealing with a memory leak in HS ATM), but will turn it back on and report back.

[DMT]

No luck for me with version 3.0.0.18 - got a group disconnect within 24 hours.

The group disconnect for me always seems to occur between 2:00-4:00 AM EST. Once it disconnects I have to re start the plug in to reconnect. The connect button won't work in this case.

I have 2 chromecast audios and 1 google home mini that I have used with this plug in since it came out and I don't think I have ever had an actual device disconnect and fail to reconnect automatically. It has been rock solid. I only have one group and that is what's problematic.

What I find interesting is that my chomecast group has the same IP as my google home mini. Everything is DHCP reservation so nothing changes. On version 3.0.0.17 I was using BLLAN to ping my google home mini and would go 7-8 days before a group disconnect. Again, never a problem with an actual device just the group. Perhaps this relationship between the group (virtual) device and the actual device is the problem. Maybe google is doing some nightly firmware updates or something. I believe I created a test group at one time that just included the 2 chromecast audios and got similar disconnects so I don't think it's particularly related to my google home mini.

Hopefully we will find a solution!

Regards,

[ServiceXp]

I think I got the latest disconnect in the debug logs. Let me know if you need to more..

[ssvyper]

I'm also having some (seemingly random) disconnect issues. I have an audio, mini and 2 chromecasts, and no groups.
Sometimes the plugin disconnects from all my devices when I cast something and I have to manually connect (and that usually fixes it). However I can't always replicate it. I'll be keeping an eye on it and try more things.

[ServiceXp]

I'm also having some (seemingly random) disconnect issues. I have an audio, mini and 2 chromecasts, and no groups.
Sometimes the plugin disconnects from all my devices when I cast something and I have to manually connect (and that usually fixes it). However I can't always replicate it. I'll be keeping an eye on it and try more things.

I've resorted to using Jon00's PI disable/enabler. (Windows Only).

So when any of my Chromecast SPKR or Groups disconnect for exactly 3 min (in my case means it's not going to reconnect) I shut down the PI wait 1 min and restart. When completed sends me a push msg.

It's definitely a brute force option, but has allowed me to keep them alive.

I generally see at least 2 of these disconnects a day, almost always with Groups.

[Bobone]

Unfortunately also need to report a stability issue. Although connected, the PI did not communicate with CCA. Disconnecting followed by reconnect did not fix the problem. Needed to disable/enable to get on track again.