externe USB HDDs per symlink in video-Verzeichnis / synoindexd out of memory

[kotellettenhorst]

Hallo community,

ich habe folgendes Problem bei der Konfiguration meiner DS109:
3 externe HDDs per USB angeschlossen - WD MyBook 500GB (Backup-Laufwerk), WD MyBook 1TB (Medien1, 30% belegt) und WD MyBook Mirror 1TB (Medien2, 95% belegt), alle vor dem Befüllen über Web-Schnittstelle auf ext3 formatiert.
Im Verzeichnis /volume1/video habe ich dann mittels ln -s zwei symbolische Links (/volume1/video/Filme1 -> /volumeUSB2/usbshare/Filme und /volume1/video/Filme2 -> /volumeUSB3/usbshare/Filme) angelegt und anschließend die Indexierung neu gestartet.
Nach einer Weile wird die DS jedoch sehr langsam obwohl der Indexierungsprozess abgeschlossen scheint (keine HDD Aktivität mehr). Kontrolle der Prozesse per ssh bestätigen diese Annahme. Ein Blick auf /var/log/messages zeigt, dass sich die DS beim Indexieren wohl irgendwie verschluckt hat, weil nach einer gewissen Zeit out of memory Fehler angezeigt werden.
Ich habe daraufhin den Symlink zur volleren Platte wieder aus dem video-Verzeichnis entfernt und siehe da, nach einem Neustart läuft die Indexierung problemlos durch.

Gibt es im Allgemeinen Probleme mit der DS und großen Medien-Archiven oder kann man die Indexierung irgendwie beeinflussen, dass diese sich nicht mehr den Speicher so vollhaut? Oder gibt es evtl. Probleme mit Dateien ab einer gewissen Größe oder mit bestimmten Medienformaten?
Lassen sich diese Probleme vielleicht umgehen, wenn man statt symlink mit mount arbeitet? (die symlinks erscheinen übrigens im Filemanager nicht unter dem video Verzeichnis. Ist dies mit dem mount Befehl möglich?)

Vielen Dank schon mal für eure Hilfe!


Hier nochmal der Auszug aus /var/log/messages:

Aug 17 19:56:46 kernel: scemd invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Aug 17 19:56:46 kernel: [<c002999c>] (dump_stack+0x0/0x14) from [<c0074a6c>] (oom_kill_process+0x5c/0xf0)
Aug 17 19:56:46 kernel: [<c0074a10>] (oom_kill_process+0x0/0xf0) from [<c0074ec0>] (out_of_memory+0x188/0x1d8)
Aug 17 19:56:46 kernel:  r7:c4074000 r6:c03050a8 r5:c75083c0 r4:c75cc340
Aug 17 19:56:46 kernel: [<c0074d38>] (out_of_memory+0x0/0x1d8) from [<c007711c>] (__alloc_pages+0x270/0x2f4)
Aug 17 19:56:46 kernel: [<c0076eac>] (__alloc_pages+0x0/0x2f4) from [<c00790b0>] (__do_page_cache_readahead+0xd0/0x214)
Aug 17 19:56:46 kernel: [<c0078fe0>] (__do_page_cache_readahead+0x0/0x214) from [<c0079658>] (do_page_cache_readahead+0x6c/0x74)
Aug 17 19:56:46 kernel: [<c00795ec>] (do_page_cache_readahead+0x0/0x74) from [<c0073670>] (filemap_fault+0x178/0x398)
Aug 17 19:56:46 kernel:  r7:c7518be0 r6:c72a8650 r5:00000000 r4:00000fff
Aug 17 19:56:46 kernel: [<c00734f8>] (filemap_fault+0x0/0x398) from [<c007e864>] (__do_fault+0x6c/0x42c)
Aug 17 19:56:46 kernel: [<c007e7f8>] (__do_fault+0x0/0x42c) from [<c007f860>] (handle_mm_fault+0x2dc/0x61c)
Aug 17 19:56:46 kernel: [<c007f584>] (handle_mm_fault+0x0/0x61c) from [<c002c2e8>] (do_page_fault+0xe4/0x224)
Aug 17 19:56:46 kernel: [<c002c204>] (do_page_fault+0x0/0x224) from [<c002c4d4>] (do_translation_fault+0x18/0x88)
Aug 17 19:56:46 kernel: [<c002c4bc>] (do_translation_fault+0x0/0x88) from [<c00241a4>] (do_PrefetchAbort+0x18/0x1c)
Aug 17 19:56:46 kernel:  r5:00027d18 r4:ffffffff
Aug 17 19:56:46 kernel: [<c002418c>] (do_PrefetchAbort+0x0/0x1c) from [<c0024f60>] (ret_from_exception+0x0/0x10)
Aug 17 19:56:46 kernel: Exception stack(0xc4075fb0 to 0xc4075ff8)
Aug 17 19:56:46 kernel: 5fa0:                                     bed9f8dc 00000008 00000002 bed9fc5c 
Aug 17 19:56:46 kernel: 5fc0: 00027d18 00027d18 00000001 bed9fcdd 00000001 00000000 bed9f8dc bed9fcbc 
Aug 17 19:56:46 kernel: 5fe0: 00027248 bed9f8d0 00016228 4005cf08 80000010 ffffffff                   
Aug 17 19:56:46 kernel: Mem-info:
Aug 17 19:56:46 kernel: DMA per-cpu:
Aug 17 19:56:46 kernel: CPU    0: Hot: hi:   42, btch:   7 usd:  36   Cold: hi:   14, btch:   3 usd:   2
Aug 17 19:56:46 kernel: Active:13802 inactive:13708 dirty:0 writeback:0 unstable:0
Aug 17 19:56:46 kernel:  free:1024 slab:1240 mapped:22 pagetables:568 bounce:0
Aug 17 19:56:46 kernel: DMA free:4096kB min:4096kB low:8192kB high:16384kB active:55208kB inactive:54832kB present:130048kB pages_scanned:175789 all_unreclaimable? yes
Aug 17 19:56:46 kernel: lowmem_reserve[]: 0 0 0
Aug 17 19:56:46 kernel: DMA: 2*4kB 5*8kB 5*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 4096kB
Aug 17 19:56:46 kernel: Swap cache: add 138411, delete 138411, find 3458/4382, race 0+0
Aug 17 19:56:46 kernel: Free swap  = 0kB
Aug 17 19:56:46 kernel: Total swap = 522104kB
Aug 17 19:56:46 kernel: Free swap:            0kB
Aug 17 19:56:46 kernel: 32768 pages of RAM
Aug 17 19:56:46 kernel: 1260 free pages
Aug 17 19:56:46 kernel: 1131 reserved pages
Aug 17 19:56:46 kernel: 1240 slab pages
Aug 17 19:56:46 kernel: 573 pages shared
Aug 17 19:56:46 kernel: 0 pages swap cached
Aug 17 19:56:46 kernel: Out of memory: kill process 1354 (postgres) score 21704 or a child
Aug 17 19:56:46 kernel: Killed process 1356 (postgres)
Aug 17 19:56:51 kernel: sshd invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Aug 17 19:56:53 kernel: [<c002999c>] (dump_stack+0x0/0x14) from [<c0074a6c>] (oom_kill_process+0x5c/0xf0)
Aug 17 19:56:53 kernel: [<c0074a10>] (oom_kill_process+0x0/0xf0) from [<c0074ec0>] (out_of_memory+0x188/0x1d8)
Aug 17 19:56:53 kernel:  r7:c7af4000 r6:c03050a8 r5:c75083c0 r4:c75cc340
Aug 17 19:56:53 kernel: [<c0074d38>] (out_of_memory+0x0/0x1d8) from [<c007711c>] (__alloc_pages+0x270/0x2f4)
Aug 17 19:56:53 kernel: [<c0076eac>] (__alloc_pages+0x0/0x2f4) from [<c00790b0>] (__do_page_cache_readahead+0xd0/0x214)
Aug 17 19:56:53 kernel: [<c0078fe0>] (__do_page_cache_readahead+0x0/0x214) from [<c0079658>] (do_page_cache_readahead+0x6c/0x74)
Aug 17 19:56:53 kernel: [<c00795ec>] (do_page_cache_readahead+0x0/0x74) from [<c0073670>] (filemap_fault+0x178/0x398)
Aug 17 19:56:53 kernel:  r7:c76cd420 r6:c729fcd8 r5:00000000 r4:00000fff
Aug 17 19:56:53 kernel: [<c00734f8>] (filemap_fault+0x0/0x398) from [<c007e864>] (__do_fault+0x6c/0x42c)
Aug 17 19:56:53 kernel: [<c007e7f8>] (__do_fault+0x0/0x42c) from [<c007f860>] (handle_mm_fault+0x2dc/0x61c)
Aug 17 19:56:53 kernel: [<c007f584>] (handle_mm_fault+0x0/0x61c) from [<c002c2e8>] (do_page_fault+0xe4/0x224)
Aug 17 19:56:53 kernel: [<c002c204>] (do_page_fault+0x0/0x224) from [<c002c4d4>] (do_translation_fault+0x18/0x88)
Aug 17 19:56:53 kernel: [<c002c4bc>] (do_translation_fault+0x0/0x88) from [<c00241a4>] (do_PrefetchAbort+0x18/0x1c)
Aug 17 19:56:53 kernel:  r5:000000e8 r4:ffffffff
Aug 17 19:56:53 kernel: [<c002418c>] (do_PrefetchAbort+0x0/0x1c) from [<c0024f60>] (ret_from_exception+0x0/0x10)
Aug 17 19:56:53 kernel: Exception stack(0xc7af5fb0 to 0xc7af5ff8)
Aug 17 19:56:53 kernel: 5fa0:                                     bed7a110 0006e680 00000010 40158948 
Aug 17 19:56:53 kernel: 5fc0: bed7a110 000000e8 00074710 00000ac0 00000abc 0006e608 0006e624 bed7a1e4 
Aug 17 19:56:53 kernel: 5fe0: 0005e470 bed7a108 00035884 4007ac74 80000010 ffffffff                   
Aug 17 19:56:53 kernel: Mem-info:
Aug 17 19:56:53 kernel: DMA per-cpu:
Aug 17 19:56:53 kernel: CPU    0: Hot: hi:   42, btch:   7 usd:   7   Cold: hi:   14, btch:   3 usd:   9
Aug 17 19:56:53 kernel: Active:13733 inactive:13757 dirty:0 writeback:0 unstable:0
Aug 17 19:56:53 kernel:  free:1022 slab:1232 mapped:6 pagetables:550 bounce:0
Aug 17 19:56:53 kernel: DMA free:4088kB min:4096kB low:8192kB high:16384kB active:54932kB inactive:55028kB present:130048kB pages_scanned:204090 all_unreclaimable? yes
Aug 17 19:56:53 kernel: lowmem_reserve[]: 0 0 0
Aug 17 19:56:53 kernel: DMA: 4*4kB 3*8kB 5*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 4088kB
Aug 17 19:56:53 kernel: Swap cache: add 138729, delete 138728, find 3476/4431, race 0+0
Aug 17 19:56:53 kernel: Free swap  = 0kB
Aug 17 19:56:53 kernel: Total swap = 522104kB
Aug 17 19:56:53 kernel: Free swap:            0kB
Aug 17 19:56:53 kernel: 32768 pages of RAM
Aug 17 19:56:53 kernel: 1232 free pages
Aug 17 19:56:53 kernel: 1131 reserved pages
Aug 17 19:56:53 kernel: 1232 slab pages
Aug 17 19:56:53 kernel: 305 pages shared
Aug 17 19:56:53 kernel: 1 pages swap cached
Aug 17 19:56:53 kernel: Out of memory: kill process 1354 (postgres) score 17537 or a child
Aug 17 19:56:53 kernel: Killed process 1357 (postgres)
Aug 17 19:56:53 kernel: dms invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Aug 17 19:56:53 kernel: [<c002999c>] (dump_stack+0x0/0x14) from [<c0074a6c>] (oom_kill_process+0x5c/0xf0)
Aug 17 19:56:53 kernel: [<c0074a10>] (oom_kill_process+0x0/0xf0) from [<c0074ec0>] (out_of_memory+0x188/0x1d8)
Aug 17 19:56:53 kernel:  r7:c7418000 r6:c03050a8 r5:c75083c0 r4:c75cc340
Aug 17 19:56:53 kernel: [<c0074d38>] (out_of_memory+0x0/0x1d8) from [<c007711c>] (__alloc_pages+0x270/0x2f4)
Aug 17 19:56:53 kernel: [<c0076eac>] (__alloc_pages+0x0/0x2f4) from [<c00790b0>] (__do_page_cache_readahead+0xd0/0x214)
Aug 17 19:56:53 kernel: [<c0078fe0>] (__do_page_cache_readahead+0x0/0x214) from [<c0079658>] (do_page_cache_readahead+0x6c/0x74)
Aug 17 19:56:53 kernel: [<c00795ec>] (do_page_cache_readahead+0x0/0x74) from [<c0073670>] (filemap_fault+0x178/0x398)

 

[kotellettenhorst]

Der Text in messages geht noch ca. 30000 Zeichen so weiter, weswegen er für das Forum zu lang ist, aber er endet wie folgt:

Aug 17 19:57:47 kernel: Mem-info:
Aug 17 19:57:47 kernel: DMA per-cpu:
Aug 17 19:57:47 kernel: CPU    0: Hot: hi:   42, btch:   7 usd:  34   Cold: hi:   14, btch:   3 usd:   6
Aug 17 19:57:47 kernel: Active:13810 inactive:13786 dirty:0 writeback:0 unstable:0
Aug 17 19:57:47 kernel:  free:1022 slab:1204 mapped:6 pagetables:477 bounce:0
Aug 17 19:57:47 kernel: DMA free:4088kB min:4096kB low:8192kB high:16384kB active:55240kB inactive:55144kB present:130048kB pages_scanned:222390 all_unreclaimable? yes
Aug 17 19:57:47 kernel: lowmem_reserve[]: 0 0 0
Aug 17 19:57:47 kernel: DMA: 16*4kB 3*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 4088kB
Aug 17 19:57:47 kernel: Swap cache: add 140191, delete 140191, find 3508/4561, race 0+0
Aug 17 19:57:47 kernel: Free swap  = 0kB
Aug 17 19:57:47 kernel: Total swap = 522104kB
Aug 17 19:57:47 kernel: Free swap:            0kB
Aug 17 19:57:47 kernel: 32768 pages of RAM
Aug 17 19:57:47 kernel: 1228 free pages
Aug 17 19:57:47 kernel: 1131 reserved pages
Aug 17 19:57:47 kernel: 1204 slab pages
Aug 17 19:57:47 kernel: 258 pages shared
Aug 17 19:57:47 kernel: 0 pages swap cached
Aug 17 19:57:47 kernel: Out of memory: kill process 1523 (synoindexd) score 862 or a child
Aug 17 19:57:47 kernel: Killed process 1523 (synoindexd)

 

[itari]

In welchem Format sind denn die externen Platten formatiert? Als ext3?

Itari

 

[kotellettenhorst]

jo, alle ext3.
habe ich über die web-Schnittstelle des Syno-Managers formatiert..

 

[itari]

Vielleicht sind einiger Formate deiner Dateien nicht ganz ok ... aus dem Log-File geht auf jeden Fall hervor, dass dein Swap-Space nicht ausreicht und deswegen die Prozesse weg brechen ... auch scheint der Postgres Probleme zu machen ... kann es sein, dass du zu wenig Platz auf den Platten hast? Mach mal einen df

Itari

 

[kotellettenhorst]

das wäre ne Möglichkeit, die externe HDD, bei der es Probleme gibt, ist mit 95-98% belegt (genauere Werte per df kann ich nachher mal liefern).
Ich kann ja mal probieren, zuvor einige GB auf eine andere Platte zu lagern und dann die Indexierung nochmal laufen zu lassen.

Gibt es eigentlich eine Möglichkeit, nicht die komplette Indexierung neu zu starten, sondern nur ein neues Verzeichnis hinzuzufügen? Dann bräuchte nicht neu das ganze audio und photos Verzeichnis indexiert werden...

 

[jahlives]

Den "durchdrehenden" synoindexd kenne ich von meiner DS408 her. Dort kommt es immer wieder mal vor, dass nach einem Neustart der synoindex vollkommen ausser Kontrolle gerät und sich den gesamten Speicher inkl SWAP unter die Nägel reisst. Dabei werden auch diverse andere Dienste abgeschossen, Postgres ist dabei immer einer der ersten Kanditaten, die abgeschossen werden. Synology konnte mir bis heute ned helfen, obwohl sich der Support bereits mehrfach eingeloggt hat.
Ich konnte den Fehler nur verhindern, indem ich komplett auf synoindex verzichtet habe. Ich habe auf der DS keine verlinkten Daten, sondern alles mittels mount --bind eingebunden.

 

[kotellettenhorst]

Das wäre ja äußerst schade, wenn sich das nicht in den Griff kriegen ließe..

Ich konnte den Fehler nur verhindern, indem ich komplett auf synoindex verzichtet habe. Ich habe auf der DS keine verlinkten Daten, sondern alles mittels mount --bind eingebunden.

a) wie kann man denn die Indexierung deaktivieren?
b) wenn man die Indexierung abgestellt hat, funktionieren denn dann die Streaming-Dienste (UPNP, Itunes, etc...) noch ordnungsgemäß oder kommen die anderweitig nicht an die Daten?

 

[jahlives]

a) am einfachsten indem du der Startdatei des synoindexd die Ausführrechte entziehst
b) UPnP und itunes werden dann wohl nicht mehr korrekt laufen. Was mich aber in meinem Fall nicht stört, da ich diese Dienste nicht benutze. Vermutlich wird aber auch die Photo- und Audiostation nicht mehr korrekt (wenn überhaupt noch) funzen

 

[itari]

b) UPnP und itunes werden dann wohl nicht mehr korrekt laufen.

Ist der Index-Dienst nicht nur dafür da, die Dateien zu katalogisieren und findbar/benutzbar zu machen? Ich wüsste nicht, wozu der sonst noch gut wäre. Wenn man also seine Dateien indiziert bekommen hat und keine neuen Dateien hinzufügt, dann müsste meinem Gefühl nach, UPnP usw. ohne Probs laufen auch wenn der Index-Dienst aus ist. Oder überseh ich hier was?

Itari

 

[jahlives]

Ist der Index-Dienst nicht nur dafür da, die Dateien zu katalogisieren und findbar/benutzbar zu machen? Ich wüsste nicht, wozu der sonst noch gut wäre. Wenn man also seine Dateien indiziert bekommen hat und keine neuen Dateien hinzufügt, dann müsste meinem Gefühl nach, UPnP usw. ohne Probs laufen auch wenn der Index-Dienst aus ist. Oder überseh ich hier was?

Itari

Stimmt wenn sie einmal indiziert sind und keine neuen Dateien hinzukommen, dann sollte es auch ohne synoindexd klappen. Problematisch ist, dass bei mir der synoindexd auch durchgedreht ist, als keine einzige neue Datei hinzugefügt wurde. Manchmal ist er aber auch korrekt durchgelaufen.
Das Durchdrehen war für mich nicht reproduzierbar. Manchmal trat es auf und manchmal auch nicht.

 

[itari]

Das Durchdrehen war für mich nicht reproduzierbar. Manchmal trat es auf und manchmal auch nicht.

Hast das mal dem Support gemailt gehabt?

Itari

 

[jahlives]

Hast das mal dem Support gemailt gehabt?

Itari

Gemailt an den Support mehrfach. Der Support ist auch mehrfach bei mir eingestiegen hat aber nicht wirklich etwas gefunden. Da ich auf der DS408 aber auch viele ipkg-SW laufen lasse und auch gewisse Einstellungen nicht mehr dem Installationsdefault entsprechen, hat Synology das Problem auf meine DS geschoben. Mir wars wie gesagt egal, da ich diese Dienste ned nutze und damit leben kann, dass synoindexd deaktiviert ist.
Da ich jetzt aber höre, dass dies auch bei anderen auftritt, wäre es vielleicht wiedermal an der Zeit den synoindexd anzuwerfen und auf den nächsten Crash zu warten. Und dann Synology nochmals anzuschreiben.

Gruss

tobi

 

[kotellettenhorst]

Ich würde die DS natürlich schon gerne mit allen Diensten nutzen, deswegen ist wohl das komplette Lahmlegen des Indexierdienstes für mich keine Option (Ich will die Platte ja gerade vernünftig indizieren, damit die Dateien per UPNP zur Verfügung stehen).
Da meine DS ansonsten sehr gut und stabil gelaufen ist und der Fehler nach Entfernen des einen Symlinks ja auch nicht mehr aufgetreten ist, ist es wohl sehr wahrscheinlich, dass das Problem irgendwie mit der Datenmenge zu tun hat - sei es nun eine zu volle Platte, zu große oder inkompatible Mediadateien oder ähnliches.
In jedem Fall sollte die DS aber eigentlich so schlau sein, dass entsprechende Dateien bei der Indexierung übersprungen werden oder die Indexierung bei Fehlern selbstständig abbricht (OHNE Amok zu laufen und MIT anständiger Fehlerrückmeldung)..

Ich probiere nachher noch mal einige Sachen aus und melde mich dann noch mal. Falls euch in der Zwischenzeit noch etwas einfällt, immer gerne her damit

 

[kotellettenhorst]

Hallo,

nun hatte ich ein wenig Zeit für ein paar Tests.
Zu Anfang hier kurz die Plattenbelegung und die Ausgabe von top:

DiskStation> df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1              2450928    318228   2107800  13% /
/tmp                     63296       200     63096   0% /tmp
/dev/hda3            304572468 127698556 176771512  42% /volume1
/volume1/@optware    304572468 127698556 176771512  42% /opt
/dev/sdk1            480719088 315456060 165160628  66% /volumeUSB1
/dev/sdl1            961432104 316680912 644648792  33% /volumeUSB2
/dev/sdm1            961424068 945772680  15548988  98% /volumeUSB3

DiskStation> top
Mem: 111432K used, 15160K free, 0K shrd, 5604K buff, 46696K cached
Load average: 0.00, 0.01, 0.00    (State: S=sleeping R=running, W=waiting)

  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
 3477 admin    S        21M  1354  0.0 17.1 postgres
 1356 admin    S        18M  1354  0.0 15.3 postgres
 1523 root     S N      13M     1  0.0 10.8 synoindexd
 4810 nobody   S       8764  4197  0.0  6.9 httpd
 4230 nobody   S       8652  4197  0.0  6.8 httpd
 4229 nobody   S       8224  4197  0.0  6.4 httpd
 4822 nobody   S       7856  4197  0.0  6.2 httpd
 4197 root     S       7072     1  0.0  5.5 httpd
 4231 nobody   S       6988  4197  0.0  5.5 httpd
 4225 admin    S       6512  1354  0.0  5.1 postgres
 4887 root     S       3432  3143  0.0  2.7 httpd
 4891 root     S       3356  3143  0.0  2.6 httpd
 4888 root     S       3340  3143  0.0  2.6 httpd
 5234 root     S       2952  3143  0.0  2.3 httpd
 3143 root     S       2936     1  0.0  2.3 httpd
 2564 root     S       2592     1  0.0  2.0 smbd
 1354 admin    S       2572     1  0.0  2.0 postgres
 5238 root     S       2572  3143  0.0  2.0 httpd
 1588 root     S       2308     1  0.0  1.8 nmbd

Dann habe ich alle Symlinks im video-Verzeichnis zunächst entfernt und nur einen auf ein Verzeichnis der 3ten USB HDD gelegt:

DiskStation> ls -l /volume1/video/
lrwxrwxrwx    1 root     root           31 Aug 19 18:59 Filme2 -> /volumeUSB3/usbshare/Filme/DVDs

Dann habe ich die Indexierung neu gestartet und parallel auf zwei ssh Sitzungen die Ausgaben von top und tail -f /var/log/messages beobachtet.
Während die DS der Indexdienst auf der internen HDD arbeitete, auf der sich ausschließlich Audiodateien (in /volume1/music) und Fotos (in /volume1/photos) befinden, lag die Speicherauslastung des synoindexd Prozesses stets bei um die 7-8% (also ca. 10MB).
Nach einiger Wartezeit kam dann der Spinup der externen HDD und der Indexdienst begann mit dem bearbeiten des video-Verzeichnisses. Auch hier zunächst nichts wirklich auffälliges, Speicherbedarf von synoindexd erhöhte sich leicht auf ca. 11-12%. Das ging dann einige Minuten gut, bis ganz urplötzlich die Speicherbelastung auf 70-80% hochgeschossen ist. Dann dauerte es nicht mehr lange, bis die bereits bekannten Fehlermeldungen kamen und ein Prozess nach dem anderen (bis hin zum synoindexd selbst) abgeschossen wurde.
Die Tatsache, dass die Speicherauslastung nicht sukzessiv sondern stark sprunghaft angestiegen ist, legt doch nahe, dass evtl. ein Problem mit bestimmten Dateien oder Verzeichnissen existiert. Dummerweise kommt vor dem out of memory keine Fehlermeldung, die auf den Ursprung des Problemes hinweist. Es kamen zwar zuvor des öfteren Fehlermeldungen wie

Aug 19 22:17:08 synoindexd: media.c (79) Failed to parse music metadata.
Aug 19 22:17:09 synoindexd: metamedia.c (124) Invalid stream type.
Aug 19 22:17:09 synoindexd: metamedia.c (31) Failed to get Misc Media Info from .....

aber das kam bei der anderen Platte auch ohne Ende und die Indexierung lief trotzdem ordnungsgemäß durch.

Die HDD Speicherbelegung ist danach genau wie zuvor, so dass ich nicht davon ausgehe, dass mangelnder Plattenplatz ein Problem ist (würde mich jedenfalls wundern).

Wie kann ich also rausfinden, bei welcher Datei synoindex die Segel streicht? Gibt es da eine Art verbose mode oder so?
Puh, für heute reichts mir erstmal.
Danke auf jeden Fall für eure bisherige Hilfe und für die hoffentlich noch kommenden zündenen Ideen

 

[kotellettenhorst]

So, ich hab eine gute und eine schlechte Nachricht:
die gute ist, dass ich das Problem auf mindestens eine Datei zurückführen kann und die schlechte ist, dass es sich deshalb wohl oder übel um einen Bug in der DS Software handeln muss.

Ich habe zuerst wieder alle Symlinks entfernt und die Indexierung einmal sauber durchlaufen lassen, um den definierten Ausgangspunkt zu haben.
Dann habe ich das DVD Verzeichnis wieder eingebunden (diesmal mit mount --bind, um auszuschließen dass das Problem nur bei Symlinks auftritt), aber NICHT die Indexierung komplett neu gestartet, sondern Schritt für Schritt mit synoindex -A [dir] ein Verzeichnis nach dem anderen hinzugefügt. Während synoindexd dann ackert habe ich wieder die Ausgaben von top und messages beobachtet.
Bei einem bestimmten DVD Verzeichnis trat das Problem dann wieder auf. Zuerst dachte ich, es läge an Umlauten im Verzeichnisname, aber ein Umbenennen ohne Umlaute produzierte den selben Fehler.
Anschließend bin ich in noch kleineren Schritten vorgegangen und habe die einzelnen Dateien des VIDEO_TS Folders nacheinander mit synoindex -a [file] hinzugefügt. Die ersten beiden VOBs gingen problemlos, aber bei der dritten trat das Problem auf.

Fällt jemandem dazu etwas ein??
Aber ich denke, das eigentliche Problem, welches die Indexierung mit bestimmten Mediendateien hat, kann wohl nur der harte Kern des Syno-Supports lösen..

 

[jahlives]

War es ein "besonderer" Dateiname bei dem der synoindexd auf die Schnauze gefallen ist? Eventuell besonders lang oder mit Leerzeichen? Sehen die Dateisystemrechte bei dieser Datei gleich aus, wie mit der Datei die noch gefunzt hat?

 

[itari]

und habe die einzelnen Dateien des VIDEO_TS Folders nacheinander mit synoindex -a [file] hinzugefügt. Die ersten beiden VOBs gingen problemlos, aber bei der dritten trat das Problem auf.

Hast mal mit XMedia Recode versucht die Datei anzufassen und zu konvertieren? Meist fällt XMedia auf die Nase, wenn irgendwas nicht ganz ok in der Daten ist ... MediaPlayer_in_the Box und VCL sind oft toleranter als sie sein sollten, so dass man von denen nicht unbedingt auf Fehler in Dateien aufmerksam gemacht wird.

Ansonsten ist es ein guter Gedanke sich mit dem Problem an den Synology Support zu wenden

Itari

 

[kotellettenhorst]

War es ein "besonderer" Dateiname bei dem der synoindexd auf die Schnauze gefallen ist? Eventuell besonders lang oder mit Leerzeichen? Sehen die Dateisystemrechte bei dieser Datei gleich aus, wie mit der Datei die noch gefunzt hat?

Das Problem kann wie gesagt nicht am Verzeichnisnamen liegen, da andere VOB Dateien in dem Verzeichnis problemlos indexiert werden können. Der Dateiname unterscheidet sich nur durch eine Ziffer (3 statt 2), weswegen auch das nicht die Ursache des Problems sein kann...

Hast mal mit XMedia Recode versucht die Datei anzufassen und zu konvertieren? Meist fällt XMedia auf die Nase, wenn irgendwas nicht ganz ok in der Daten ist ...

Guter Tipp, das Proggi kannte ich noch gar nicht.
Tatsächlich ist die fragliche VOB Datei wohl irgendwie kaputt: unter Videodaten zeigt XMedia Recode erst gar nichts an, unter Audio fehlen 2 von 3 streams. Die anderen VOBs sehen von den Infos her in Ordnung aus..
Kann XMedia das irgendwie fixen?

Tja, dann werd ich wohl nochmal Kontakt zum Syno-Support aufnehmen und denen meine Ergebnisse präsentieren..

Danke nochmal für eure Hilfe, ich geb Bescheid, wenn ich von denen ne Antwort habe..



p.s.:
Das ist jetzt etwas OT, aber für mich nicht uninteressant, falls es jemand weiß: kann XMedia Recode die Reihenfolge der Audio Streams in VOB Dateien ändern, ohne den ganzen Film neu encoden zu müssen?

 

[kotellettenhorst]

Cool, manchmal ist der Support mit der Lösung da bevor man überhaupt gefragt hat

Hab gesehen, dass ich noch FW .844 drauf hatte, im Download Center war aber seit Juli schon die FW .850 verfügbar, die Verbesserungen bei der Audio und Video Indizierung versprach...
Also Firmware aktualisiert, die Problemdatei indizieren lassen und siehe da, synoindexd läuft nicht mehr aus dem Ruder und erkennt anscheinend, dass er da Müll vor sich stehen hat..
Nun habe ich die Symlinks wieder erstellt und lasse jetzt die gesamte Indizierung noch mal durchlaufen. Bleibt nur zu hoffen, dass er nun durchläuft und nicht noch eine noch schlimmer verwurstelte Datei findet


Nochmal eine Frage wegen dem Einbinden: mir ist es nicht gelungen, die Einbindung mittels mound --bind in der rc.local beim Start hinzukriegen.
Ich habe die rc.local wie in einem anderen post von itari beschrieben erweitert mit

#!/bin/sh

# Optware setup
[ -x /etc/rc.optware ] && /etc/rc.optware start
[ -e /volumeUSB2/usbshare/Filme ] && mount --bind /volumeUSB2/usbshare/Filme /volume1/video/Filme1
[ -e /volumeUSB3/usbshare/Filme ] && mount --bind /volumeUSB3/usbshare/Filme /volume1/video/Filme2

exit 0

aber nach einem Neustart waren die mounts nicht da (Verzeichnisse sind natürlich vorhanden...).
wird die rc.local abgearbeitet, bevor die USB drives verfügbar sind oder hab ich da nen Fehler drin?
Wie ist das überhaupt so, besser symlink oder besser mount? Der einzige Vorteil, der mir zum mount einfallen würde, wäre, dass die Verzeichnisse auch im Web-Filemanager zu sehen sind..