Devices are not always discovered

[tlk]

I usually have to launch the application twice to get the full list of my devices. Maybe waiting more time for product advertisement is required at startup or auto-refreshes while the menu is developed?

Originally posted by @mbolo01 in #4 (comment)

[tlk]

Not sure how to reproduce this. The https://github.com/tlk/beoplay-macos-remote-cli emulator show up instantly.

@mbolo01 the Discovery.app will let you see the devices as they announce their presence on the network via MDNS: https://apps.apple.com/us/app/discovery-dns-sd-browser/id1381004916?mt=12

They show up under _beoremote._tcp:

Do you see a pattern of the devices that are not discovered by BeoplayRemote.app?

[mbolo01]

I see all of them (5) with the Discovery app, as I do with the BeoplayRemote ..... but not systematically at first launch for the BeoplayRemote.
What is the logic behind? Is the BeoplayRemote querying via bonjour for available devices on the network or is it listening to devices advertising?
I just stopped/started BeoplayRemote and only 4 out of 5 appeared in the list, I stopped/started again and 5 out of 5 are present in the list. Sometimes I only have 1 out of 5.

I can run a network analyzer on my MAC and capture the advertisement MDNS packets to identify a frequency pattern.

[tlk]

Thanks for the feedback! I believe the issue is that the current implementation is very eager to return and stop the discovery process which is not really a great fit for this GUI app. The best approach is to adjust the implementation such that the app keeps listening for devices being added and removed during the entire app lifecycle (like you already mentioned). I had conveniently forgotten about my rather hackish implementation - hence the proof-of-concept label.

Come to think of it, I am not sure what the logic of the "moreComing" boolean is, as the nature of Bonjour/DNS-SD and mDNS is to support adding and removing services (devices) dynamically. Perhaps "moreComing = false" means "not right now, but maybe in 0.1ms".

Could be fun to improve this and will probably look into it sometime soonish. I'd rather save the network analysis to after the implementation has been changed, but it might come in handy at that point. Thanks!

[mbolo01]

I quickly ran a network analysis of the Discovery tool and it seems to broadcast to query about who ha sa mDNS service and then all impacted devices are responding in their turn, including the B&O devices. Then a mDNS cache is used I guess.

[tlk]

Bonjour! I have rewritten the code that handles device discovery. The app will now keep the list of devices updated during the entire app lifecycle. A simple way to test this is by toggling the wifi connection, but it should also address the issues you have been experiencing. Is is better now?
Best regards,
Thomas

[mbolo01]

Bonjour! I saw you updated the code before you commenting here, so I tried with the code available at that time. It works find for new devices being powered up while the app is working, but it "does not work" for devices powered down while the app is running. They don't disappear (I waited 5 minutes at least). The only way to make them disappear while the app is active is to flush the DNS cache. I guess you are relying on this cache in your queries and the cache is not updated the way that would suit your update logic.
It raised another issue: if you select a device present in the list, but not live, the app freezes. If you close it and run it again, it freezes again because I think it remembers the last selected device. Flushing the DNS cache helps me to get the control back as the previously selected device is no longer seen as active.

I saw you did a more recent update to a module, I'll test it with the same scenario.
Best regards,
Jérôme

[mbolo01]

Being more patient, powered of device disappeared automatically from the list after almost 10'.
I guess a test must be run before controlling a device still appearing in the list in case it has disappeared during between two DNS refreshes to avoid app freeze?

[tlk]

I have quickly adjusted the code so it does not automatically connect to devices unless specified under the devices.default property. This does not address the root cause though as selecting a non-accessible device will just silently fail.

[tlk]

You are right about the caching - the app relies on the macOS bonjour services. You can keep this running in Terminal.app to see the messages the app receive:

dns-sd -B _beoremote._tcp.

I just checked and my M5 responds to mDNS queries with TTL values at 4500 seconds (75 minutes). If the power is cut off the device does not have a chance to announce that it is disappearing. I could go crazy on network level and send out home-crafted packets in order to speed up things, but should probably rely on the macOS services :-)

In my tests the app now shows the ― symbol when asked to connect to a non-responding emulated device. The user can switch to another source and ignore the non-responding device.

With the latest update, do you still see app freeze when attempting to control a device that has been powered off?

[mbolo01]

When I tried to connect to a "-" marked device, it no longer freezes, good! But when I go back to the UI, the "✓" is back in front of the non responsive device.
Here is the log while I tried to connect to the "-" marked device:
2019-12-03 17:51:44.877609+0100 BeoplayRemoteGUI[25179:2278451] connectDevice "Bureau", BeoPlay-A6-25516325.local.:8080
2019-12-03 17:51:44.877871+0100 BeoplayRemoteGUI[25179:2278451] connection state: disconnecting
2019-12-03 17:51:44.878046+0100 BeoplayRemoteGUI[25179:2278451] connection state: offline
2019-12-03 17:51:44.878342+0100 BeoplayRemoteGUI[25179:2278451] connection state: connecting
2019-12-03 17:51:44.878684+0100 BeoplayRemoteGUI[25179:2278451] reload sources
2019-12-03 17:51:44.878982+0100 BeoplayRemoteGUI[25179:2278451] device

[tlk]

Great with the log, thanks! I checked in an update - did that help?

[mbolo01]

Yep, "-" is now always present when selected device is unreachable, well done.
May I suggest different signs that inform about an issue such as:
"! M5 Kitchen" or "x M5 Kitchen"

[tlk]

Agree, "!" looks better than the default symbol - just need to figure out how to change it...