Alle neuen VDR-Aufnahmen kaputt (auf NAS) - ERROR: skipped xxx bytes to sync on start of TS packet

  • Hallo,


    ich habe bei einem Client/Server-VDR-System in der Familie folgendes Problem:


    Alle neuen Aufnahmen enthalten Fehler. Geschätzte alle 10 bis 20 Minuten gibt es bei der Wiedergabe auf den Clients massive Bildaussetzer bis hin zum Stillstand. Ob es exakt periodisch auftritt, kann ich nicht sagen, sieht aber nicht so aus. Im Log hagelt es dann diese Meldungen:

    Code
    Nov  3 20:04:59 vdr vdr: [879] ERROR: skipped 26843 bytes to sync on start of TS packet
    Nov  3 20:04:59 vdr vdr: [879] ERROR: skipped 101460 bytes to sync on start of TS packet
    Nov  3 20:04:59 vdr vdr: [879] ERROR: skipped 101460 bytes to sync on start of TS packet
    Nov  3 20:04:59 vdr vdr: [879] ERROR: skipped 32309 bytes to sync on start of TS packet
    Nov  3 20:05:01 vdr vdr: [879] ERROR: skipped 16356 bytes to sync on start of TS packet
    Nov  3 20:05:01 vdr vdr: [879] ERROR: skipped 55599 bytes to sync on start of TS packet
    Nov  3 20:05:01 vdr vdr: [879] ERROR: skipped 101460 bytes to sync on start of TS packet
    Nov  3 20:05:01 vdr vdr: [879] ERROR: skipped 33129 bytes to sync on start of TS packet


    Der VDR-Server läuft unter der Version 1.7.26, BS ist LFS, und zeichnet über einen NFS-Mount auf einem Synology-NAS auf. Das Ganze funktionierte bisher auch tadellos, allerdings tritt seit einigen Monaten das beschriebene Problem auf. Eventuell könnte das mit einem Festplattentausch und Software-Update am NAS zusammenfallen, was aber nicht sicher zu klären ist. Allerdings gibt es ansonsten keine Probleme mit dem NAS und anderen Dateien dort (Samba-Shares).


    Getestet habe ich folgendes:
    Ich habe eine Aufnahme direkt auf der SSD des Servers aufgenommen und dort einen neuen Index vom VDR generieren lassen. => Keine Fehler!
    Dann habe ich die Aufnahme auf das NAS verschoben und wieder einen neuen Index generieren lassen. => Es kommt zu den beschriebenen Fehlern!


    Live-TV funktioniert absolut einwandfrei!


    Die Akzeptanz des Systems geht aktuell gegen Null (bis Abschaffung!) und ich habe keine Idee, wie das Aufnahmen-Problem zu beheben ist. Wer kann mir helfen?


    Liegt es evtl. an den Mount-Optionen (rw,_netdev,rsize=16384,wsize=16384)? Aber warum ging es dann vorher?



    Beste Grüße
    CafeDelMar

  • Also erstmal mußt du die Ursache finden. Platte oder Netzwerk oder RAM würde ich mal vermuten.
    Die Daten sehen total im Eimer aus. Der Sync TS kommt alle 188 Bytes.
    md5sum die Daten, lokal, dann auf dem Server und dann übers Netz. Auch mehrfach, ob sich der Wert ändert.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Also erstmal mußt du die Ursache finden. Platte oder Netzwerk oder RAM würde ich mal vermuten.
    Die Daten sehen total im Eimer aus. Der Sync TS kommt alle 188 Bytes.
    md5sum die Daten, lokal, dann auf dem Server und dann übers Netz. Auch mehrfach, ob sich der Wert ändert.


    Hallo Johns,


    schon mal vielen Dank für die Tipps.


    Ich habe es mit der letzten Testaufnahme mal probiert. Der MD5-Hash unterscheidet sich bei der gleichen Datei auf der SSD des Servers und der kopierten auf dem NAS, bleibt aber nach mehreren Versuchen jeweils gleich.


    Wenn es an der Hardware des Servers liegen würde, müssten doch auch lokale Aufnahmen die gleichen Fehler haben? Von daher würde ich das mal ausschließen bzw. weiß ich nicht wie ich das testen soll - ich habe nur Remote-SSH-Zugriff.
    An die Platten im NAS und die restliche Hardware mag ich auch nicht so recht glauben, da alles "außerhalb" von VDR korrekt zu funktionieren scheint. Ältere VDR-Aufnahmen auf dem NAS funktionieren auch absolut fehlerfrei. (Ausschließen will ich aber nichts!)


    Ich vermute stark ein Netzwerk-Problem oder ganz konkret ein Problem mit NFS, nur weiß ich nicht, wie ich hier weiter vorgehen soll?
    Warum auch immer, andere NFS-Parameter probieren? Welche?


    CafeDelMar

  • Hmm. Habe ich es vielleicht in die falsche Kategorie gepostet oder kann mir hier wirklich keiner helfen?


    Ich weiß nicht wie ich hier weiter vorgehen soll und mein Vater (ist das VDR-System meiner Eltern) hat jetzt schon keine Lust mehr auf VDR. :(



    CafeDelMar

  • Ich weiß nicht wie ich hier weiter vorgehen soll


    Hast du mal einen Kreuztest mit einer anderen Distribution gemacht? Bei LFS stehen einem ja fast endlose individuelle Fehlerquellen zur Verfügung.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Bei so einem einfachen System, kann ich mir nicht vorstellen, daß irgendein NFS Mount Parameter eine Rolle spielt.


    Scheinbar ist SSD -> NFS -> Platte kaputt. Umbenennen und nochmal aufs NFS kopieren und Prüfsummen berechnen.
    Ins Syslog auf dem Rechner gucken, ob irgendwelche Plattenfehler gemeldet werden.
    Das Kaputte löschen und das Ganze nochmal, wenn da ein kaputter Sektor war, dann sollte der ja jetzt nochmal benutzt werden.


    badblocks laufen lassen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch


  • Hast du mal einen Kreuztest mit einer anderen Distribution gemacht? Bei LFS stehen einem ja fast endlose individuelle Fehlerquellen zur Verfügung.


    Was soll schon an einem cp und md5sum mit NFS bei einer Distribution kaputt sein?
    Und an einem NFS Bug im Kernel kann ich nicht glauben.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Kannst ja auch mal rsync anstatt cp versuchen.


    Denke aber auch eher an einen Hardware-Defekt, RAM oder Platten. Lass doch mal memtest und/oder fsck drüberlaufen.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB


  • Hast du mal einen Kreuztest mit einer anderen Distribution gemacht? Bei LFS stehen einem ja fast endlose individuelle Fehlerquellen zur Verfügung.


    Das System wurde seit Start nicht mehr verändert, die Fehler bei den Aufnahmen treten erst seit einigen Monaten auf. Wie schon im Eingangspost geschrieben, könnte das mit dem Einbau neuer Platten (2x WD RED 3TB) und einem Software-Update am NAS zusammenfallen, aber das ist nicht wirklich sicher. Das NAS arbeitet außerhalb von VDR/NFS, soweit es zu beobachten ist, absolut fehlerfrei.


    CafeDelMar

  • Kannst ja auch mal rsync anstatt cp versuchen.


    Denke aber auch eher an einen Hardware-Defekt, RAM oder Platten. Lass doch mal memtest und/oder fsck drüberlaufen.


    Meinst Du auf dem NAS oder dem VDR-Server?


    Wenn beim VDR-Server: Müssten dann nicht auch Aufnahmen auf der lokalen SSD solche Fehler aufzeigen?


    CafeDelMar

  • Scheinbar ist SSD -> NFS -> Platte kaputt. Umbenennen und nochmal aufs NFS kopieren und Prüfsummen berechnen.
    Ins Syslog auf dem Rechner gucken, ob irgendwelche Plattenfehler gemeldet werden.
    Das Kaputte löschen und das Ganze nochmal, wenn da ein kaputter Sektor war, dann sollte der ja jetzt nochmal benutzt werden.


    badblocks laufen lassen.


    Das werde ich nochmal machen.
    Fehler meldet das NAS eigentlich automatisch, aber ich versuche da auch noch mal einen Check anzustoßen.


    Danke schon mal soweit an alle!


    CafeDelMar

  • Meinst Du auf dem NAS oder dem VDR-Server?


    Wenn beim VDR-Server: Müssten dann nicht auch Aufnahmen auf der lokalen SSD solche Fehler aufzeigen?


    CafeDelMar


    Dann wohl eher auf dem NAS.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Hallo Zusammen,


    ich habe GENAU die gleichen Probleme wie CafeDelMar. Konfiguration ist sehr Ähnlich: YaVDR (auf aktueller HW: ASRock B75 Pro3-M, Intel Pentium G860, 2x 3.00GHz, ASUS GT610, cineS2 DUAL PCIe) hat nur ein SSD fürs System, alle Aufnahmen landen ebenfalls per NFS-Mount auf einem Synology-NAS (413j).


    Aktuell läuft VDR 1.7.27 ohne Probleme, alle Aufnahmen sind OK.
    Nach einen Update (YaVDR) auf die aktuell 2.0.x per (update && dist-upgrade) sind die meinsten Aufnahmen Schrott. Sehr viele Pixelfehler und die Aufnahmen sind von der Dateigröße auch zu klein. Live-TV geht immer perfekt. Fehlereinträge im Logfile sind identisch vorhanden. Einige wenige Aufnahmen gelingen ab und zu fehlerfrei.


    Da ich von der SSD regelmäßig ein Image ziehe kann ich OHNE sonstige Veränderungen am Systen das Verhalten nachstellen.
    Da ich keine Ahnung habe wie ich den Fehler eingrenzen kann und ich im Forum auch nichts brauchbares gefunden habe ist mein Workarround momentan auf der "alten" V1.7.27" zu bleiben.


    Wäre super wenn das Problem gelöst werden könnte, meine Unterstützung ist Euch sicher.


    Gruß
    Frank

  • Umbenennen und nochmal aufs NFS kopieren und Prüfsummen berechnen.


    Also nach dem Umbenennen und noch mal kopieren, gab es keine Fehler und die gleiche Checksum.
    Dummerweise fällt das jetzt mit einem Update der NAS-Software zusammen. Es könnte natürlich daran liegen, aber ich habe nahezu die gleiche Konstellation (gleicher Software-Stand auf dem VDR-Server und das gleiche NAS mit demselben Software-Stand) zu Hause und da gab es nie Probleme.


    Ich teste mal weiter.


    CafeDelMar

  • Aktuell läuft VDR 1.7.27 ohne Probleme, alle Aufnahmen sind OK.

    Komisch, CafeDelMar hat ja eine ältere VDR-Version:

    Der VDR-Server läuft unter der Version 1.7.26


    henfri hatte ähnliche Symptome mit Aufnahmen über NFS (das müsste aber ein VDR 1.7.27 gewesen sein): [0.5 alpha] ... Ist träge


    Was für ein Netzwerktreiber wird denn da genutzt? Bei dem Board von Frankie würde ich ja eher auf den schlechten Standard-Treiber für die Realtek-Karte tippen, fnu hat da mal was dazu geschrieben: HOWTO: Zotac GT630 Zone Edition in yaVDR 0.5 testing

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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