Hyperion stops working after sleep (Win10)

  • Hi, I'm running Hyperion with WLED (just started setting it up this morning). All working well, except that when the PC sleeps and then wakes, Hyperion stops working. The LEDs correctly go blank when the PC sleeps, but they don't come back on when woken.


    I've checked the logs, and after sleep / wake, it shows this:


    < ----- Current Log --------------------------- >

    2023-01-06T14:16:43.066Z [LEDDEVICE|First LED Hardware instance] (ERROR) Device disabled, device 'wled' signals error: 'Power-off request failed with error: 'Host unreachable''

    2023-01-06T14:16:43.066Z [LEDDEVICE|First LED Hardware instance] (WARNING) Failed switching device wled OFF


    Which perhaps means that Hyperion thinks it has lost connection to the WLED controller and can't access it any more?


    After waking, if I tell hyperion to "identify" the LED controller, the lights all flash correctly, so the connection is fine. Also, if I just restart Hyperion it all starts working again - but obviously having to restart manually each time the PC sleeps is a bit irritating! Does anyone have any idea why this is happening and whether it can be resolved?


    Thanks in advance!

    • Offizieller Beitrag

    Proper Suspend/Resume support has been lately added to Hyperion see PR1535

    You might download one of the latest development builds to test the feature.

    Look for artifacts at the bottom of the screen.
    Note: This link is temporarily. The artifacts will be removed, if the PR is merged.

  • Ah - thank you! Just downloaded and slept / woke three times - it worked perfectly twice (with a delay of about 20 seconds after waking before coming to life), but on one occasion hyperion crashed - does it log to disk so it's possible to see what went wrong? (And thanks again for taking the time to add this functionality and point me at the dev builds to test it.)

  • Windows logs show me this:


    Faulting application name: hyperiond.exe, version: 2.0.15.0, time stamp: 0x63b45622

    Faulting module name: Qt5Core.dll, version: 5.15.2.0, time stamp: 0x5fa4dd3b

    Exception code: 0xc0000005

    Fault offset: 0x00000000001f307b

    Faulting process ID: 0x337c

    Faulting application start time: 0x01d921eab9d30beb

    Faulting application path: C:\Utilities\Hardware\Hyperion\bin\hyperiond.exe

    Faulting module path: C:\Utilities\Hardware\Hyperion\bin\Qt5Core.dll

    Report ID: bf5d7662-2d84-4885-b5e7-aa91fd3ba5a2

    Faulting package full name:

    Faulting package-relative application ID:


    EventData:

    hyperiond.exe

    2.0.15.0

    63b45622

    Qt5Core.dll

    5.15.2.0

    5fa4dd3b

    c0000005

    00000000001f307b

    337c

    01d921eab9d30beb

    C:\Utilities\Hardware\Hyperion\bin\hyperiond.exe

    C:\Utilities\Hardware\Hyperion\bin\Qt5Core.dll

    bf5d7662-2d84-4885-b5e7-aa91fd3ba5a2


    I'm guessing this isn't much help, though!

    • Offizieller Beitrag

    Unfortunately, it does not provide enough details…

    If you would like to do me a favor, you could start hyperiond.exe with „-c -d“ as options via the command-line or by creating a shortcut with command line properties.

    Then full debug output will be printed.

    In case the error occurs again, we might find some pointers to what happened before the abort.

    Many thanks already in advance! ;)

  • Thanks, that's perfect - I just (predictably) slept and woke five times and everything worked perfectly, but I'll keep launching with the debug flag set and try to test more tomorrow!

  • I just encountered another crash when resuming from sleep... but annoyingly, running hyperion with the "-c -d" from the command line, it still creates its own window and writes all the logs to that, so when the app crashes, the window vanishes together with all the log details.


    I'm struggling to think of a way to capture this - a quick google suggests that adding "/k" as a parameter to the console window should keep it open, or alternatively a flag to capture log writes to a file would be an option? If it happens again, I'll try to make sure the hyperion window is on top so I can watch it, but I suspect the crash will occur quickly enough that I won't get a chance to see any error messages...


    EDIT: just had a slightly different crash, it's come out of sleep but hyperion isn't responding at all, and the context menu isn't working. The log window is still up, but the most recent log is a few seconds after the initial startup, so nothing was written either entering or leaving sleep. Killing the process and restarting works fine, expected.


    Followup (sorry for the spam) - this time Hyperion slept, woke up fine, but didn't seem to be able to control or see the LED strip (no output). Quitting and restarting Hyperion corrected the problem, as usual. I've put the logs into pastebin rather than clogging up this thread: https://pastebin.com/s6Dd5tka

    2 Mal editiert, zuletzt von TimJW () aus folgendem Grund: Merged a post created by TimJW into this post.

  • Just as an update in case anyone else struggles with this - I couldn't get Hyperion to reliably work after sleep, and I also ran into a problem with HyperionScreenCap stopping capture after sleep and not resuming.


    Rather than spend any more time, I just used a quick powershell script to terminate and relaunch Hyperion and HyperionScreenCap, and set it as a scheduled task, triggered on workstation unlock (as I have my PC set to lock on sleep). This is now working fine for me, although hopefully Hyperion will become more reliable at suspend/resume over time and it will be unnecessary in the future!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!