live tv-Ausfall wärend Wiedergabe von Aufzeichnung "PES packet shortened to"

Tja und ich habe die scheiß Meldung auch gerade!
Aber ich hatte einen Timer gesetzt und wollte Pro 7 aufnehmen. Er nimmt 1-2 Min auf und stürzt ab. Also keine Aufnahme. Voll witzig, wenn man für einen Freund was aufnehmen soll.

sprut

Zitat

Ich habe einen VDR mit einer FF- und einer Budget-TT-Karte. Wenn ich mir eine Aufzeichnung von HD anschaue, und der VDR am Ende der Wiedergabe zum Live-TV-zurüchschalten sollte, dann liefert er manchmal (etwa 4 mal pro Woche, und nur nach längerem Replay) anstelle des Live -Bides nur ein schwarzes Bild, an dessem oberen Rand manchmal noch einige MPEG-Artefakte zu sehenh sind. Untermalt wird das dann von einzelnen Ton-Stotterern.

Mit der VDR-Version 1.4.1 hatte ich auch massiv dieses Problem (nur war bei mir der ton eigentlich immer mit weg). Mit der 1.3.41, die ich davor drauf hatte ist mir das nie passiert.
Seit ich auf VDR 1.4.3-4 umgestellt habe ist es mir erst einmal passiert und da kam das Bild auch ca. 30sec von selber zurück.

Femon zeigte übrigens immer gute Werte an, nur die Bitrate war 0.
Aufnehmen und diese Aufnahme anschauen hat auch noch geklappt, es ist also nur die primäre Karte betroffen.

Ein paar Tips zur Fehlersuche:

1) Per femon Plugin die Empfangsqualität der Karten bei einem Sender prüfen, wichtig sind BER und UNC, mit der Fernbedienung (R/L) kannst du zwischen den Karten bei gleichem Sender wechseln

Die Strategie nach der VDR die Aufgaben auf die primäre und ander Karten verteilt wurde in den letzten Versionen mehrmals geändert, Details in der Doku oder hier in den Threads zu den jeweiligen Releases

2) Firmware für die FF Karte? findet sich im dmesg Output

3) Wie ist die Interruptverteilung, teilt sich eine DVB Karte den Interrupt?
Prüfen mit "cat /proc/interrupts"

Schaut mal hier:
Optimierter av7110 Treiber
Kann aber sein, das das bei Euren VDRs schon eingebaut ist.
Frithjof

Hallo,

hat jemand eine Lösung für das "PES packet shortened to ..." Problem. Mein VDR (FF + Budget-Karte) hat das gleiche Problem.

Danke!

Gerhard

hallo,

auch bei mir aufgetreten.
3Aufnahmen + ARD-live. Plötzlich ca. alle 30-40 sec für 10sec Live-Bildausfall.
log gleich wie oben.
Aufnahmen teilweise unbrauchbar.
Aktuelles OS: 1.4.4-2(siehe Sig.) vorher mit 1.3.37 - nie aufgetreten. Hardware nicht verändert.
----
regards

monolith

hallo,

leider tritt auch bei mir genau dieser fehler auf! debian etch, 2.6.18 standard-kernel, c't vdr experimental tobi repository.

jede menge PES packet shortened und ring buffer overflows ... hatte ich vorher nicht.

ich frage mich, was das auf einmal ist, daß dies so viele haben. habe zwar jetzt einen neuen server, aber das ding ist echt ein hammerteil, sollte also daran nicht liegen. oder doch?

grüße
linuxbaer

eine lösung gibt's nicht, oder?

Hi,

da dieses Verhalten von mir kodiert wurde, bitte in remux.c mal folgende Zeile aktivieren, indem das Kommentarzeichen "//" weggenommen wird:

//dsyslog("TS continuity error (%d)", ccCounter);

Evtl. auch noch ein paar Zeilen weiter oben vor dem

return; // discard TS packet with adaption_field_control set to '00'.

noch ein dsyslog einbauen, so dass es wie folgt aussieht:

if (!(Buf[3] & (ADAPT_FIELD | PAY_LOAD))) {
     dsyslog("TS packet discarded due to invalid adaption_field_control");
     return; // discard TS packet with adaption_field_control set to '00'.
     }

Vermutlich tritt die "discarded" Meldung nicht auf. Die "continuity" Meldung deutet aber darauf hin, dass Karte und/oder Treiber TS-Pakete unterschlagen.

Bye.

Bei mir hab ich das Problem mit den Hängern übrigens beseitigt bekommen.
Die gleiche Ursache wird es bei euch zwar eher nicht sein, ich habs zur Info aber trotzdem mal beschrieben.

Ich musste meine Root-Platte im Oktober tauschen (die SMART-Meldungen kamen immer öfter) und die Neue(Alte) ist wohl etwas langsamer als die, die drin war. Anscheinend hat sich der Rechner dadurch beim Hochfahren ab und an mal verhaspelt und irgendwas (war leider nicht genau zu bestimmen) nicht richtig gestartet oder initialisiert. Das System lief zwar, der VDR hat aber diese Fehler produziert. Andere Programme (nfs, samba, cups) waren davon deutlich weniger betroffen, daher ist mir das anfangs auch nicht aufgefallen.
Seit dem Setzen von "boot_parallel"(oder so ähnlich) auf "no" in der sysconfig läuft alles wieder einwandfrei (kein Absturz oder hänger seit inzwischen 4 Wochen). Das System braucht nun zwar etwas länger zum booten, damit kann ich aber leben.

rnissl:
Die debug-Meldungen werde ich trotzdem bei Gelegenheit aktivieren und mal schauen, was sich so in den Logfiles sammelt.

... das hat doch irgendwie mit diesem "Repacker" zu tun, oder?
Mir ist übrigens aufgefallen, dass seit etwa einem Jahr keine Konvertierung mehr wegen fehlerhafter Daten abgebrochen ist. Selbst wenn wirklich Fehlerer im Signal waren gab es nur einen kurzen Aussetzer.
Ich verwende vdrsync und zeichne den Digitalton nicht mit auf. Ich wollte es nur mal erwähnen, da es, zumindestens anfangs, bei vielen Probleme mit dem Konvertieren gab.

Hi,

Zitat

Original von SHF
rnissl:
Die debug-Meldungen werde ich trotzdem bei Gelegenheit aktivieren und mal schauen, was sich so in den Logfiles sammelt.

... das hat doch irgendwie mit diesem "Repacker" zu tun, oder?
Mir ist übrigens aufgefallen, dass seit etwa einem Jahr keine Konvertierung mehr wegen fehlerhafter Daten abgebrochen ist. Selbst wenn wirklich Fehlerer im Signal waren gab es nur einen kurzen Aussetzer.
Ich verwende vdrsync und zeichne den Digitalton nicht mit auf. Ich wollte es nur mal erwähnen, da es, zumindestens anfangs, bei vielen Probleme mit dem Konvertieren gab.

Ja, die Repacker haben einige verärgert, weil VDR vorher nie Probleme gemeldet hat. Wo halt kein Kode zum Meckern vorhanden ist, kann halt auch nicht gemeckert werden

An der Stelle sind wir aber noch weit von den Repackern entfernt. Das Kürzen der PES-Pakete ergibt sich wie folgt: im TS-Paket gibt es ein Bit, das anzeigt, dass dieses TS-Paket ein neues PES-Paket einleitet. Folglich muss das letzte PES-Paket zu diesem Zeitpunkt vollständig empfangen worden sein. Ist dem nicht so, dann sind wohl TS-Pakete verloren gegangen.

Früher hat VDR einfach das neue Paket samt Header als Nutzdaten an das alte Paket angehängt. Man erinnert sich vielleicht noch, dass cVideoRepacker was von "system start code detected" gemeldet hat, was auf dieses Verhalten hindeutet. Der Schaden dürfte dabei aber größer gewesen sein, als mit der derzeitigen Lösung.

Zum Plattentausch kann ich beitragen, dass bei mir nach dem Wechsel von PATA nach SATA jede Menge TS-Fehler gemeldet worden sind. Aufnahmen waren fast nicht mehr zu gebrauchen. Anscheinend ließ der sata-Treiber nicht zu, dass die SAT-Karte ihre Daten entsorgen konnte. Jedenfalls habe ich das SATA-Experiment damals wieder aufgegeben.

Bye.

Hi und erstmal ein dickes Sorry, dass es so lange gedauert hat.

Zitat

Original von rnissl
Zum Plattentausch kann ich beitragen, dass bei mir nach dem Wechsel von PATA nach SATA jede Menge TS-Fehler gemeldet worden sind. Aufnahmen waren fast nicht mehr zu gebrauchen. Anscheinend ließ der sata-Treiber nicht zu, dass die SAT-Karte ihre Daten entsorgen konnte. Jedenfalls habe ich das SATA-Experiment damals wieder aufgegeben.

Beim Booten hat ein Dienst ein timeout gemeldet, warscheinlich weil die neue Festplatte es nicht geschafft hat alle parallel gestarteten Programme mit Daten zu versorgen. Mit der Festplatte selber hatte es nichts zu tun. Leider kann ich nicht mehr sagen was da genau schief gegangen ist, beim Booten war es einfach zu kurz zu lesen und der Bootlog ist auch nicht erhalten geblieben.

Zumindestens scheine ich das Problem wirklich beseitigt zu haben, bislang ist es nicht wieder aufgetreten.

Das Wichtigste ist, dass die Bildausfälle nicht vom VDR sondern einem anderen nicht richtig gestarteten Programm oder Kernelmodul verursacht wurden. Da passen auch die Beobachtungen mit den sata-Treibern ganz gut.
Betroffene sollten die Suche also auch auf derartige Ursachen ausdehnen.

Zitat

Original von rnissl
Ja, die Repacker haben einige verärgert, weil VDR vorher nie Probleme gemeldet hat. Wo halt kein Kode zum Meckern vorhanden ist, kann halt auch nicht gemeckert werden

An der Stelle sind wir aber noch weit von den Repackern entfernt. Das Kürzen der PES-Pakete ergibt sich wie folgt: im TS-Paket gibt es ein Bit, das anzeigt, dass dieses TS-Paket ein neues PES-Paket einleitet. Folglich muss das letzte PES-Paket zu diesem Zeitpunkt vollständig empfangen worden sein. Ist dem nicht so, dann sind wohl TS-Pakete verloren gegangen.

Ich bin mit dem aktuellen Zustand eigentlich recht zufrieden. Ab und zu gibt es zwar mal eine "PES packet shortened" Meldung, aber ansonsten läuft alles einwandfrei. Selbst ARM-Crashes (meine Sig. ist aktuell) gab es im letzten Jahr praktisch keine mehr (nur im Zusammenhang mit der anderen Geschichte). Ich wollte es halt nur erwähnt haben, dass es bei mir, in dem Punkt, eher besser als schlechter geworden ist.

hochschieb!

Ich habe aktuell das Mahlzeitimage 3.2 installiert.

Seitdem bekomme ich, wenn ich eine Aufnahme starte, nach ein paar Minuten
im Log die Fehlermeldung "PES Packet ....".

Das Live-Bild ist ok.

Gibt es mittlerweile schon ne Lösung?

Gruß Deejenda