[ANNOUNCE] VDR developer version 1.7.20

Hatte heute noch eine Aufnahme die nach 1.5 Stunden abbrach, wegen folgendem Fehler:

Sep 15 20:37:22 homeserver vdr: [18450] ERROR: encountered new payload while buffering - dropping some data!
Sep 15 20:37:22 homeserver vdr: [18450] ERROR: too many bytes for frame type buffer (1128 > 940) - dropped 188 bytes
Sep 15 20:37:22 homeserver vdr: [18450] ERROR: too many bytes for frame type buffer (25756 > 940) - dropped 24816 bytes

Die Aufnahme lief auf Sky HD. Gibt hier Lösungen oder eventuell noch Änderungen in der 1.7.21? Hatte zuvor auch eine Aunfhame laufen, die lief ohne Probleme durch.

Zitat von TheChief

Hatte heute noch eine Aufnahme die nach 1.5 Stunden abbrach, wegen folgendem Fehler:
Gibt hier Lösungen oder eventuell noch Änderungen in der 1.7.21?

VDR/HISTORY:

2011-09-04: Version 1.7.21

...
- Revoked the changes to cFrameDetector that have been introduced in version 1.7.19.
Detecting frames in case the Picture Start Code or Access Unit Delimiter
extends over TS packet boundaries is now done by locally skipping TS packets
in cFrameDetector.

Das sollte dein Problem beheben.

Klaus

Danke, werd dann mal updaten.

Wenn der vdr ein paar Minuten gelaufen ist, gibt's am Ende zu 80% einen Absturz. Ist insofern unkritisch, da die Konfiguration schon weggeschrieben ist. Die Analyse hat gezeigt, das anscheinend kein Plugin schuld ist. Der Stacktrace zeigt den typischen Absturz in cListBase::Clear, wie ich ich schon früher bei fehlerhaft beendeten Plugins gesehen habe. Hier scheint aber noch ein TS buffer Thread zu laufen.

Stacktrace:

(gdb) thread apply all bt


Thread 2 (Thread 1753):
#0  0x00007f5955ef3f93 in poll () from /lib/libc.so.6
#1  0x00000000005102f5 in cPoller::Poll (this=0x7f5924bcadd0, TimeoutMs=<value optimized out>) at tools.c:1260
#2  0x0000000000473bcb in cTSBuffer::Action (this=0x1014f30) at device.c:2039
#3  0x0000000000509b7c in cThread::StartThread (Thread=0x1014f30) at thread.c:257
#4  0x00007f595741d9ca in start_thread () from /lib/libpthread.so.0
#5  0x00007f5955f0070d in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()


Thread 1 (Thread 1133):
#0  0x00007f5955e916bd in ?? () from /lib/libc.so.6
#1  0x00007f5955e94460 in ?? () from /lib/libc.so.6
#2  0x00007f5955e97e83 in free () from /lib/libc.so.6
#3  0x000000000051221d in cListBase::Clear (this=0x7d5de0, __in_chrg=<value optimized out>) at tools.c:1901
#4  ~cListBase (this=0x7d5de0, __in_chrg=<value optimized out>) at tools.c:1821
#5  0x00007f5955e53262 in exit () from /lib/libc.so.6
#6  0x00007f5955e38c54 in __libc_start_main () from /lib/libc.so.6
#7  0x000000000045c699 in _start ()
(gdb) q

PID 1133 ist der normale vdr Prozess und 1753 der TS buffer Thread.
Logfile:

Sep 17 17:42:37 htpc vdr: [1753] TS buffer on device 3 thread started (pid=1133, tid=1753)
...
Sep 17 17:48:00 htpc vdr: [1133] =====================
Sep 17 17:48:00 htpc vdr: [1133] max. latency time 2 seconds
Sep 17 17:48:00 htpc vdr: [1133] caught signal 15
Sep 17 17:48:00 htpc vdr: [1133] exiting, exit code 0
Sep 17 17:48:00 htpc kernel: [  336.269450] __ratelimit: 21 callbacks suppressed
Sep 17 17:48:00 htpc kernel: [  336.269456] vdr[1133]: segfault at 18 ip 00007f5955e916bd sp 00007fff3ee3b790 error 4 in libc-2.11.1.so[7f5955e1a000+17a000]

Bis zum Beenden des vdr wird der TS buffer Thread auch nicht beendet (kein Log-Eintrag).

Ist dies noch ein unbekanntes Problem?

Zitat von wtor

Bis zum Beenden des vdr wird der TS buffer Thread auch nicht beendet (kein Log-Eintrag).

Ist dies noch ein unbekanntes Problem?

Sowas kann ich hier nicht beobachten.
Passiert das mit "plain vanilla" VDR? Also ohne jegliche Patches und nur mit den allernötigsten Plugins (sprich: dem Ausgabeplugin).

Klaus

Ich nutze den vdr 1.7.20 mit Copperheads Extensionpatch. Als Plugin war testweise nur dvbhddevice aktiv. Ein Test mit einem "plain vanilla vdr" könnte ich mal machen. Könnte allerdings etwas dauern, da das mein Wohnzimmer-vdr ist. Und dann schreit gleich die Familie...

Gelöscht, da ich wieder mal nicht auf dem neuesten Beitrag war.

Zitat von TheChief

Hast Du mal die 1.7.21 probiert? Da soll das Problem ja gefixt worden sein bzw. eine Änderung wieder rückgängig gemacht.

Sieht für mich nach einem anderen Problem aus...

Scheint so, als ob da doch noch das osdteletext Plugin (0.9.1) mit drin war. Das ist zumindest das einzige, welches die "TS buffer"-Meldungen erzeugt:

Sep 18 14:34:08 htpc vdr: [8598] switching to channel 2
Sep 18 14:34:08 htpc vdr: [8682] osdteletext-receiver thread ended (pid=8598, tid=8682)
Sep 18 14:34:08 htpc vdr: [8598] buffer stats: 0 (0%) used
Sep 18 14:34:08 htpc vdr: [8683] osdteletext-receiver thread started (pid=8598, tid=8683)
Sep 18 14:34:08 htpc vdr: [8684] receiver on device 3 thread started (pid=8598, tid=8684)
Sep 18 14:34:08 htpc vdr: [8685] TS buffer on device 3 thread started (pid=8598, tid=8685)
Sep 18 14:34:09 htpc vdr: [8680] TS buffer on device 2 thread ended (pid=8598, tid=8680)
Sep 18 14:34:09 htpc vdr: [8679] buffer stats: 88736 (4%) used
Sep 18 14:34:09 htpc vdr: [8679] receiver on device 2 thread ended (pid=8598, tid=8679)

Habe gerade etwas damit gespielt, aber der Fehler kam natürlich nicht...

Hallochen allesamt,

ich weiss nicht ganz genau, ob das hierhin gehört (bitte ggf. verschieben) aber ich habe auch beim Einsatz von DVB-T (SD) Aufnahmen diese Fehler. Allerdings habe ich ZWEI eingebaute DVB-T Karten und der Fehler tritt auch nur dann auf, wenn beide Karten zur gleichen Zeit eine Sendung aufnehmen müssen. Habe ich trotz der Verwendung der Pakete aus Debian sid (ich bin im Kompilieren und so nicht so gut) auf Fehlerbehebung ?

Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: encountered new payload while buffering - dropping some data!
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (1128 > 940) - dropped 188 bytes
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (4888 > 940) - dropped 3948 bytes
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (1128 > 940) - dropped 188 bytes
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: encountered new payload while buffering - dropping some data!
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (1128 > 940) - dropped 188 bytes
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (4888 > 940) - dropped 3948 bytes
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: encountered new payload while buffering - dropping some data!
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (1128 > 940) - dropped 188 bytes
Oct 25 22:41:26 pcxxx vdr: [27986] ERROR: too many bytes for frame type buffer (36284 > 940) - dropped 35344 bytes
Oct 25 22:41:27 pcxxx vdr: [27986] ERROR: video data stream broken
Oct 25 22:41:27 pcxxx vdr: [27986] initiating emergency exit

01:05.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
01:07.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)

Würde mich über jegliche Tipps sehr freuen, ansonsten funktioniert VDR 1.7.20

Ich wollte nur mal nachfragen, ob das hier schon jemand gesehenhat ...

Zitat von raha

Ich wollte nur mal nachfragen, ob das hier schon jemand gesehenhat ...

Ich schätze die meisten, die diesen Thread interessant fanden, sind längst weiter gezogen zu Version 1.7.21. Statt diesen toten Thread zu hijacken solltest du lieber einen eigenen aufmachen.

Gerald

Na gut, dann mache ich das. Ich habe das nur hierher geschrieben, weil - im Unterschied zu den anderen Einträgen - der Fehler nicht bei HD Aufnahmen sondern beim Einbau von 2 DVB-T Karten auftritt.