DS212j und synoindexd - 100% Last

[mr coffee]

Hallo,

ich benötige mal ein paar Erfahrungswerte, hier erstmal mein Problem:
Ich habe eine neue DS212j (neuste DSM-Version) gekauft um meine Musik auf dieser auszulagern. Auf der DS ist nur DSaudio installiert, sonst nichts. Ich habe eine WD30EZRX eingebaut und meine Musik in den Ordner "music" kopiert. Das sind in etwa 2TB und war gegen Samstag Mittag (heute ist Montag Abend) fertig. Seitdem läuft die Indexierung, der Prozess synoindexd verursacht auf der DS 99% CPU-Last (die tatsächliche Last schwankt zwischen 80 und 99 Prozent abhängig von den anderen Prozessen) bei konstant 160MB RAM-Verbrauch.

Da ich ja nicht erkennen kann, wie der Fortschritt ist habe ich aktuell Zweifel, ob der Prozess nicht hängen geblieben ist. Meine Zweifel entstehen, da:

• der Ressourcen-Monitor mir sagt, dass 0 byte auf der Platte gelesen und geschrieben werden
• die Festplatten in den Ruhemodus gehen bei Nichtbenutzung
• die Musik zuvor auf meiner DS212+ lag, bei der ich solches Verhalten nicht erkennen konnte (allerdings über bind gemountet von ext. Festplatte)

Jetzt frage ich mich, hat jemand Erfahrungswerte wie lang die Indexierung für dieses Datenvolumen dauern kann? Die DS muss ja nichts konvertieren, also sollte es doch einigermaßen schnell gehen ...
Außerdem wäre es interessant ein logfile zu haben in welchem ich erkennen kann, wie weit der Prozess gekommen ist (die DS könnte ja Probleme mit möglicherweise vorhandenen zu tiefen Pfaden oder Umlauten haben, die ich eliminieren muss).

Jemand eine Idee, was ich tun kann? Danke.

Edit:
Ich habe mir jetzt mal per konsole "more /var/log/messages" das Logfile angesehen und siehe da, eine endlose Liste von:
synoindexd: audio_parse.cpp:512 Bad parameter.

Kann damit jemand was anfangen?

Edit2:
Ich habe nun den Service per "/usr/syno/etc/rc.d/S66synoindexd.sh restart" neugestartet und siehe da -> der Service arbeitet wieder.

Trotzdem wäre ich um ein paar Erfahrungswerte bzgl. der Dauer der Indexierung froh, außerdem würde ich gerne wissen wo die Indexdaten gespeichert werden.

Edit3:
Nach 15 Minuten bin ich wieder am Ausgangspunkt angelangt: 100% CPU-Last, kein READ/WRITE auf der HD und 160MB Ram-Verbrauch ...

 

[mr coffee]

So Jungs, ich gehe gerade der Sache auf den Grund, nachdem ich hier keine Rückmeldung bekommen habe und auch der Synology Support noch nicht geantwortet hat.

Folgendermaßen gehe ich vor:
ich habe für jedes Hauptverzeichnis unter meinem Music-Ordner einen neuen NICHT INDIZIERTEN gemeinsamen Ordner erstellt. Nach und nach habe ich die einzelnen Hauptverzeichnisse in ihre eigenen neuen nicht indizierten Ordner verschoben. Danach hab ich synoindexd jeweils neu gestartet. Das habe ich so lange gemacht, bis der Prozess nicht mehr hängengeblieben ist (sprich keine 100% CPU Last und 160MB RAM-Verbrauch). So konnte ich das Hauptverzeichnis, welches den Fehler verursacht hat identifizieren. Synoindexd hat ohne den Fehler nur wenige Minuten bei sehr geringer CPU-Last und 4MB Ram-Verbrauch gearbeitet, also ein eklatanter Unterschied.

Ich kopiere jetzt die Ordner dieses Verzeichnisses nach und nach wieder in den indizierten Ordner um rauszubekommen, wann der Fehler wieder auftritt. Wenn ich irgendwas sinnvolles rausbekomme (also irgendwas in der Art wie Sonderzeichen "xyz" macht Probleme, die maximale Ordnertiefe ist ... usw.) melde ich mich wieder.

 

[Trolli]

Früher hat sich der Indexprozess schonmal bei Playlisten aufgehängt, die auf nicht mehr existente Musikstücke verwiesen haben. Ich hätte aber eigentlich gedacht, dass das schon lange behoben wäre.

 

[mr coffee]

Jo danke Trolli für dein Post, aber das war nicht das Problem. Ich habe in einem Verzeichnis ein Album mit defekten .flac-Files gehabt. Sobald dieses Verzeichnis in ein indiziertes Verzeichnis kopiert wird, hängt sich synoindexd auf (es hilft auch nicht, nur die Dateien wieder weg zu schieben, der Dienst muss zusätzlich neu gestartet werden).

Sollte man Synology so ein defektes FLAC-File zukommen lassen, damit die evtl. ihre Indizierung darauf anpassen können?

Edit: Ich habe jetzt einfach mal bei Synology angefragt, mal sehen ob die sich für das Thema interessieren.

 

[Trolli]

Klar interessieren die sich dafür. Solche Fehler müssen behoben werden. Solche Prozesse sollten auch bei defekten Dateien nicht einfach abstürzen.