TS continuity error mit VDR 1.7.0 und Reelbox.org Rev 8xxx ?

tomsat · 7. Oktober 2008

Ich habe schon ziemlich alles versucht bekomme mit VDR-1.7.0 - Multiproto und eHD Treibern und Reelbox-Plugin aus allen Rev. > 8xxx vor allem bei HD-Kanälen ständig TS continuity error's.

Die TS continuity error's erscheinen im Log nach ein paar Minuten und werden immer mehr. Was sich auf dem TV zuerst als Störungen zeigt. Nach ein paar Minuten lässt sich auf dem TV nichts mehr erkennen.

Habe es mit verschiedenen VDR-Versionen, verschiedenen Kernel-Versionen sowie verschiedenen Reelbox.org Revisionen ausprobiert. Immer der gleiche Effekt. Sieht aus wie wenn ein Buffer überlaufen würde.

Mit den 7xxx Revisionen geht es noch.

Hat jemand gleiches beobachtet?

Im Moment läuft bei mir Ubuntu 2.6.22.15, VDR-1.7.0, Multiproto, Reelbox R. 7857 ohne Probleme.

Gruss

tomsat

jm24 · 8. Oktober 2008

Hallo,

Wollte auch auf eine neuere Revision updaten, führt bei mir zum gleichen Ergebnis:

TS continuity Errors, und ring buffer overflows, im Log kann man beobachten, dass innerhalb von ein paar Sekunden der buffer von 10% auf 100% voll läuft.

Code

Oct  8 10:40:17 vdr-gross vdr: [10234] buffer usage: 70% (tid=10233)
Oct  8 10:40:17 vdr-gross vdr: [10234] buffer usage: 80% (tid=10233)
Oct  8 10:40:18 vdr-gross vdr: [10234] buffer usage: 90% (tid=10233)
Oct  8 10:40:18 vdr-gross vdr: [10234] buffer usage: 100% (tid=10233)
Oct  8 10:40:22 vdr-gross vdr: [10234] ERROR: 19186 ring buffer overflows (3606957 bytes dropped)
Oct  8 10:40:28 vdr-gross vdr: [10234] ERROR: 29871 ring buffer overflows (5615748 bytes dropped)
Oct  8 10:40:34 vdr-gross vdr: [10234] ERROR: 29417 ring buffer overflows (5530396 bytes dropped)
Oct  8 10:40:36 vdr-gross kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv->state=2
Oct  8 10:40:40 vdr-gross vdr: [10234] ERROR: 31074 ring buffer overflows (5841912 bytes dropped)
Oct  8 10:40:46 vdr-gross vdr: [10234] ERROR: 29311 ring buffer overflows (5510468 bytes dropped)
Oct  8 10:40:48 vdr-gross vdr: [10233] clearing transfer buffer to avoid overflows
Oct  8 10:40:48 vdr-gross vdr: [10234] buffer usage: 0% (tid=10233)
Oct  8 10:40:48 vdr-gross vdr: [10233] TS continuity error (8)
Oct  8 10:40:48 vdr-gross vdr: [10233] TS continuity error (0)
Oct  8 10:40:48 vdr-gross vdr: [10233] TS continuity error (11)
Oct  8 10:40:48 vdr-gross vdr: [10233] TS continuity error (12)
Oct  8 10:40:48 vdr-gross vdr: [10233] cVideoRepacker: operating in MPEG1/2 mode
Oct  8 10:40:48 vdr-gross vdr: [10233] 116 cRepacker messages suppressed
Oct  8 10:40:50 vdr-gross vdr: [10234] buffer usage: 70% (tid=10233)
Oct  8 10:40:50 vdr-gross vdr: [10234] buffer usage: 80% (tid=10233)
Oct  8 10:40:50 vdr-gross vdr: [10234] buffer usage: 90% (tid=10233)
Oct  8 10:40:50 vdr-gross vdr: [10234] buffer usage: 100% (tid=10233)
Oct  8 10:40:52 vdr-gross vdr: [10234] ERROR: 17704 ring buffer overflows (3328341 bytes dropped)
Oct  8 10:40:57 vdr-gross kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv->state=2
Oct  8 10:40:58 vdr-gross vdr: [10234] ERROR: 31419 ring buffer overflows (5906772 bytes dropped)
Oct  8 10:41:04 vdr-gross vdr: [10234] ERROR: 29459 ring buffer overflows (5538292 bytes dropped)
Oct  8 10:41:04 vdr-gross vdr: [10233] clearing transfer buffer to avoid overflows
Oct  8 10:41:04 vdr-gross vdr: [10234] buffer usage: 0% (tid=10233)
Oct  8 10:41:04 vdr-gross vdr: [10233] TS continuity error (8)
Oct  8 10:41:04 vdr-gross vdr: [10233] TS continuity error (14)
Oct  8 10:41:04 vdr-gross vdr: [10233] TS continuity error (13)
Oct  8 10:41:04 vdr-gross vdr: [10233] cVideoRepacker: operating in MPEG1/2 mode
Oct  8 10:41:04 vdr-gross vdr: [10233] PES packet shortened to 1908 bytes (expected: 5126 bytes)
Oct  8 10:41:06 vdr-gross vdr: [10234] buffer usage: 70% (tid=10233)
Oct  8 10:41:06 vdr-gross vdr: [10234] buffer usage: 80% (tid=10233)
Oct  8 10:41:06 vdr-gross vdr: [10234] buffer usage: 90% (tid=10233)
Oct  8 10:41:06 vdr-gross vdr: [10234] buffer usage: 100% (tid=10233)
Oct  8 10:41:10 vdr-gross vdr: [10234] ERROR: 20057 ring buffer overflows (3770705 bytes dropped)

Alles anzeigen

Habe momentan auch eine 7xxx Revision am laufen, ohne Probleme. Aber alles was neuer ist geht nicht mehr.

Gruß
jm24

stevie101 · 8. Oktober 2008

Ich habe auch den TS continuity error, aber Ringbuffer overflows hatte ich nur in Zusammenhang mit dem "bitstreamout" oder wenn zwei HD Aufnahmen zusammenliefen.
Generell könnte es ein Empfangsproblem sein, vielleicht mal den LNB gegen einen empfindlicheren tauschen.

IG88 · 8. Oktober 2008

> TS continuity Errors

habe noch nicht im log nachgesehen aber was du beschreibst würde man auch so sehen - tritt bei mir nicht auf (svn-stand ande letzte woche)

> könnte es ein Empfangsproblem sein,

aber warum läuft es dann mit dem alten svn ? (ich nehme mal an er hat direkt zwischen den ständen gewechselt)

> vielleicht mal den LNB gegen einen empfindlicheren tauschen.

ich würde eher mal die Stecker an den kablen checken und die schüssel ausrichtung checken/korrigieren - ist auf jeden fall wahrscheinlicher und auch billiger

stevie101 · 8. Oktober 2008

Ja seltsam, wenn es bei den 7xxx Versionen funktioniert hat.
Habt ihr parallel auch den multiproto upgedated ?
Ich bin auf 8xxx, und habe keine Veränderung in Bezug auf diesen Fehler zwischen den alten und neuen Versionen festgestellt, werde mir das ganze aber nochmal genauer anschauen.

IG88 · 8. Oktober 2008

hi,

habe mal in die logs geschaut, aktuell habe ich sowas auch, aber ich sehe beim bild keine gravierenden probleme wie sie beschrieben wurden

21:55:42 vdr: [8337] transfer thread ended (pid=4679, tid=8337)
21:55:43 vdr: [4679] switching to channel 13
21:55:43 vdr: [4679] buffer stats: 0 (0%) used
21:55:43 vdr: [8340] transfer thread started (pid=4679, tid=8340)
21:55:43 vdr: [8339] TS buffer on device 2 thread ended (pid=4679, tid=8339)
21:55:43 vdr: [8338] buffer stats: 32148 (1%) used
21:55:43 vdr: [8338] receiver on device 2 thread ended (pid=4679, tid=8338)
21:55:43 vdr: [4679] Picture settings OK.
21:55:43 vdr: [8341] receiver on device 2 thread started (pid=4679, tid=8341)
21:55:43 vdr: [8342] TS buffer on device 2 thread started (pid=4679, tid=8342)
21:55:43 vdr: [8340] TS continuity error (13)
21:55:43 vdr: [8340] TS continuity error (2)
21:55:44 vdr: [8340] cVideoRepacker: switching to MPEG1/2 mode
21:55:44 vdr: [8340] cVideoRepacker: operating in MPEG1/2 mode
21:55:46 vdr: [8340] transfer thread ended (pid=4679, tid=8340)
21:55:46 vdr: [4679] switching to channel 12
21:55:46 vdr: [4679] cTS2PES got 1 TS errors, 1 TS continuity errors
21:55:46 vdr: [4679] cTS2PES got 0 TS errors, 1 TS continuity errors
21:55:46 vdr: [4679] buffer stats: 42488 (2%) used
21:55:46 vdr: [8342] TS buffer on device 2 thread ended (pid=4679, tid=8342)
21:55:46 vdr: [8341] buffer stats: 18424 (0%) used
21:55:46 vdr: [8341] receiver on device 2 thread ended (pid=4679, tid=8341)
21:55:46 vdr: [8380] transfer thread started (pid=4679, tid=8380)
21:55:46 vdr: [8381] receiver on device 2 thread started (pid=4679, tid=8381)
21:55:46 vdr: [8382] TS buffer on device 2 thread started (pid=4679, tid=8382)
21:55:46 vdr: [4679] Picture settings OK.
21:55:46 vdr: [8380] TS continuity error (5)
21:55:46 vdr: [8380] TS continuity error (5)
21:55:47 vdr: [8380] cVideoRepacker: switching to MPEG1/2 mode
21:55:47 vdr: [8380] cVideoRepacker: operating in MPEG1/2 mode

tomsat · 8. Oktober 2008

Das es ein Hardwareproblem ist kann ich ausschliessen. Habe noch eine 2. (ältere) Installation mit Debian und einer 7xxx Rev., ebenfalls VDR-1.7.0 und Multiproto auf einer 2. Partition. Damit läuft alles. Ebenfalls mit meiner jetzigen Installation mit 7xxx Rev.

Multiproto's habe ich diverse probiert. Ältere, neuere, aktulle, mit und ohne _plus. Immer das selbe Problem bei den 8xxx Rev's.

Möglicherweise ein Bug der 'nur' mit Multiproto auftritt und so bei Reel nicht gemerkt wird?

Tommy.Z · 9. Oktober 2008

Hi
Ich glaub das hatte ich auch, aber nach Umstieg auf liplianin ist das weg.
Gruß Tommy

(kann aber nicht mit Sicherheit sagen, was es war, da ich derzeit zuviel teste mit meiner eHD)

Goga777 · 11. Oktober 2008

so, does error "TS continuity" has link with something wrong in VDR or in ffmpeg or in dvb-drivers ?

jm24 · 12. Oktober 2008

Hi,

Hab heute mal zum testen, die neben der S2-3200 verbaute DVB-S Rev 1.5 gegen eine Budget gestauscht, hat auch nichts geändert.

Dann hab ich mal den liplianin Treiber probiert, auch keine Änderung.

Verkabelung hab ich überprüft, sollte in Ordnung sein.

Gruß
jm24

real_schorsch · 12. Oktober 2008

Die TS-Fehler sind nur ein Symptom, nicht die Ursache. Das wichtigere Symptom vorher ist das Überlaufen des Buffers. Zum Rausfinden, wo das passiert, könnte man mal ein paar printfs in HdCommChannel.c/SendPacket() bauen. Am besten je eines am Anfang und Ende und evtl. noch eins in der Retry-Schleife bei hd_channel_write_start. Wenn es da blockiert, passt irgendwas am Format nicht und der/die Buffer im DeCypher laufen über.

tomsat · 12. Oktober 2008

Kann man das nicht abfragen so das die Buffer gar nicht erst überlaufen?

Und seltsam ist ja das es nach dem Wechseln auf einen HD-Kanal anfänglich gut geht und erst nach ein paar Minuten immer schlimmer wird.

Kann das den trotzdem sein das etwas mit dem Format nicht stimmt wenn das Bild i.O. ist? Ich denke mal das Format verändert sich ja nicht nach ein paar Minuten - oder?

real_schorsch · 13. Oktober 2008

"Kann man das nicht abfragen so das die Buffer gar nicht erst überlaufen?"

Die laufen auch nicht über, ausser wenn was daneben geht...

Ich weiss jetzt gerade nicht, wo der hier wirksame Unterschied zwischen 7xxx und 8xxx ist, aber da gab es einige Änderungen, die das Feedback für die Trickmodi betroffen haben. Auch der Remuxer ist beim Reel-vdr ja ein anderer, da könnte schon irgendwas daneben gehen.

jm24 · 13. Oktober 2008

Würde gerne die printfs in HDCommChannel.c einbauen, habe aber davon wenig Ahnung. Habe das gestern mal probiert, ist nichts dabei herausgekommen.

Vielleicht kann das wer machen der mehr Ahnung vom Programmieren hat. Oder eine kleine Beschreibung wie das richtig funktioniert.

Gruß
jm24

jm24 · 19. Oktober 2008

Habe es jetzt nochmal versucht(mit etwas Unterstützung):

Code

printf("test %d \n");

an den Anfang und ans Ende von Sendpacket() gesetzt. kann ich das so machen?

real_schorsch · 19. Oktober 2008

Welche Zahl soll das %d ausgeben? Mach eher mal ein "start\n" und ein "end\n". Im laufenden Normalbetrieb sollte das start und end nur so durchrauschen, wenn es in der HD-Karte irgendwo klemmt, sollte zwischen start und end eine merkliche Verzögerung sein, d.h. es wird (zu) lange gewartet, bis ein Platz im Buffer frei wird.

jm24 · 19. Oktober 2008

Okay, hab es jetzt so gemacht:

Code

void Channel::SendPacket(UInt type, hd_packet_header_t &header, int headerSize,
                                 Byte const *data, int dataSize)
        {
            printf("start\n");
            if (!ch_) return;


	    if (!hda->hdp_running) // Player not running, avoid stall
		    return;


//            static FairMutex mutex;
            mutex_.Lock();


            header.magic = HD_PACKET_MAGIC;
            header.seq_nr = packetSeqNr_;
            header.type = type;
            header.packet_size = headerSize + dataSize;


            packetSeqNr_++;


            void *buffer;


            int ch_packet_size = (header.packet_size + 3) & 0x7FFFFFFC; // Align 4


            int bufferSize = hd_channel_write_start(ch_, &buffer, ch_packet_size, 0);
            if (!bufferSize)
            {
                for (int n = 0; n < 2000000 && !bufferSize; n += 5000)
                {
                    ::usleep(5000);

                    printf("!buffersize_start\n");
                    bufferSize = hd_channel_write_start(ch_, &buffer, ch_packet_size, 0);
                    printf("!buffersize_end\n");
                }
            }
            if (bufferSize)
            {
                printf("buffersize_start\n");
                safe_memcpy(buffer, &header, headerSize);


                if (dataSize)
                {
                    safe_memcpy(static_cast<Byte *>(buffer) + headerSize, data, dataSize);
                }
                hd_channel_write_finish(ch_, ch_packet_size);
                printf("buffersize_end\n");
	    }
            mutex_.Unlock();
            printf("end\n");
        }

Alles anzeigen

Bei hd_channel_write_start und in (buffersize) habe ich auch noch ein printf eingefügt.

Am Anfang rauscht wie du schon gesagt hast, das start und end ständig durch.
(buffersize) durchläuft er nur am Anfang ein paar mal.
Nach ein paar Sekunden dann nur noch hd_channel_write_start, start und end nur noch in großen Abständen bzw fast gar nicht mehr.

TS continuity error mit VDR 1.7.0 und Reelbox.org Rev 8xxx ?

Jetzt mitmachen!

Teilen