[Bug]: Infinite loop due to buggy COM port enumeration

shadeMe commented 1 month ago

Firefly Luciferin version

2.16.4

Glow Worm Luciferin version

NA

Firmware type

FULL

What is the stream method?

WiFi Stream

Fiefly Luciferin config file

No response

Relevant log output

No response

How to reproduce

I'm running into a peculiar bug on my Windows machine. For all versions starting with v1.10.2, the application enters a busy loop indefinitely after the initial firmware selection screen. I dug a bit further with by attaching a debugger, and I noticed the following:

For some odd reason, the code that enumerates the available devices loops infinitely. Inspecting the CommPortIdentifier p variable showed that the following linked list: COM1, COM5, COM5, ... repeatedly. Below are the list of active and inactive serial devices on my machine:

COM1 is the default port emulated by the mobo, COM5 is a keyboard (Dygma Raise), COM4 is a dig2Go and the rest are different variations of another Adalight device that I have connected through a pair of USB hubs. As long as the keyboard is connected, the enumeration loops infinitely. Disconnecting it fixes the issue. Interestingly enough, removing the inactive serial devices also fixes the issue.

Not sure if this merits a workaround/fix on your end, but the last change to the getAvailableDevices function happened here. Would you consider modifying the enumeration logic to include a sanity check for exactly this scenario?

sblantipodi commented 1 month ago

@shadeMe thank you for the very detailed bug report, I appreciate it. This bug has been bugging me for some time but I've never been able to reproduce it when I tried.

Still not able to reproduce with the device I have and it happens very very rarely on my machine.

Would you mind to create a pull request and try to fix it on your machine? If it's not possible, I'll try to fix it thanks to the additional details you gived me in this issue.

Thanks Davide

shadeMe commented 1 month ago

Happy to help! Unfortunately, I've been unable to reproduce the issue after the removal of the inactive COM devices (perhaps that might be a potential solution, i.e., filter out disconnected/inactive devices somewhere in the enumeration control flow?), so I'm afraid I can't provide a fix at the moment.

Furthermore, I ran into some more difficulties:

I use the dig2Go with a WS2812B 240 LED strip (with the dig2Go's bundled 5V 3A USB power adapter), and the Glowworm firmware (full and light) seem to overdrive the LEDs in my setup to a point that the micro-controller crashes/shuts down after a couple of minutes (I could get the brightness control on the web interface to work either).
The Firefly app automatically picks the active network adapter. Since I use a VPN, the app ends up picking its tunnel interface and starts broadcasting to the incorrect IP address range. Adding a split tunnel for the app in my VPN's setting (ProtonVPN) doesn't help either. So, I currently cannot use them together. And when I have the VPN disconnected, the app doesn't consistently discover/communicate with the device. Maybe there's a potential feature request there?

For those reasons, I've ended up going with the default WLED firmware + WARLS/DRGB. I'd love it if the app supported WLED, but I also understand your reasoning here.

sblantipodi commented 1 month ago

@shadeMe sorry for the late reply. 1) dig2go can't really support 240 LEDs, it is limited to 5V/3A and 15W can't nearly power 240 LEDs. 2) if you are using a VPN I'll suggest to bypass the autodiscovery feature and use a static IP address. 3) I love WLED but Firefly Luciferin is not going to support WLED for the reasons you already know. :)

sblantipodi / firefly_luciferin