Closed shadeMe closed 2 months 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
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:
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.
@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. :)
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?