You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to figure out what goes wrong for a little while, but exactly what goes wrong eludes me.
I'm working on a media server that uses jmdns to discover "Google Cast" devices like the ChromeCast. It mostly works fine, but I've discovered that if the ChromeCast device reboots, jmdns sends the remove event, but doesn't send a new add or registered event when the device comes back on line. I've done many attempts at studying this, and it seems that it will eventually be "rediscovered", but I can't find any logic in when that is. I have experienced anything from 4 minutes to 3 hours and 20 minutes before it is "rediscovered".
I've tried to dive into the details, I've read through the entire RFC6762 and "selected parts" of RFC6763, but to no avail. I have problems interpreting jmdns' logging enough to understand what's really going on, but it looks to me like the ChromeCast announces itself like it should when it's coming back up, and it also seems like it's re-added to jmdns' cache, but no add or registered events are sent. This indicates to me that the problem is most likely with jmdns, but I don't understand the log well enough to be sure.
I'm attaching a log file where I've manually "isolated" one such reboot by deleting log events that doesn't come from jmdns or isn't directly related. I've made a "debug implementation" of both listener types that will merely log the event that is received, and I've left these in the log. The entries from the "debug listeners" can be recognized by net.pms.service.MulticastDNS.
I think this problem should be easily reproducible by anybody that has a "cast device", which includes ChromeCasts, Google Home devices and Android TVs. All I do to trigger the reboot is to use the "Google Home" application on Android and send the command to reboot from there.
I hope somebody that know this better than me can help analyze the situation, as I seem to be stuck.
I've been trying to figure out what goes wrong for a little while, but exactly what goes wrong eludes me.
I'm working on a media server that uses jmdns to discover "Google Cast" devices like the ChromeCast. It mostly works fine, but I've discovered that if the ChromeCast device reboots, jmdns sends the
remove
event, but doesn't send a newadd
orregistered
event when the device comes back on line. I've done many attempts at studying this, and it seems that it will eventually be "rediscovered", but I can't find any logic in when that is. I have experienced anything from 4 minutes to 3 hours and 20 minutes before it is "rediscovered".I've tried to dive into the details, I've read through the entire RFC6762 and "selected parts" of RFC6763, but to no avail. I have problems interpreting jmdns' logging enough to understand what's really going on, but it looks to me like the ChromeCast announces itself like it should when it's coming back up, and it also seems like it's re-added to jmdns' cache, but no
add
orregistered
events are sent. This indicates to me that the problem is most likely with jmdns, but I don't understand the log well enough to be sure.I'm attaching a log file where I've manually "isolated" one such reboot by deleting log events that doesn't come from jmdns or isn't directly related. I've made a "debug implementation" of both listener types that will merely log the event that is received, and I've left these in the log. The entries from the "debug listeners" can be recognized by
net.pms.service.MulticastDNS
.I think this problem should be easily reproducible by anybody that has a "cast device", which includes ChromeCasts, Google Home devices and Android TVs. All I do to trigger the reboot is to use the "Google Home" application on Android and send the command to reboot from there.
I hope somebody that know this better than me can help analyze the situation, as I seem to be stuck.
cast_reboot_log.txt
The text was updated successfully, but these errors were encountered: