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

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.

Zitat von kfb77 schrieb:

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:

# netstat -i 
Kernel Schnittstellentabelle
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
br0              1500 11325611      0  20348 0        518018      0      0      0 BMRU
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)

Zitat von SurfaceCleanerZ

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?

Zitat von kfb77

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

Zitat von kfb77

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

Nein! EPG kommt vom Sat. Werde das setup mit epgd und epg2vdr mal ausprobieren. Ist allerdings etwas tricky zum bauen ...

Zitat von kfb77

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

Ethernet Karte ist bestellt. Dauert aber ein paar Tage bis die im Dorf eintrudelt ...

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?

Zitat von wirbel

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?

Ich verwende schon das aktuelle SATIP Plugin aus dem github repository ( https://github.com/rofafor/vdr-plugin-satip.git ). Da sollte das schon gefixt sein.

Und "frontend resuse" habe ich such schon ausgeschaltet ..

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:

diff -Bc vdr-plugin-satip/satip.c vdr-plugin-satip.MC/satip.c
*** vdr-plugin-satip/satip.c    2021-08-08 15:52:56.419631759 +0200
--- vdr-plugin-satip.MC/satip.c    2021-08-08 15:57:02.827899707 +0200
***************
*** 482,487 ****
--- 482,489 ----
      "    Detachs active SAT>IP servers.\n",
      "TRAC [ <mode> ]\n"
      "    Gets and/or sets used tracing mode.\n",
+     "EITS [ on/off ]\n"
+     "    switches EPG scan mode on/off\n",
      NULL
      };
    return HelpPages;
***************
*** 592,597 ****
--- 594,611 ----
          SatipConfig.SetTraceMode(strtol(optionP, NULL, 0));
       return cString::sprintf("SATIP tracing mode: 0x%04X\n", SatipConfig.GetTraceMode());
       }
+   else if (strcasecmp(commandP, "EITS") == 0) {
+      if (optionP && *optionP) {
+         if (strcasecmp(optionP, "off") == 0) {
+            SatipConfig.SetEITScan(false);
+            return cString("SATIP EITScan switched off");
+        }
+         if (strcasecmp(optionP, "on") == 0) {
+            SatipConfig.SetEITScan(true);
+            return cString("SATIP EITScan switched on");
+        }
+         }
+      }
  
    return NULL;
  }

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