Aufnahmefehler: Wie vorgehen?

  • Hallo,


    nachdem ja jetzt die vdr Entwicklungsversion (gegenwärtig verwende ich 2.5.6) die Anzahl der Fehler bei einer Aufnahme trackt, und die das Live-Plugin auch so schön darstellt (Danke!) sehe ich dass die überwiegende Anzahl meiner Aufnahmen Fehler beinhaltet. Ca. 10-20% der Aufnahmen sind fehlerfrei, die anderen haben zumeist zwischen 150 und 1000 Fehler. Beim Anschauen der Aufnahmen fällt aber nichts besonderes auf. Einzelne, sehr seltene "Rucker" in den Aufnahmen hatte ich auch bisher schon hin und wieder. Deshalb gehe ich davon aus dass das "Problem" schon länger besteht.


    Nun stellt sich mir also die Frage, wie gehe ich am sinnvollsten vor die Ursache zu finden und ggf. zu fixen? Wie finde ich heraus, an welchen Stellen der Aufnahmen die Fehler sind (um ggf. die Logs zu dieser Zeit anschauen zu können)?


    Setup is gegenwärtig so:


    VDR läuft nativ auf einem Fedora 34 Server der physikalisch direkt am Switch des Octopus.Net SATIP Empfänger hängt. Also keine anderen Switches direkt beteiligt. Das LAN Interface des Servers ist allerdings als Bridge konfiguriert (da der Server auch mein Host für VMs ist).

    Das Signal kommt über SAT (OctopusNET mit SW Version 1.1.6). Signalqualität ist immer 100% mit SNRs zwischen 13 und 17db. Als Signalstärke werden ca. 68DBµV angezeigt. Das Signal kommt von der Schüssel (80cm) über einen Switch (Spaun SMS 5587UI) und 20dB Dämpfungsglieder auf den OctopusNET. LNB und SAT Kabel sind fast neu.


    VDR ist Version 2.5.6 aus dem github repository.

    Plugins (alles direkt aus den github repositories): Satip, streamdev-server, epgsearch, vdrmanager, live, vnsiserver, svdrposd

    Alles selbst zusammengebaut.


    Probiert habe ich schon folgende Dinge:

    - vdr läuft in VM auf dem Server und nicht nativ. Ergebnis: Höhere Fehlerrate

    - Transport TCP statt UDP vom SATIP zum Server für RTP. Ergebnis: Kein Unterschied


    Was wären denn wohl Strategien den/die Fehler zu finden?


    Grüße Michael

  • Hi,

    Ich würde mal versuchen das LNB besser auszurichten. Ist m. M. nach der erste Schritt. Am Besten mit nem Satfinder mit Display. VDR ist da nicht so geeignet und bei Satip ja eh noch weniger.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Sieht bei mir ähnlich aus, auch OctopusNet und Bridge Interface auf dem Server, alle Anwendungen laufen im LXC Container.

    Und ich hatte auch mal das gleiche Problem. Bei mir war die Ursache Input Drops auf dem Ethernet Interface während Backups.

    Die siehst du mit z.B. ip -s link show <Ethernet Device>.

    Ich habe das damals gelöst mit einem zweiten Interface, nur für SAT/IP.


    Wie finde ich heraus, an welchen Stellen der Aufnahmen die Fehler sind (um ggf. die Logs zu dieser Zeit anschauen zu können)?

    Spontan fällt mir dazu ein, markad mit -l3 schreibt Fehler mit Framenummer ins Log (suche nach "decoding error").

    VDR
  • Hi,

    Fnu empfiehlt ja immer spezielle Switches mit Priorisierung, aber das kann er besser erklären.

    Ich hab aufgrund seiner Empfehlung auch Netgear GS116Ev3 und GS108Ev3. Nutze aber noch S2 3200 und DD Karten sowie S952.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Danke für die Tipps!


    Ein dezidiertes LAN Interface hatte ich auch schon im Sinn. Muß mal 'ne Netzwerkkarte besorgen (kost ja fast nichts mehr). Eventuell probier ich auch mal den VDR auf einen Raspie4 (dann dafür deziert) zu packen. Den muß ich aber erst freiräumen ... Der VDR ist headless. Schauen tue ich mit Kodi Clients.

    Markad werde ich mal einbauen. Mal sehen ob ich dann zumindest die Uhrzeiten der Fehler lokalisieren kann.


    Für den TIpp mit dem Switch: Ich habe ja das LAN Interface extra deswegen direkt an den im OctopusNet eingebauten Switch gehängt. Die anderen Switche im Netzwerk sollten also (nach meiner Meinung) aussen vor sein. Das sind dann TP-LInk TL-SG116E 1.20 bzw SG108E 5.0 Typen.


    LNB ausrichten: Das habe ich mit so einen SAT-Finder gemacht. Aber würde wenn der LNB nicht gut genug ausgerichtet ist nicht auch der OctopusNet gereingere SNRs und Qualitätsraten ausspuken? Ich hatte den LNB mal getauscht (war schon über 10 Jahre alt und die Verkabelung etwas "angegammelt"). Vor dem Tausch hatte mir der OctopusNet nur SNRs im Beriech 9-12dB und Qualität manchmal < 100% angezeigt. Nach dem Tausch LNB (inklusiver neuer Kabel) sehe ich, wie geschrieben SNR 13-17dB und Qualität immer 100%.


    Gruß

    Michael

  • Inzwischen habe ich Tests mit eingebautem Markad Plugin gemacht und sehe nun etwas klarer:


    Zwei Szenarien:


    1. Fehler während der Aufnahme. Hier war ich zunächst über die hohen Anzahl erstaunt. Mehrere hundert Fehler. Aber der Log von Markad zeigt mir das da durchaus einige hundert Fehler innerhalb 1-2 Sekunden entstehen können (die für mich dann nur als 1 "Ruckler" wahrnehmbar sind)

    Sowas scheint den Löwenanteil auszumachen. D.h. bei meinen Aufnahmen habe ich in der Regel 1-2 solche Situationen. Was ja schon mal beruhigend ist.


    2. Szenario: Wenn eine zweite Aufnahme anläuft während eine andere Aufnahme läuft gibt es häufiger (aber nicht immer) ein "ERROR: video data stream broken" und damit ein Neustart des VDR was zu einer Lücke in der ersten Aufnahme führt.


    Irgendwelche hinweise was sowas verursachen könnte? WIe gesagt der Content kommt immer via SATIP. Ich hab schon lange keine DVB Karten mehr.

  • Ich habe mal meine Glaskugel befragt ;-)

    zu 1.: DTS continuity error kommen von fehlenden Frames. Ich unterstelle mal, dass es bei

    Signalqualität ist immer 100%

    es nicht am SAT Empfang liegt. Hast du mal nach Input Drops auf dem Ethernet Interface geschaut ?


    zu2.: Hast du "ring buffer overflows" im Syslog zu der Zeit ? Falls ja, würde ich vermuten, deine Platte kann nicht schnell genug weg schreiben.

    VDR
  • finished with 402 errors

    Was mir noch aufgefallen ist: Der Log Auszug kann nicht vollständig sein, du hast nur 2 Fehler mit verschiedenen Frame Nummern drin, es müssten aber 402 sein. Suche nochmals nach "decoding error", da gibt es noch andere Fehler wie DTS continuity error. Wenn nicht, poste mal bitte das ganze Log, dann läuft da was schief, diese Funktion ist brandneu.

    VDR

    The post was edited 1 time, last by kfb77 ().

  • Hi,

    Den Neustart kannst du wahrscheinlich verhindern indem du in den VDR Einstellungen den Notausstieg deaktivierst.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • kfb77 schrieb: wrote:

    es nicht am SAT Empfang liegt. Hast du mal nach Input Drops auf dem Ethernet Interface geschaut ?


    zu2.: Hast du "ring buffer overflows" im Syslog zu der Zeit ? Falls ja, würde ich vermuten, deine Platte kann nicht schnell genug weg schreiben.

    Also "ring buffer overflows" sehe ich keine im syslog. Das /video Verzeichnis liegt auch auf einer PCIe SSD. Die müsst eigentlich bei weitem schnell genug schreiben können.


    Drops auf dem Ethernet Interface sehe ich schon. Die kommen aber auch wenn kein VDR läuft:

    Code
    1. # netstat -i
    2. Kernel Schnittstellentabelle
    3. Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
    4. br0 1500 11325611 0 20348 0 518018 0 0 0 BMRU
    5. enp5s0 1500 11667169 0 228 0 1366259 0 0

    Da muß ich noch genauer verstehen was die drops verursacht. (br0 ist eine Bridge die auf enp5s0 sitzt)


    Den Neustart kannst du wahrscheinlich verhindern indem du in den VDR Einstellungen den Notausstieg deaktivierst.

    Ja klar. Aber dann hängt die erste Aufnahme. Da kommen wirklich keine Daten mehr! Der Restart macht irgendwie schon Sinn. Eventuell ein SATIP Problem?


    Was mir noch aufgefallen ist: Der Log Auszug kann nicht vollständig sein, du hast nur 2 Fehler mit verschiedenen Frame Nummern drin, es müssten aber 402 sein. Suche nochmals nach "decoding error", da gibt es noch andere Fehler wie DTS continuity error. Wenn nicht, poste mal bitte das ganze Log, dann läuft da was schief, diese Funktion ist brandn

    Ja das war tatsächlich mit einem grep drinnen. Hier also der gesamte vdr log für die Aufnahme im Anhang: (dieses Mal auch in der richtige Reihenfolge ..)
    vdr-20210802-0513.txt


    Gruß

    Michael

  • Das /video Verzeichnis liegt auch auf einer PCIe SSD. Die müsst eigentlich bei weitem schnell genug schreiben können.

    Das sehe ich auch so, also das kann es nicht sein.


    Drops auf dem Ethernet Interface sehe ich schon. Die kommen aber auch wenn kein VDR läuft:

    Die sind aber nicht so dramatisch. Das kann der Grund für Ruckler sein, aber nicht für VDR Neustart.


    Hinweis für zukünftige Test: starte markad mit --log2rec, dann schreibt er ein Logfile ins Aufnahmeverzeichnis und du brauchst die Infos nicht aus dem Syslog grepen. Außerdem bekommst du keine Probleme mit syslog rate limit bei markad -l3.


    Ist das ein vollständiges Log ? Also du hast kein epg2vdr Plugin laufen ?

    VDR
  • Zum Vergleich, so sieht es bei mir aus, ohne Probleme:

    bridge0 geht ins normale LAN (sogar deutlich mehr Input Drops, wie bei dir)

    bridge1 ist SAT/IP

    bridge2 ist ein 10Gb SAN

    Wie du siehst, sobald du den Client Müll abgetrennt hast, gibt es gar keine Drops mehr.

    VDR

    The post was edited 1 time, last by kfb77 ().

  • So war die Frage nicht gemeint, ganz im Gegenteil: Laut markad Log nutzt du VPS Timer und das verträgt sich nicht mit epg2vdr, da gibt es Aufnahme Abbrüche beim Start der Aufnahme. Darum meine Frage. Also besser nicht ausprobieren ...

    VDR
  • Das Thema EPG hat mich nun auf eine Idee gebracht. Habe mal probeweise den EPG-Scan im SATIP Plugin ausgeschalten und siehe da: Nun sind 90% der Aufnahmen fehlerfrei (gegenüber 10% vorher) und die Fehlerraten der anderen Aufnahmen liegen im einstelligen Bereich (gegenüber 200 bis über 1000 vorher).

    Ich denke mal dass das wohl alles kein Infrastrukturproblem (Netzwerk oder so) darstellt. Auch drei Aufnahmen parallel gehen fehlerfrei.


    Allerdings brauch ich natürlich EPG ... EPG ausschalten ist also kein wirklicher Dauerzustand. Nun bin ich also wieder ratlos. Muß ich wirklich die SATIP Rohdaten debuggen (was ich bisher noch nicht wirklich gemacht habe)? Liegt das Problem möglicherweise im SATIP Plugin?

  • Könnte dazu passen:

    https://github.com/rofafor/vdr-plugin-satip/issues/72


    Does disabling frontend reuse in the setup menu have any effect on the issue?

  • Da wurde nichts verändert, nur das issue geschlossen. Wenn frontend reuse off ist, hast du eine Fehlerquelle weniger.

  • So inzwischen habe ich noch wesentlich weitergespielt ...


    Der vdr (alles gleich SW Versionen) läuft nun auf einem dezidierten Rapsberry Pi 4. /video ist eine USB3 SSD. Der Pi hängt netzwerktechnisch direkt am Switch des OctopusNet. Packet drops sehen ich nun über mehrere Tage und viele VDR Aufnahmen nicht. Netzwerktechnisch scheint also alles im grünen Bereich zu sein.


    Verhalten ist wie gehabt! Wir bewegen uns also definitiv im bereich VDR SW (inklusive Plugins - sehr wahrscheinlich beim satip Plugin) und dem SATIP Server im OctopusNet.


    Was ich definitiv sagen kann: EPG Scans während Aufnahmen laufen auf den freien Tunern des Octopus sind böse (sprich generieren Fehler in den Aufnahmen).


    Das hab ich nun mal - mir der Kneifzange - so umgangen:


    Im satip plugin habe ich das ein-/ausschalten des EPG scans über svdrpsend steuerbar gemacht. Folgender patch macht das möglich:

    Nun lasse ich einen cronjob alle 10 minuten laufen und wenn einen Aufnahme in der nächsten halben Stunde ansteht oder gar schon läuft schält der Job das EPG Scanning ab und ansonsten an.


    Richtig wäre meiner Meinung nach aber dass der vdr selbst nicht einfach alle freien Tuner für's EIT scanning verwendet, sondern für die SATIP Tuner Gruppen pro Device bilden würde und den Scan nur startet wenn alle Tuner dieser Gruppe frei sind. Das schau ich mir mal an, aber nach dem ich am C++ nicht so unbedingt der Held bin kann das ein Weilchen dauern.


    Mit diesem Setup bekomme ich nun immer fehlerfreie Aufnahmen wenn nur eine Aufnahme läuft (ich hab dem vdr alle 4 Tunder des Octopus gegeben.) Laufen mehere Aufnahmen parallel gibts aber auch wieder (allerdings nur eine sehr kleine Zahl) von Fehlern.


    Zudem bekomme ich reproduzierbar Fehler wenn eine Aufnahme läuft und ich via vnsi (mit Kodi) einen Kanal tune. Macht immer genau 2 Fehler pro Kanalwechsel in Kod in der Aufnahme.


    Nun bin ich also an grübeln: Ist das ein Problem des satip Servers im Octopus dass ein neues Tunen in einem Tuner den Stream der anderen Tuner beeinflusst? Wenn dem so wäre, dann wären meine Möglichkeit wohl am Ende. Ich kann den Zustand nicht vermeiden (zumindest wenn ich mehere Tuner verwenden möchte). Oder aber haben wir noch ein Problem im vdr (oder wohl eher im satip Plugin) welches dann ja irgendwie zu fixen sein müsste.


    Hat den jemand hier ein setup mit einem OctopusNet (1.16) das komplett und immer fehlerfreie Aufnahemn mit vdr 2.5.6 und dem satip Plugin aus dem git repository liefert?


    Gruß Micha