Bei Emby heißt die Option:

Bildmaterial in Medienordnern speichern

und unten drunter gibt es auch nochmal :

Eine Kopie der Bilder im Metadaten-Ordner des Servers zwischenspeichern

Das kannst du für jede angelegte Bibliothek einstellen.

Bei Jellyfin wird das ähnlich sein denke ich.

ja gibt es in Jellyfin ähnlich:

in den Bibliotheken

und generell

da hier nichts angeklickt/eingetragen ist, speichert er alle Infos unter /mnt/user/appdata/binhex-jellyfin/cache|data

daher frage ich mich, was ich noch vergessen habe, bzw. wieso beim scrollen durch jellyfin doch hin und wieder HDDs anspringen.....

aber wirklich stören tut es mich nicht, wenn ich da rumstöber will ich ja i.d.R. auch was schauen ;)

und dann machen es die unnötigen 5W/15min einer HDD im Vergleich zum laufenden Heimkino dann auch nicht mehr....

Ne, da kann ich dir dann leider auch nicht wirklich helfen sorry.

Genug Offtopic denke ich.

Mam59 wird mein Vorschlag eh zuviel Arbeit sein denke ich 🙃

8 hours ago, Gepelmario said:

du könntest dein Problem auch ganz anders lösen und Jellyfin oder Emby mit dem entsprechenden Plugin für Kodi nutzen,

Aber das löst doch das Problem mit den Startupgruppen überhaupt nicht, es mag zwar für diesen speziellen Einsatzzweck die Zugriffe dämpfen, aber das kann mit anderen Anwendungen dann wieder anders aussehen.

Filme & Serien sind ein Beispiel, auf dem Array liegt noch jede Menge anderer Kram rum.

Fakt ist: Startupgruppen versprechen, dass alle zugehörigen Platten zur gleichen Zeit schlafen gehen und wieder auffwachen. Das funktioniert nicht korrekt offensichtlich. Also muss das jemand mal nachgucken und hoffentlich fixen.

6 hours ago, Gepelmario said:

Mam59 wird mein Vorschlag eh zuviel Arbeit sein denke ich

Das hat nix mit Arbeit zu tun, allerdings kommen mir diese Streaming Programme wie Jellyfin, Plex usw. nicht ins Haus. Ich scrape EINMAL und verlasse mich dabei nicht (nur) auf Daten aus dem Internet. Die Clients mit Kodis (meist Raspberries) brauchen nix tun, nur "lokale Infos" anzeigen. Spart endlose Ressourcen.

On 7/29/2026 at 3:22 PM, MAM59 said:

Wie eskalieren wir das Problem nun weiter???

bliebe ja nur ein bug report, wundert mich zwar irgendwie da ja die Hardware sagt "kein spindown möglich" und die Startup Gruppen ja "eigentlich" nichts damit zu tun haben sollten, läuft ja außerhalb davon ... aber, die Erfahrung zeigt, es ist wohl so ;)

Vorausgesetzt, die besagte disk spinned aktuell genau so oft hoch wie in der Gruppe, zum Ausschluss würde ich die einfach mal noch ein paar mal hochfahren lassen, in den auto spindown gehen lassen usw usw ... nur um sicher zu sein das es nicht an X spinups liegt und dann die Hardware sagt "ist nicht".

1 minute ago, alturismo said:

Vorausgesetzt, die besagte disk spinned aktuell genau so oft hoch wie in der Gruppe, zum Ausschluss würde ich die einfach mal noch ein paar mal hochfahren lassen, in den auto spindown gehen lassen usw usw ... nur um sicher zu sein das es nicht an X spinups liegt und dann die Hardware sagt "ist nicht".

Ich kann ihr ja noch ne Woche Frist geben, das "Problem" existiert eh schon ein paar Jahre, da kommt es auf ein paar Wochen nicht an.

Ich habe gerade Deine ersten Posts geschaut und da fiel mir auf, dass alle Ordner den selben Zeitstempel haben. Wie kann das sein? Läuft da ggfs. ein Job zeitgesteuert der alle Platten anpackt? Nur so eine Frage.

Zum Thema Streaming, Startup Gruppen, Plex und Konsorten: Wie ich gelesen habe nutzt Du Startup Gruppen da das nacheinander Hochfahren der Platten nervt. Deshalb nutze ich seit einem Dutzend Jahren die Disk Shares. In meinem Plex, oder Deinen Werkzeugen, kann man meist mehrere Verzeichnisse angeben. Wenn man statt mit /mnt/user/Content mit /mnt/disk1/Content, /mnt/disk2/Content, etc arbeitet, dann passiert das nicht mehr. Das Werkzeug kennt dann die exakte Platte und wird nur diese konkret ansprechen. In meinem Plex sind fast 200 Verzeichnisse hinterlegt, das kratzt Plex nicht die Bohne - und das wird bei Deinen Werkzeugen auch so sein. Wenn Du User Shares und Disk Shares gleichzeitig aktiv hast dann könntest Du z.B. auf user Schreiben und von user oder disk Lesen. Auf disk würde ich nicht Schreiben, dass kann gefährlich werden und ist zu aufwändig. Ich weiß ist OT - aber hilft ggfs. um die Startup Gruppen locker zu umschiffen.

Edited July 31Jul 31 by hawihoney

12 minutes ago, hawihoney said:

Ich habe gerade Deine ersten Posts geschaut und da fiel mir auf, dass alle Ordner den selben Zeitstempel haben. Wie kann das sein

Ist auf allen Platten gleich, die Verzeichnisse auf Top Ebene haben alle denselben Zeitstempel. Keine Ahnung, wer oder was das macht. Mover? Cache_dirs? Es hindert die anderen Platten auf jeden Fall nicht daran, sich schlafen zu legen und im Moment (ohne Startupgruppen) ist auch disk4 brav, obwohl der Zeitstempel mit den anderen übereinstimmt.

19 minutes ago, hawihoney said:

Wenn man statt mit /mnt/user/Content mit /mnt/disk1/Content, /mnt/disk2/Content, etc arbeitet, dann passiert das nicht mehr

Mag sein, aber damit verzichtet man ja auf ein Hauptfeature von UNRAID: das DATENGRAB! Ich hab keine Lust, mich darum zu kümmern, WO eine Datei ist, ich werf sie einfach in die Freigabe, die Verteilung macht UNRAID. Und so ein- zweimal im Jahr lasse ich dann noch den großen Balancer drüberlaufen, damit die Platten symmetrisch ausgelastet werden (und nicht bis zum Rand, wo sie anfangen zu schnarchen).

Und, wie schon öfters erwähnt, ich suche keinen Workaround, sondern einen Fix.

1 hour ago, MAM59 said:

Mag sein, aber damit verzichtet man ja auf ein Hauptfeature von UNRAID: das DATENGRAB!

Falsch. Du kombinierst (aktivierst) beide Share Arten. Du hast nach wie vor Dein Datengrab in /mnt/user/ umgehst aber für ausgewählte Werkzeuge/Arbeitsabläufe mit den Disk Shares, z.B. beim Abspielen, das kaskadierende Wecken.

Aber egal. Jeder so wie es für ihn passt.

3 hours ago, hawihoney said:

Falsch. Du kombinierst (aktivierst) beide Share Arten. Du hast nach wie vor Dein Datengrab in /mnt/user/ umgehst aber für ausgewählte Werkzeuge/Arbeitsabläufe mit den Disk Shares, z.B. beim Abspielen, das kaskadierende Wecken.

mal abgesehen davon dass das auch unter /mnt/user so sein sollte (und hier auch so ist) das nur die benötigte disk in den spinup geht,
haben wir hier eh wohl eine etwas andere Basis.

bei @MAM59 liegen wahrscheinlich auch Fanarts in den Ordnern welche dann "verstreut" sind und nicht unbedingt auf der passenden disk wo auch der zugehörige Film oder die Serie liegt, daher das kaskadierende spinup Thema, daher würden hier disk Shares auch leider nichts bringen ....

Ich nutze das jetzt nicht in der Form, weder mit nfo files noch fanarts, plex, emby, ... haben Ihre Datenbank und Ihre Caches wo der Kram dann abgelegt ist, daher macht es für mich in der Form auch wenig Sinn, aber das ist "Glaubensfrage" und OT hier.

Bin echt gespannt wenn die disk mal öfters hoch und runter gefahren ist, den Zusammenhang begreife ich halt 0, würde mich auch frustrieren ;)

8 hours ago, alturismo said:

bei @MAM59 liegen wahrscheinlich auch Fanarts in den Ordnern welche dann "verstreut" sind und nicht

Gut geraten :-)

Ein Beispielfilmverzeichnis sieht so aus:

root@F:/mnt/user/Filme/Animation# ls -lRva Ronal\ der\ Barbar\ \(2011\)/

Ronal der Barbar (2011)/:

total 1568796

drwxrwxrwx 1 imagemaster users 29 Jan 11 2025 ./

drwxrwxrwx 1 nobody users 16384 Jul 2 06:02 ../

drwxrwxrwx 1 imagemaster users 34 Jan 10 2025 .actors/

-rwxrw-rw- 1 imagemaster users 1605901109 Mar 13 2023 Ronal\ der\ Barbar\ (2011).mkv*

-rwxrw-rw- 1 imagemaster users 6227 Jan 10 2025 Ronal\ der\ Barbar\ (2011).nfo*

-rwxrw-rw- 1 imagemaster users 196064 Jan 10 2025 Ronal\ der\ Barbar\ (2011)-fanart.jpg*

-rwxrw-rw- 1 imagemaster users 318449 Jan 10 2025 Ronal\ der\ Barbar\ (2011)-poster.jpg*

Ronal der Barbar (2011)/.actors:

total 1396

drwxrwxrwx 1 imagemaster users 34 Jan 10 2025 ./

drwxrwxrwx 1 imagemaster users 29 Jan 11 2025 ../

-rwxrw-rw- 1 imagemaster users 674115 Jan 10 2025 Allan_Olsen.jpg*

-rwxrw-rw- 1 imagemaster users 40800 Jan 10 2025 Anders_Juul.jpg*

-rwxrw-rw- 1 imagemaster users 89553 Jan 10 2025 Bodil_Jørgensen.jpg*

-rwxrw-rw- 1 imagemaster users 28746 Jan 10 2025 Brian_Lykke.jpg*

-rwxrw-rw- 1 imagemaster users 117093 Jan 10 2025 Brigitte_Nielsen.jpg*

-rwxrw-rw- 1 imagemaster users 25649 Jan 10 2025 César_Mourão.jpg*

-rwxrw-rw- 1 imagemaster users 35103 Jan 10 2025 Dee_Snider.jpg*

-rwxrw-rw- 1 imagemaster users 15665 Jan 10 2025 Hadi_Ka-Koush.jpg*

-rwxrw-rw- 1 imagemaster users 27604 Jan 10 2025 Jens_Jacob_Tychsen.jpg*

-rwxrw-rw- 1 imagemaster users 56608 Jan 10 2025 Jesper_Binzer.jpg*

-rwxrw-rw- 1 imagemaster users 36785 Jan 10 2025 Lars_Bom.jpg*

-rwxrw-rw- 1 imagemaster users 36384 Jan 10 2025 Lars_Mikkelsen.jpg*

-rwxrw-rw- 1 imagemaster users 43292 Jan 10 2025 Lærke_Winther.jpg*

-rwxrw-rw- 1 imagemaster users 19631 Jan 10 2025 Ole_Ernst.jpg*

-rwxrw-rw- 1 imagemaster users 23445 Jan 10 2025 Ole_Thestrup.jpg*

-rwxrw-rw- 1 imagemaster users 28116 Jan 10 2025 Preben_Kristensen.jpg*

-rwxrw-rw- 1 imagemaster users 107999 Jan 10 2025 Sven-Ole_Thorsen.jpg*

Es enhält also Film, NFO, Fanarts, Poster und ein UV ".actors" mit den Bildern der Beteiligten.

Kodi "scraped" den Kram dann in eine zentrale MySQL Datenbank, die von allen Klienten benutzt wird.

Aber ich bin ein Fan von KISS (keep it simple stupid!) und erhalte die Originaldaten damit auch andere Programme direkt damit arbeiten können und man Änderungen zur Not auch manuell vornehmen kann.

Und ja, das ist eine "Glaubensfrage", ich glaube nicht an mysteriöse Datenbanken :-)))

(Platte 4 geht immer noch brav aus, wenn ihr dazu geheissen wird :-) )

@JorgeB when we look at all this (i am out of ideas here)

do you have any idea why this only happens when the disk is set in a startup group?

i don't see a causal link... If not, what would be needed for a meaningful bug report?

1 hour ago, alturismo said:

do you have any idea why this only happens when the disk is set in a startup group?

Not really, seems very odd.

1 hour ago, alturismo said:

what would be needed for a meaningful bug report?

@MAM59 Before creating a bug report please post the steps needed to reproduce this; I can then test if it's a general problem.

1 minute ago, JorgeB said:

@MAM59 Before creating a bug report please post the steps needed to reproduce this; I can then test if it's a general problem.

Simple, just create a startup group, put all array members including parity into that group and wait.

After a few days, maybe a week or so, one drive starts to deny spindown.

The only "visible" clue is that "status 1" returned by the spindown command and reported in the logs.

Maybe it is just a timing problem, I guess, UNRAID tries to spindown all my 6 drives one by one in a loop and sets a timeout for the action. Maybe this one drive is sometimes too slow to react or something like that?!??!?

maybe a simple "sleep 1" in the loop could help? (but I cannot find the loop, else I would test it)

It seems very odd to me that if there's a bug with that, it would always affect the same disk, but I'll try to repro as soon as I can.

1 minute ago, JorgeB said:

It seems very odd to me that if there's a bug with that

I agree, but I have monitored it over a long period now altready. It is totally reproducable here.

At first, I thought it would be "always the last disk in the array", but a few months ago I have added another drive and now the "semi-last" disk (previous last one) is affected.

I will turn on startup groups today again and watch when it happens once more

Oh! I just had the idea of a different approach that MIGHT give new hints:

• I create a startup group

• I add ALL drives BUT the suspicious one (disk4)

Then we will see:

• does a different drive show the same erratic behaviour?

• is disk4 still manually controllable ?

Lets run it for a week and then rethink...

Edited August 1Aug 1 by MAM59

Still everything is working as it should be.

The startup group spins down correctly, disk4 spins down on its own or if manually ordered to spin down.

I guess, the only problem arises, if disk4 is part of the startup group, for whatever reason.

Although strange, I think this problem is just here locally, I have to live with it. So I will stop further investigations now unless somebody has considerations for another test scenario that might help to pin down the culprit.

@JorgeB ? ? ?

It does sound more like a specif issue, not a general one, but I'll keep an eye out for any similar issues, also try to repro myself.