Duplicate Groups #70
Comments
|
I have also seen occasional instances of a group being duplicated (and I use static IP addresses). I was able to put everything back to normal by clicking "Reset Settings" on the Options tab. I tried clicking Scan for Devices but it appears to do nothing. I would be content if Scan for Devices "rebuilt" the list of devices in the same way that Reset Settings does but without changing the items ticked on the Options tab. |
|
I'm not sure what happens when there are duplicates. In 2.6.2 I added some logging. Can you post the lines that start with 'OnServiceAdded:' & 'Discovered device:'? I'm not sure about changing the scan button. Maybe I should add a close button in the device box to remove a device? |
|
Do you want the lines from v2.6.1? ...or do you want me to install v2.6.2, and send that log? |
|
RE: "Maybe I should add a close button in the device box to remove a device?" That would be useful when a device is displaying an error... |
|
Can you also post the 2.6.2 logs? I've added some additional data for testing purposes. |
|
OK, I installed v2.6.2, and ran a couple of scenarios... When I first loaded DAS, it did not discover all Devices, and I had to click "Rescan..." multiple times. It eventually found all Devices, and no duplications. I Casted to the 1st Floor & 2nd Floor Groups, and did not notice any issues (Log "ToGroups") Then I unloaded DAS, and restarted it. This time, it took MANY clicks on "Rescan..." to find all Devices, and it also made duplicate Devices for two Groups. I casted to individual Devices (Image 1), then tried the "X" that appeared on one of the Duped Groups. When I clicked the "X", the Device color changed (image 2); (Log "ToDevices"). I then deselected the Devices, and selected 2 of the Groups (Image 3)... ...and Log "SwitchedToGroups" I will monitor the rest of the day as it Casts to the Groups. |
|
The dilemma for me is that (in the past), Casting to individual Devices seems more stable, that is, fewer to no Drop-outs; HOWEVER, the speakers are not in sync, which is bothersome in open areas where you can hear the audio from multiple Devices that are buffering differently. I'm guessing the drop-outs while Casting to Groups could be caused by IP Address changes to the Groups (which would explain why DAS sometimes populates with duplicate Group Names)... How can a Group be assigned a static IP Address? {a Group is sort of a "Virtual Device", so there doesn't seem to be a way to see a Group in the Router)... |
|
My understanding, perhaps wrongly, is that one device in a group is the "master" for that group. My guess is that you get duplicate groups if the "master" device gets allocated an new IP. There is no way to specify which device is the master for a group. You will almost certainly have a more stable setup if you bite the bullet and give all devices static IP addresses. Forgive me if I am teaching you to such eggs ... I have specified static IP addresses for all my devices in the DHCP server function of my router. Devices still get IP addresses by DHCP but they get the same address every time. |
|
Thanks @FA-Bubba , great logs & dumps (as always).
That's why the groups appear twice. I don't know why there are two id's in your setup. Both have the same IP. It can be that the id can't (always) be used to identify a group, or that an old id is still broadcasted in your network. Maybe turning all Chromecasts off, and then on again fixes it. Let me think on how to fix it in DAS...
|
|
I set static IP Addresses for al of my Devices, and a quick peak 'implies' that the Group inherits the lowest IP Address of it's Group Members (I will need A LOT more observations to conclude this, but a few peeks aligns with this theory... So far, no Duplicated Groups, so setting a Static Address may prevent that (unless the lowest IP drops off-line). If I observe this, I will analyze some network stats and will ID the Devices with the consistently highest connection levels, then assign them the lowest IPs... I'm not sure if this will be fruitful, but worth a try. BTW, the "X" was only visible in that one Device Box... |
|
v2.6.2... Basically, Device discovery was inconsistent, and Casting failed a few times. Casting seems to be OK now, but the status in the Device Boxes still seems inconsistent. BTW, all of my devices have Static IPs now. |
|
It looks like the duplicate groups disappeared because of the statis IP addresses. DAS doesn't stop the devices when you close the application. That's why the status is still 'Casting ...' when you stop & start the application. And change to 'Connected' after a while. |
|
I believe the attached log is for about a 22-hour period... I noticed some Disconnects, and Reconnects at the following times: 9:11 PM; 9:20 PM; 10:29 PM & 4:02 AM. To my knowledge, there were no "events" on my network during any of these times, although the Host PC does a backup to a local USB drive around 1:00 AM & around 3:00 AM. It is possible to determine from the Log what might be causing these drop-outs? All of my Devices have Static IPs. I have also attached a screen shot of network statistics showing Uptime & Activity for all of the Devices I am using with DAS. |
|
It's not clear to me what's causing the drop-outs. |
|
This comment refers to a closed issue about audio drop-outs... I again experienced a lot of dropouts, even after rebooting, so I restarted DAS, and instead of casting via Speaker Groups, I selected each speaker individually. This enabled me to more easily identify where the drops were occurring... I then rebooted each offending Device Only 4 units were demonstrating this issue); that is, I unplugged the power cord to each of these Chromecast Audio devices, and restarted each device. This resulted in a much more stable experience, with no drop-outs. Now I am wondering if each Chromecast Audio has some sort of buffer overflow issue that is corrected by powering-it down, then back on. They had all been powered on for several months, with no "off-time", so it is feasible that they had individual "memory issues"... I'm not sure how I can confirm this idea, but offer it as 'food for thought'... |
|
I solved one issue, but another (old) one popped-up:... Now, I am seeing a Duplicate Group (2nd Floor Speakers) in the Device Box. The "2nd Floor Speakers" Group is 'Discovered' 3 times in the attached log, but with two different addresses. Since the dropouts have been resolved, I am not currently Casting to this Group, but using "ALL Speakers" instead. However, I may have a need to use this group again in the future, so would like to correct this. Any ideas?
|
|
Nice that you have no more dropouts! Maybe the groups appear multiple times because of the new router. A 'Reset Settings' should fix it. |
|
THANK YOU! "Reset Settings" eliminated the dupe Group. My guess is that the new address resulted from the new Extender, even though it uses the same SSID... FYI, the PC had rebooted before that, and still retained the Dupe Group -- does that mean settings of previously Discovered Devices/Groups are stored or cached? Thanks! |
|
Yes, the known devices are stored when you close the application. The list of known devices is used when discovery of devices fails. |
On startup, DAS populated the Device Box with some duplicate names... Just prior to this, DAS had been running for about 48+ hours, streaming only to Groups, and I was hearing drop-outs. At that time, I noticed that the "1st Floor" Group had a duplicate entry in the Device Box, so I closed the App, and restarted it. It was then that the "1st Floor" & the "2nd Floor" Groups were duplicated upon initial loading, so I selected ONLY individual devices (see screen shot), and the stream was stable, without dropouts...
I downloaded the Log, and noticed multiple instances of these Groups being 'discovered' ,but with different addresses. I am wondering if assigning static IP Addresses to each device would help resolve this... HOWEVER, is it possible to assign a static IP Address to a Group? (if so, how?). Also, is there a way to use MAC Addresses instead of IP -- would that be more stable or 'better' than using IP Addresses?
Log-2020-02-04-v2-6-1-DupeGroups.zip
The text was updated successfully, but these errors were encountered: