Seit Update auf 6.11.5 Probleme...

Nope, nichts mehr eingebaut, keine PCI Karte oder ähnliches. Auch die WLAN OnBoard komplett deaktiviert.
Eingebaut nur 4x HDD (2x Seagate IronWolf 10 TB, 2x WD Green 8 TB) + 1x M.2 SSD 512 GB für Cache.
Tuner laufen über die Kabel-FritzBox, habe lediglich ein USB Reader dran für OSCAM für meine UnityMedia Karte.
Edit: Und aktuell läuft eine Windows VM auf Unraid Server wegen YouTube Downloader Batch)

OMV ist halt auch wieder Linux mit dem ganzen "Theater", dass Sleep vielleicht geht, vielleicht aber auch nicht.

OMV hatte ich auch früher genutzt, glaube bis Version 3 oder 4.
War auch immer etwas "gefrickel". Ok, damals war das Docker-Thema noch nicht soooooo weit verbreitet, Installationen direkt auf dem OMV System
Und bei OMV muss ich dann wieder mit dem SleepScript schauen/basteln, da werd ich mittlerweile echt zu alt für.
Wobei, wie geschrieben, LightsOut und Aufnahmen-Planung ist auch gebastel... seufz

Mmmh, meinst du wegen dem erhöhten Stromverbrauch, oder wegen dem Schlafenlegen?

Falls wegen dem Sleep:
Soweit ich weiß sende ich über das Sleep Script den Befehl vorher die VM in Pause/Sleep zu versetzen. Oder sogar herunterfahren? weiß nicht mehr (mit einem Delay anschließend).
Kann ich die tage mal schauen was ich da gemacht habe...

Falls wegen Stromverbrauch:
Joah, könnte ich mal schauen wie der sich auswirkt, wäre dann aber auch keine "Lösung", da ich die ja hier und da brauche, nicht nur yt-dlp läuft da drauf, auch andere Kleinigkeiten, Serien- umbenennen (FileBot glaube ich), und einfach der Explorer wird darüber genutzt um in den Netzwerkfreigaben zu "pfuschen", hier und da auch mal zum Surfen und was nachlesen, weil es am Tablet einfach ne Kackseite ist die sich sehr mies bedienen lässt

Hach schön.
Wochenende hat er sich direkt 2x hintereinander nach dem Sleep aufgehängt, sonst liegen manchmal tage dazwischen...
Lustiger/Interessanterweise hat es nichts gebracht
a) den RAM zu tauschen
b) VM auszulassen

Einzuschalten / booten konnte ich (nach dem Strom weg, Strom dran) dann auch erst wieder, wenn ich den Stick einmal abgezogen habe, und dann wieder reingesteckt habe.
Ohne das raus- und reinstecken des USB Sticks hat er sich beim Einschalten direkt nach dem BIOS Post aufgehängt.

Vermute irgendwie jetzt der Stick hat nen Macken.. oO
Aktuell nutze ich ja einen SanDisk USB3.0 Stick
Ich weiß, USB 3.0 sollte man vermeiden, habe ich aber auch erst gelesen, nach dem ich die Lizenz drauf gehauen hatte
Und wieso vorher etwas ändern wenn etwas läuft, aber jetzt wäre ggf die Möglichkeit auf einen USB 2.0 SLC Stick zu wechseln...
z.B. https://de.rs-online.com/web/p/usb-sticks/2444608

Fastboot köntne sogar tatsächlich aktiviert sein.
Nutzen tu ich Standby S3, kein Hibernate (S4) (wenn ich die S-Zustände richtig verstanden habe), aber im Plugin ist definitiv Standby ausgewählt.


Edit: Werde heute Abend nochmal schauen ob Fastboot aktiviert ist...

Mmh... nie probiert ehrlicherweise

Habe leider kein Hibernate im SleepPlugin...
Version 3.0.10
von Darkside40

Vorhin Strom wieder an BIOS EInstellungen überprüft (bBilder folgen noch), gewartet auf autom. sleep, zack., abgestürtzt...

Dann wieder eingeschaltet, wollte auf Hibernate umstellen (siehe oben), BIOS noch bisschen was anders umgestellt, C-States von C7 auf "Auto" wieder.
Dann mal manuell in sleep versetzt über die WebGui.. natürlich lief es, nicht aufgehängt nichts, und konnte direkt wieder wecken... *GRML*

Er geht ja „theoretisch“ schlafen. Hängt sich da aber komplett auf. Also, wie beschrieben, Lüfter drehen normal und 20-30 Watt verbraucht. Ist aber, laut LED im sleep.

Logs steht natürlich nichts drin, da der sleep Befehl geklappt hat

Aber ja, Logs stelle ich dann nochmal zur Verfügung wenn da jemand wurschteln mag.

Hier die Bilder der bios Änderungen von heute…

Die erste Änderung, hier hat er sich dann auch wieder aufgehängt…

Und dann nochmal die zweite Änderung, hier ging es zumindest nach einem manuellen sleep Befehl über die gui…

Unraid will mich echt trollen...

Logs sind im Anhang...
syslog-previous ist das Log, bevor ich ihn heute morgen ausschalten musste, weil mal wieder aufgehöngt, und syslog das "neue",m dann von heute morgen.
In syslog-previous hat der sleep (auch im "automatik" modus) um 19:25 Uhr wunderbar geklappt, aufgeweckt gegen 20:25 Uhr wieder...
Heute nacht dann ging er wieder schlafen, so gegen 0:23 Uhr, dann wurde er scheinbar instant wieder geweckt, dann 0:24 Uhr, da lief er dann wieder, und dann hat er sich "aufgehängt".

Heute morgen dann um 5 Uhr (syslog, ohne -previous), ist dann das "neue" syslog nach dem ich ihn wieder eingeschaltet hab.

Dieses da, um 0:23/0:24 irritiert mich total, das kam um 19:25 Uhr nicht (also, die zeilen zwischen den "PM" Meldungen:

Aug 27 00:23:54 MyServer kernel: PM: suspend entry (deep)
Aug 27 00:23:55 MyServer emhttpd: read SMART /dev/sde
Aug 27 00:24:25 MyServer kernel: Filesystems sync: 10.837 seconds
Aug 27 00:24:25 MyServer kernel: Freezing user space processes
Aug 27 00:24:25 MyServer kernel: Freezing of tasks failed after 20.008 seconds (1 tasks refusing to freeze, wq_busy=0):
Aug 27 00:24:25 MyServer kernel: task:emhttpd         state:D stack:0     pid:6318  ppid:1      flags:0x00004006
Aug 27 00:24:25 MyServer kernel: Call Trace:
Aug 27 00:24:25 MyServer kernel: <TASK>
Aug 27 00:24:25 MyServer kernel: __schedule+0x5b2/0x612
Aug 27 00:24:25 MyServer kernel: schedule+0x8e/0xcc
Aug 27 00:24:25 MyServer kernel: request_wait_answer+0xf7/0x1d3
Aug 27 00:24:25 MyServer kernel: ? _raw_spin_rq_lock_irqsave+0x20/0x20
Aug 27 00:24:25 MyServer kernel: fuse_simple_request+0x1b0/0x1ef
Aug 27 00:24:25 MyServer kernel: fuse_dentry_revalidate+0x140/0x2ce
Aug 27 00:24:25 MyServer kernel: lookup_fast+0x97/0xc0
Aug 27 00:24:25 MyServer kernel: walk_component+0x42/0xca
Aug 27 00:24:25 MyServer kernel: path_lookupat+0x78/0xfe
Aug 27 00:24:25 MyServer kernel: filename_lookup+0x5f/0xbc
Aug 27 00:24:25 MyServer kernel: ? getname_flags+0x29/0x152
Aug 27 00:24:25 MyServer kernel: ? kmem_cache_alloc+0x122/0x14d
Aug 27 00:24:25 MyServer kernel: user_path_at_empty+0x37/0x4f
Aug 27 00:24:25 MyServer kernel: path_getxattr+0x47/0xb1
Aug 27 00:24:25 MyServer kernel: do_syscall_64+0x65/0x7b
Aug 27 00:24:25 MyServer kernel: entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Aug 27 00:24:25 MyServer kernel: RIP: 0033:0x145eb3a2916a
Aug 27 00:24:25 MyServer kernel: RSP: 002b:0000145eb3513d88 EFLAGS: 00000202 ORIG_RAX: 00000000000000bf
Aug 27 00:24:25 MyServer kernel: RAX: ffffffffffffffda RBX: 0000145eb3514cdc RCX: 0000145eb3a2916a
Aug 27 00:24:25 MyServer kernel: RDX: 0000145ea800ec10 RSI: 00000000005ae80e RDI: 0000145ea800c510
Aug 27 00:24:25 MyServer kernel: RBP: 0000145eb3513db0 R08: 0000145ea80007a0 R09: 0000145ea80007a0
Aug 27 00:24:25 MyServer kernel: R10: 0000000000001000 R11: 0000000000000202 R12: ffffffffffffff80
Aug 27 00:24:25 MyServer kernel: R13: 0000000000000002 R14: 00007ffc8836b910 R15: 0000145eb3314000
Aug 27 00:24:25 MyServer kernel: </TASK>
Aug 27 00:24:25 MyServer kernel: OOM killer enabled.
Aug 27 00:24:25 MyServer kernel: Restarting tasks ... done.
Aug 27 00:24:25 MyServer kernel: random: crng reseeded on system resumption
Aug 27 00:24:25 MyServer kernel: PM: suspend exit

Mmmmh...
Und als Lösung, was ich dagegen tun kann?
Ich meine, der Task der Probleme verursacht ist anscheinend emhttpd. Aber soweit ich weiß, ist das Bestandteil von Unraid, oder ist das Emby? oO
Falls Emby, das läuft ja im Docker, und ich stoppe meine Docker manuell vor dem Sleep (==> s3_PrepareToSleep: Stopping Docker Emby)

Mmmh...
Evtl. könnte es ja helfen per Script die emhttpd zu "killen" vorher
Keine Ahnung...