VDR startet auf genau einem Sender (N-TV HD) einfach neu

Der Absturz hat eigentlich nichts mit der Ausgabe zu tun, sondern, ob er entschlüsselt werden kann oder nicht.
Beim Setzen der CA-IDs aus den DVB-Daten geht irgendwas schief.

Lars.

Hallo zusammen,

jetzt muss ich mich doch mal zu Wort melden. Lese hier normalerweise nur mit ;)...
Ich hab mal etwas gedebugged:
die "Length" die da "AddCaDescriptors" übergeben wird kommt in dem Fall immer von

int GetCaDescriptors(int Source, int Transponder, int ServiceId, const int *CaSystemIds, int BufSize, uchar *Data, int EsPid)

aus "pat.h". Laut Kommentar gibt die Funktion nur dann -1 zurück, wenn der Buffer "Data" zu klein ist, um alle CA Descriptors zu speichern. Die cCiCaPmt Konstrukturen übergeben hier immer einen 512B großen Buffer. Hab die testweise mal auf 1K vergrößert und jetzt scheints wieder zu laufen.

Den entsprechenden Patch findet Ihr im Anhang. Allerdings verstehe ich von der Materie zu wenig, um zu beurteilen, ob das wirklich eine gute Lösung ist. Die 512B scheinen mir genauso willkürlich wie 1K. Oder gibt`s da irgendeinen Standard, laut dem 512B normalerweise die Obergrenze sind.

Gruß,
Stefan

Ich habe auch inzwischen auch noch etwas getestet und feststellen müssen, dass es eigentlich am VDR liegen muss und nicht an einem der "unaussprechlichen" Plugins.

Ich habe verschiedene vdr-plugins getestet und bei allen ist der VDR abgeschmiert, sobald ich auf n-tv HD geschaltet habe..
Im Gegensatz dazu macht mein DVB-Viewer keinerlei Probleme, welcher vom Windows-PC ebenfalls auf den VDR-PC zugreift, in dem die HD+Karte steckt.
Damit ist m. M. n. die eigentliche Ursache beim VDR selber zu suchen!

Paulaner

Das mit dem zu kleinen Buffer und zu vielen IDs klingt plausibel.
In Kombination mit meinem Patch sollte es dann häufiger klappen, bis die Anzahl wieder vom Sender erhöht wird.

Alternativ kann der vdr den Buffer auch dynamisch erhöhen, bis es passt oder GetCaDescriptors liefert die nötige Größe zurück.

Lars

Wenn die

Zitat von mini73

GetCaDescriptors

-1 zurückgeben kann, dann muss der VDR auch das verarbeiten ohne segfault.

Bei meinem KabelBW Anschluss schmiert da übrigens nichts bei ntv HD ab.

stefan.r
Vielen Dank für den Patch! Damit habe ich wieder Bild bei n-tv HD

Warum sind denn eigentlich die CAIDs (aus der Channels.conf)

1830,1843,1860,98C,9C4,648,650,186A,500

zu groß für den 512 Byte Puffer?
Selbst wenn ich die 9x4 (z. B. 1843) rechne sind das "nur" 36 Byte (Zeichen)

Zitat von mini73

Der Absturz hat eigentlich nichts mit der Ausgabe zu tun, sondern, ob er entschlüsselt werden kann oder nicht.
Beim Setzen der CA-IDs aus den DVB-Daten geht irgendwas schief.

Da kennst Du dich 1000x besser aus als ich, ich wollte nur berichten wie der Status bei einem rpi2 ist. Weil der Sender könnte entschlüsselt werden, wenn requestet, war aber nicht der fall (nur das was ich im log gepostet habe), ich habe da alles von VDR (vdpau) übernommen, wo es zu einem segfault kommt, bspw. anderer Privater HD Sender waren aber hell.

Was mir noch aufgefallen ist, ist die Höhe der CPU Auslastung bei verschlüsselten Sender. Auf der VDR (vdpau) Box habe ich einen Patch von manio benutzt (siehe unten) welche als ein Workaround für hohe CPU Auslastung bei ihm gedient hat. Kann es sein, dass hier das Problem auch eine zu hohe CPU Auslastung ist (also das mit Setzen der CA-IDs aus den DVB-Daten)? Bspw. bei Servus HD ist die CPU Auslastung auf RPI 2 max 18% (RPI2 hat einen direkt angebundenen Tuner), und beim OxF ist es max 78%. Es sind nur rpihddevice, cecremote und dvbXpi von PlugIns geladen.

diff --git a/device.c b/device.c
index 9da5e7f..ededd0a 100644
--- a/device.c
+++ b/device.c
@@ -1756,6 +1756,7 @@ void cTSBuffer::Action(void)
  	bool firstRead = true;
  	cPoller Poller(f);
  	while (Running()) {
+       	cCondWait::SleepMs(1);
        	if (firstRead || Poller.Poll(100)) {
           	firstRead = false;
           	int r = ringBuffer->Read(f);

Der sleep entschärft die Schleife ein wenig und gibt anderen Threads Gelegenheit, etwas zu tun. Bei poll-Schleifen ist sowas manchmal sinnvoll. Mal sehen, ob ich heute Abend in den Source gucken kann...

Lars

Zitat von MegaV0lt

stefan.r
Vielen Dank für den Patch! Damit habe ich wieder Bild bei n-tv HD

Warum sind denn eigentlich die CAIDs (aus der Channels.conf)

Code

1830,1843,1860,98C,9C4,648,650,186A,500

zu groß für den 512 Byte Puffer?
Selbst wenn ich die 9x4 (z. B. 1843) rechne sind das "nur" 36 Byte (Zeichen)

In so einem Descriptor steht schon noch mehr drin als nur die CAID. Erst mal kommen 6 Byte Header (davon sind Byte 3+4 die CAID) und danach bis zu 256 Byte Nutzdaten. Und die Methode GetCaDescriptors gibt ja eine Liste zurück. In den Buffer passt im Worst Case also nur einer.

Zitat von MegaV0lt

stefan.r
Vielen Dank für den Patch! Damit habe ich wieder Bild bei n-tv HD

Da ja also mit diesem Patch das Problem mit n-tv HD behoben ist, ergibt sich die Frage: "Soll jetzt jeder selbst den VDR patchen oder gibt es dazu in nächster Zeit einen gepatchten VDR für yaVDR-0.5? "

Paulaner

Jeder darf seinen vdr patchen, aber ich schau mal, was ich für yavdr machen kann.
Vermutlich aber nur testing, d.h. vdr 2.2.0 (aber natürlich auch für yavdr 0.6).

Lars.

Moin!

Ich hab hier mal einen etwas umfangreicheren Patch fertig gemacht, der zum einen die benötigte Größe beim ersten Aufruf zurückgibt, falls der Buffer zu klein ist, und diesen dann dynamisch erweitert und noch mal versucht, die CA-IDs zu bekommen. Wenn's dann immer noch nicht klappt, ist's halt Pech.

Da ich keine verschlüsselten Sender habe, mag das mal jemand testen?
Ich hab die Buffergröße bewusst bei 512 gelassen, damit man im Log sieht, wie groß der Buffer für n-tv wirklich sein muss. Es müssten dann Zeilen wie "DEBUG: buffer for ca-descriptors too small (x, needed y)" erscheinen.

EDIT: In AddCaDescriptors die Prüfung "Length <= 0" durch "Length < 0" ersetzen, neuer Patch kommt irgendwann...
EDIT2: Neue Patchversion gibt es hier: VDR startet auf genau einem Sender (NTV HD) einfach neu

Lars.

Zitat von stefan.r

In so einem Descriptor steht schon noch mehr drin als nur die CAID. Erst mal kommen 6 Byte Header (davon sind Byte 3+4 die CAID) und danach bis zu 256 Byte Nutzdaten. Und die Methode GetCaDescriptors gibt ja eine Liste zurück. In den Buffer passt im Worst Case also nur einer.

Wenn das so ist, dann war das nur Zufall, das bis jetzt alles geklappt hat. Der Buffer müsste eher 512k groß sein. Am besten wäre natürlich, dass der Puffer einfach mit der Anzahl der Einträge wächst.

Deshalb einfach mal meinen letzten Patch ausprobieren. In Theorie sollte es dann keine Probleme mehr geben.

Lars

Ich sehe gerade, dass "uint8_t capmt[2048];" in cCiCaPmt überlaufen kann. Da ist zwar ein Kommentar wegen overflow-check, aber es ist keiner drin.
Ein böser Sender kann also den vdr auch weiterhin zum Abstürzen bringen. Mal gucken, ob ich das auch noch korrigiert bekomme.
Zumindest einen check kann ich da noch einbauen.

Lars.

So der Patch läuft. Log wird bei n-tv HD wie folgt ausgegeben:

Dec 03 13:04:13 [vdr] [15836] switching to channel 93 (n-tv HD)
Dec 03 13:04:13 [vdr] [15836] [softhddev]SetPlayMode: 0_
Dec 03 13:04:13 [vdr] [15836] [softhddev]SetVideoDisplayFormat: 0_
Dec 03 13:04:13 [vdr] [15836] [softhddev]GetSpuDecoder:_
Dec 03 13:04:13 [vdr] [16539] osdteletext-receiver thread ended (pid=15836, tid=16539)
Dec 03 13:04:13 [vdr] [15836] buffer stats: 0 (0%) used
Dec 03 13:04:13 [vdr] video: slow down video, duping frame_
Dec 03 13:04:13 [vdr] video: decoder buffer empty, duping frame (29/980) 0 v-buf_
Dec 03 13:04:13 [vdr] video: --:--:--.---   +0	0   0/\ms   0-1+4 v-buf_
Dec 03 13:04:13 [vdr] [16540] device 1 TS buffer thread ended (pid=15836, tid=16540)
Dec 03 13:04:13 [vdr] [16538] buffer stats: 74260 (1%) used
Dec 03 13:04:13 [vdr] [16538] device 1 receiver thread ended (pid=15836, tid=16538)
Dec 03 13:04:13 [vdr] audio/alsa: using device 'hw:NVidia,7'_
Dec 03 13:04:13 [vdr] [15836] CAM 1: assigned to device 1
Dec 03 13:04:13 [vdr] [15836] DEBUG: calling AddCaDescriptors with Length 0
            	- Last output repeated 5 times -
Dec 03 13:04:13 [vdr] audio/alsa: start delay 336ms_
Dec 03 13:04:13 [vdr] [15836] D***I: 0.0 set CAM decrypt (SID 61204 (0xEF14), caLm 3, HasCaDescriptors 0)
Dec 03 13:04:13 [vdr] [15836] creating directory /tmp/osdteletext/S19.2E-1-1057-61204
Dec 03 13:04:13 [vdr] [16724] device 1 receiver thread started (pid=15836, tid=16724, prio=high)
Dec 03 13:04:13 [vdr] [16725] osdteletext-receiver thread started (pid=15836, tid=16725, prio=high)
Dec 03 13:04:13 [vdr] [16726] device 1 TS buffer thread started (pid=15836, tid=16726, prio=high)
Dec 03 13:04:13 [vdr] [15836] [softhddev]SetPlayMode: 1_
...
Dec 03 13:04:14 [vdr] audio/alsa: using device 'hw:NVidia,7'_
Dec 03 13:04:14 [vdr] audio/alsa: start delay 336ms_
Dec 03 13:04:14 [vdr] [softhddev] invalid PES video packet_
Dec 03 13:04:14 [vdr] [16150] channel 54 (RTL HD) event Do. 03.12.2015 12:00-14:00 'Punkt 12 - Das RTL-Mittagsjournal' status 4
Dec 03 13:04:14 [vdr] [16150] channel 62 (VOX HD) event Do. 03.12.2015 13:00-13:55 '4 Hochzeiten und eine Traumreise' status 4
Dec 03 13:04:15 [vdr] [15836] ChannelSid: 61204 Channel: n-tv HD
Dec 03 13:04:15 [vdr] [15836] max. latency time 2 seconds
Dec 03 13:04:15 [vdr] [15836] retuning due to modification of channel 93 (n-tv HD)
Dec 03 13:04:15 [vdr] [15836] switching to channel 93 (n-tv HD)
Dec 03 13:04:15 [vdr] [15836] [softhddev]SetPlayMode: 0_
Dec 03 13:04:15 [vdr] [15836] [softhddev]SetVideoDisplayFormat: 0_
Dec 03 13:04:15 [vdr] [15836] [softhddev]GetSpuDecoder:_
Dec 03 13:04:15 [vdr] [15836] DEBUG: buffer for ca-descriptors too small (512, needed 529)
Dec 03 13:04:15 [vdr] [15836] DEBUG: calling AddCaDescriptors with Length 0
Dec 03 13:04:15 [vdr] [15836] CAM 1: unassigned
Dec 03 13:04:15 [vdr] [16725] osdteletext-receiver thread ended (pid=15836, tid=16725)
Dec 03 13:04:15 [vdr] [15836] buffer stats: 0 (0%) used
Dec 03 13:04:15 [vdr] audio/alsa: using device 'hw:NVidia,7'_
Dec 03 13:04:15 [vdr] audio/alsa: start delay 336ms_
Dec 03 13:04:15 [vdr] [15836] CAM 1: assigned to device 1
Dec 03 13:04:15 [vdr] [15836] DEBUG: buffer for ca-descriptors too small (512, needed 529)
Dec 03 13:04:15 [vdr] [15836] DEBUG: calling AddCaDescriptors with Length 0
            	- Last output repeated twice -
Dec 03 13:04:15 [vdr] [15836] DEBUG: buffer for ca-descriptors too small (512, needed 529)
Dec 03 13:04:15 [vdr] [15836] DEBUG: calling AddCaDescriptors with Length 0
            	- Last output repeated twice -
Dec 03 13:04:15 [vdr] [15836] D***I: 0.0 set CAM decrypt (SID 61204 (0xEF14), caLm 3, HasCaDescriptors 1)
Dec 03 13:04:15 [vdr] [16726] device 1 TS buffer thread ended (pid=15836, tid=16726)
Dec 03 13:04:15 [vdr] [16724] buffer stats: 76892 (1%) used
Dec 03 13:04:15 [vdr] [16724] device 1 receiver thread ended (pid=15836, tid=16724)
Dec 03 13:04:15 [vdr] [16257] CAM 1: replies to QUERY - multi channel decryption possible
Dec 03 13:04:15 [vdr] [16746] osdteletext-receiver thread started (pid=15836, tid=16746, prio=high)
Dec 03 13:04:15 [vdr] [16745] device 1 receiver thread started (pid=15836, tid=16745, prio=high)
Dec 03 13:04:15 [vdr] [16747] device 1 TS buffer thread started (pid=15836, tid=16747, prio=high)

Und das Bild kommt?

Danke!

Lars.

Ja, habe Bild auf n-tv-HD

Aber die 0er müssen nicht protokolliert werden:

Dec 03 13:04:15 [vdr] [15836] DEBUG: calling AddCaDescriptors with Length 0 
- Last output repeated twice -

Die kommen auch auf anderen Kanälen, wo das Problem gar nicht existiert

Ja, das dachte ich mir auch schon. Da gibt's demnächst ein Patch-Update.

Lars.