LED does not turn on when turning off PC
userXinos opened this issue · comments
Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)
Steps to reproduce
use ctrl+shift+del menu to turn off/restart pc
What is expected?
turn off all leds
What is actually happening?
The app crashes and doesn't turn off the LED properly
System
HyperHDR Server:
- Build: master (GitHub-0a2123d/fc83579-1709997497)
- Build time: Mar 9 2024 15:21:09
- Git Remote: https://github.com/awawa-dev/HyperHDR
- Version: 20.0.0.0beta2
- UI Lang: auto (BrowserLang: en-US)
- Avail Capt: Linux (V4L2)
- Database: read/write
note
reference to: awawa-dev/HyperSerialEsp8266#39 (reply in thread)
Hi
Could you test this build: https://github.com/awawa-dev/HyperHDR/actions/runs/8309238015
I see no sign that the signal was sent to HyperHDR so that it could cleanly close the LED drivers. The log ends abruptly. And we have handlers for SIGINT, SIGTERM, SIGPIPE etc. Are the LEDs not turned off in these 2 cases, also when you run HyperHDR from the menu and not from the console?
The console was used to create a log files. But I checked right now, the leds do not turn off if the application is launched from the start menu or from autorun
Without signals that are not sent to HyperHDR, we are unable to ensure proper driver shutdown. There is no such problem on Debian (e.g. Raspberry Pi OS). You can try a workaround and run HyperHDR as a user service, maybe at least it closes properly.
Something like that:
systemctl --user start hyperhdr.service
systemctl --user status hyperhdr.service
Or as a global service.
okay. if i run it like this, there is no icon in the tray and there is no system screen capture in the dashboard
upd:
log.txt
This log is from journalctl after you close the system or logged out the user?
from web (http://localhost:8090/#logs)
the leds don't work at all now
Inside service you may need --verbose --desktop flags and reload it later. Pipewire wont work if console app (daemon) is detected as in your logs. I don't know if it makes sense to continue debugging it. Signals such as SIGINT or SIGTERM are the basis without which the application cannot function properly and it is not visible that they are sent to it. And it works on other systems. What I could have improved, I did (response to Pipewire's stream pause event which previously generated an exception)
Compare logs to Kubuntu:
There is a clean exit on user log out action. Which is missing on Fedora in your logs. I run it something like that: /usr/bin/hyperhdr > /home/...log.txt So I guess it's Fedora specific behaviuor unless I'm missing something.
okay. my /usr/bin/hyperhdr > hdr.log
looks like the same thing
https://pastebin.com/4hRyN9fq
[0m18:27:54.259 LEDDEVICE0_ADALIGHT : [0m LedDevice.cpp:544:writeBlack() | Set LED strip to black/power off [36;1m
LED was powered off in this case?
yes, if I kill the program myself, it turns off the LED
journalctl -xe | grep hyperhdr - https://pastebin.com/vEwLxPL5
idk how the daemon doesn't want to work it seems
I didnt kill the program but I simply logged-out. Try to repeat the same procedure ('/usr/bin/hyperhdr > hdr.log') for user log-out and power off. BTW do you have 'restore apps' enabled in the KDE configurations ( https://askubuntu.com/questions/428805/prevent-kubuntu-from-remembering-previous-session ) ? Disable it.
- disabled
- /usr/bin/hyperhdr > hdr.log
- logout
https://pastebin.com/TnzZaUDp
(leds not disabled)
Maybe there is still a crash? Nothing in the journalctl? Could you disable Pipewire capturing (in the grabber configuration), set a background effect instead and repeat it.
- journalctl -f > journalctl.log - https://pastebin.com/byenXter (nothing about hyperhdr)
- /usr/bin/hyperhdr -v > hdr.log - https://pastebin.com/rFnst4ad
- logout
(leds not disabled)
Thank you. So it seems Fedore doesn't close the app on the user logout.
The patch for crash on Pipewire stream pause is included in #800 The problem of not properly closing the app by your configuration of Fedora is not an HyperHDR issue.
So, does that mean I should wait for the LED to be forced to turn off on the controller’s side ?
Btw, the problem seems to have gotten worse and it seems to happen sometimes even if shutdown via the start menu 😟
To proper shutdown HyperHDR needs to be notified about closing. If it doesn't happen as in your logs then probably it is killed just like that so LEDs remain on last colors that were sent. I suspect OS encounters some problem maybe even crash during shutdown/logout and that prevents it from properly apps closing. I could not repeat that behaviour on KUbuntu which uses KDE/plasma as in your configuration.
The problem with the crash on pipewire stream pause was real and fixed but I suspect it was related to the same problem because otherwise HyperHDR should be closed first then Pipewire. But for some reason on your system Pipewire service is closed before the app that was run by the user.