awawa-dev / HyperHDR

Highly optimized open source ambient lighting implementation based on modern digital video and audio stream analysis for Windows, macOS and Linux (x86 and Raspberry Pi / ARM).
http://www.hyperhdr.eu/
MIT License
1.05k stars 110 forks source link

LED does not turn on when turning off PC #792

Closed userXinos closed 6 months ago

userXinos commented 6 months ago

Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)

hdr.log config.json

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:

note

reference to: https://github.com/awawa-dev/HyperSerialEsp8266/discussions/39#discussioncomment-8759113

awawa-dev commented 6 months ago

Hi Could you test this build: https://github.com/awawa-dev/HyperHDR/actions/runs/8309238015

userXinos commented 6 months ago

hdr.log (reboot) hdr1.log (log out (for example))

hdr2.log (systemctl)

so this works if systemctl --user stop pipewire.socket && systemctl --user start pipewire.socket (hdr2.log) but not if reboot (hdr.log) or end session (hdr1.log)

udp: hdr3.log (shutdown - nope)

awawa-dev commented 6 months ago

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?

userXinos commented 6 months ago

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

awawa-dev commented 6 months ago

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.

userXinos commented 6 months ago

image image

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

awawa-dev commented 6 months ago

This log is from journalctl after you close the system or logged out the user?

userXinos commented 6 months ago

from web (http://localhost:8090/#logs)

the leds don't work at all now

awawa-dev commented 6 months ago

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)

awawa-dev commented 6 months ago

Compare logs to Kubuntu:

https://pastebin.com/nJAT66Fg

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.

userXinos commented 6 months ago

okay. my /usr/bin/hyperhdr > hdr.log

looks like the same thing https://pastebin.com/4hRyN9fq

awawa-dev commented 6 months ago

[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?

userXinos commented 6 months ago

yes, if I kill the program myself, it turns off the LED

userXinos commented 6 months ago

image

journalctl -xe | grep hyperhdr - https://pastebin.com/vEwLxPL5

idk how the daemon doesn't want to work it seems

awawa-dev commented 6 months ago

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.

userXinos commented 6 months ago

https://pastebin.com/TnzZaUDp (leds not disabled)

awawa-dev commented 6 months ago

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.

userXinos commented 6 months ago

(leds not disabled)

awawa-dev commented 6 months ago

Thank you. So it seems Fedore doesn't close the app on the user logout.

awawa-dev commented 6 months ago

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.

userXinos commented 6 months ago

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 😟

awawa-dev commented 6 months ago

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.