Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LED does not turn on when turning off PC #792

Closed
userXinos opened this issue Mar 12, 2024 · 22 comments · Fixed by #800
Closed

LED does not turn on when turning off PC #792

userXinos opened this issue Mar 12, 2024 · 22 comments · Fixed by #800

Comments

@userXinos
Copy link

userXinos commented Mar 12, 2024

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:

  • 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)

@awawa-dev
Copy link
Owner

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

@userXinos
Copy link
Author

userXinos commented Mar 17, 2024

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

userXinos commented Mar 17, 2024

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
Copy link
Owner

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

@userXinos
Copy link
Author

userXinos commented Mar 17, 2024

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

the leds don't work at all now

@awawa-dev
Copy link
Owner

awawa-dev commented Mar 17, 2024

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
Copy link
Owner

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
Copy link
Author

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

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

@awawa-dev
Copy link
Owner

[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
Copy link
Author

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

@userXinos
Copy link
Author

image

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

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

@awawa-dev
Copy link
Owner

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
Copy link
Author

userXinos commented Mar 17, 2024

  • disabled
  • /usr/bin/hyperhdr > hdr.log
  • logout

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

@awawa-dev
Copy link
Owner

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
Copy link
Author

userXinos commented Mar 17, 2024

(leds not disabled)

@awawa-dev
Copy link
Owner

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

@awawa-dev
Copy link
Owner

awawa-dev commented Mar 21, 2024

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
Copy link
Author

userXinos commented Mar 22, 2024

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
Copy link
Owner

awawa-dev commented Mar 22, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants