Posts by HelmutB

Der Fehler dürfte wegen mutex_lock_interruptible() immer die gleiche Ursache haben.

Ich werde es mir am Wochenende genauer ansehen.

LG Helmut.

Ja, es dürfte irgend etwas mit dem ca-Device zu tun haben. Und mit mutex_lock_interruptible().

Apr 07 17:49:51 CoreELEC kernel: wintv_usb2ci: probe succesfull
Apr 07 17:49:51 CoreELEC kernel: wintv_usb2ci: cam_state_set       : 00 -> 01
Apr 07 17:49:55 CoreELEC kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
Apr 07 17:49:55 CoreELEC kernel: PC is at __mutex_lock_interruptible_slowpath+0xc0/0x240

Ich weiss nicht mehr, warum ich diesen mutex_lock hier so verwende - vermutlich von irgendwo einfach abgeschrieben, hat bei mir nie gestört - die genaue Funktionsweise muss ich jetzt genauer nachlesen.

War hier ein CA-Modul eigesteckt - bzw. macht es eine Unterschied, ob der Treiber mit oder ohne Module geaden wird?

LG Helmut

Ich kann einen segfault nur provozieren, indem ich das usb-ci bei laufenden VDR abstecke. Dann greift ts_poll() ins Leere. Es erfolgt aber kein Neustart, und wenn ich es wieder anstecke ist es nach dem CAM-Reset wieder normal verwendbar. Es muß bei bei Dir also an etwas anderem liegen.

Ich kann jetzt nur raten. Vielleicht geschieht es beim Zugriff auf das ca-Device.
Wenn der Aufruf wintv_usb_ci_show_sw_info(wintvci) in wintv-ci-core.c auskommentiert wird, sollte vor einem segfault noch die Meldung "probe successfull" angezeigt werden.

Kannst du das mit dem Patch im Anhang einmal ausprobieren.

LG Helmut

Hab ich im Augenblick leider nicht.

Welche Version verwendest du? Der Letztstand auf github wäre Version 0.3.4pre3 vom 4.3.2021.

Gibt es das Problem auch bei einer älteren Version - z.B. mit Ver. 0.3.3 ?

LG Helmut

Auf github liegt nun die Version 10.

Die Umlaute sollten nun richtig dargestellt werden und ein möglicher Deadlock bei sehr schnell aufeinanderfolgenden Programmwechsel wurde gefixed.

LG Hemut

Ich habe heute noch ein paar Eränzungen und Korrekturen in github übernommen.

Es wurde ein Fehler bei der Erkennung eines "Item-change" korrigiert und es gibt jetzt nur noch einen RDS-Parser, die reduntanten Codes in cRDSReceiver und RadioCheckPES wurden entfernt.

Zusätzlich wird nun auch der Radiotext des Senders Dlf Novaerkannt, der als "DAB dynamic label" mit den MECs 0xAA und 0x48 übertragen wird.

LG Helmut

Es gibt ein paar Neuerungen auf https://github.com/siricco/vdr-plugin-radio.

- das Hintergrundbild wird auch bei Wiedergabe einer Aufnahme angezeigt - aus dem Post #39

- in cRadioImage::send_pes_packet() werden nun MPEG2 PES Header geschrieben. Damit sollte die PlayPes() Funktion z.B. auch mit softhddevice ein Bild darstellen.

- Man kann das Leeren des Radiotext Cache im Setup deaktivieren. Damit bleibt z.B. die Playliste auch nach einem Programmwechsel erhalten.

- Bei mehr als zwei RTplus Tags wird die OSD-Höhe automatisch angepasst.

Im Anhang auch die 4 Diffs zur Version 9.

LG Helmut

Emma53 : das liegt daran, dass statt 2 Zeilen für RTplus nun bis zu 6 Zeilen ausgegeben werden. Bei Programmen ohne RTplus oder nur mit Titel + Interpret sieht es daher etwas leer aus.

Mich stört das zwar nicht, aber ich könnte es so abändern, dass sich die Größe des OSD an die Anzahl der vorhandene RTPLus Infos anpasst.

LG Helmut

This line in RadioImage::send_pes_packet seems wrong:

https://github.com/siricco/vdr…2ef7ae1/radioimage.c#L106

I think, x should go into pes_header[6].

Helmut

Vermutlich gab es damals Probleme mit FF-Karten wie hier beschrieben: [ANNOUNCE] radio-plugin 0.2.5

Ich könnte den ReplayImage-Patch übernehmen und zur Sicherheit über das Setup noch zu-/abschaltbar machen.

Helmut

Es scheint, als wäre das Hintergrundbild bei Wiedergabe überhaupt deaktiviert:

       if ((IsRadioOrReplay == 1) && imagepath && !imageShown) { // only live $20090905

Versuche einmal den Patch im Anhang.

Helmut

Ich verwende xineliboutput. Hier gibt es bei Live das Problem, dass sowohl mit PlayPes() als mit StillPicture() zwar das Bild angezeigt wird, xinliboutput dann aber den Ton unterdrückt. Deshalb muß ich das Hintergrundbild ganz abschalten.
Ich habe es jetzt kurz getestet - bei der Wiedegabe von Aufnahmen habe ich auch kein Hintergrundbild, mit PlayPes() habe ich Ton, mit StillPicture() weder Ton noch Bild. Hast du beide Optionen ausprobiert?

Ich habe bei der Bildausgabe nichts geändert - zumindest nicht wissentlich. Ich werde es mir aber ansehen.

Helmut

Ich habe inzwischen einen Klon des Radio-Plugins in https://github.com/siricco/vdr-plugin-radio angelegt, den AAC- und Extension-Patch übernommen und bin bei Version 9 angelangt.

Die Commits bis zum Stand Version 8 sind in der Branch 1.1.0-aac zu finden, es ist mir aber nicht ganz gelungen alle Commits auch direkt in den git-Stand vom 15.7.2018 zu übernehmen, deshalb gibt es im Master einen Commit der alles Fehlende zur v8 abdeckt.

Der aktuelle Stand kann über den Tag AAC_RDSv9als "tar.gz" heruntergeladen werden:

https://github.com/siricco/vdr…io/releases/tag/AAC_RDSv9

Und falls es wer brauchen kann - im Anhang nur das Diff zur Version 1.1.0.

Helmut

Eine kleine Eränzung zur CAID 0x0FFF. Diese dürfte lt. https://www.dvbservices.com/identifiers/ca_system_id?page=2 offiziell von Sony registriert sein.

Diese also einfach als ungültig zu betrachten wäre daher auch nicht ganz richtig. Da ist es besser, diesen inaktiven Eintrag in camtweaks.conf zu belassen.

Helmut

Ja, es scheint zu funktionieren.

Die Reihenfolge muss bei statischer CAPMT nicht zwingend der CamSlot Nummerierung folgen, da hier auch nach der passende CAID gesucht wird. Die fortlaufende Reihenfolge bezieht sich nur auf absolut idente Einträge, egal in welcher Zeile der erste Treffer liegt.

Zum neuen 5. Eintrag - der kommt wegen CAM 4:

Feb 20 21:07:11 SERVER vdr[380974]: [381029] CAM 4: system ids: 0FFF
Feb 20 21:07:11 SERVER vdr[380974]: [381029] CAM 4: Tweaks [disabled]: Flags: 0x0, Limit: 0 ()
Feb 20 21:07:14 SERVER vdr[380974]: [381029] CAM 4: system ids: 0650
Feb 20 21:07:14 SERVER vdr[380974]: [381029] Matching camtweak: CAFE,BABE,Irdeto Access,0x650:2:4

Das Modul meldet sich hier zuerst mit einer ungültigen CAID weil sie die Informationen der Smartcard noch nicht hat und legt einen neuen Eintrag an. Danach wird die gültige CAID 0x650 der Smartcard gemeldet und mit dieser die passenden camtweaks gefunden.

Ich werde prüfen, ob man eine CAID 0x0FFF überhaupt ignorieren kann, aber auch wenn du den neuen Eintrag drinnen lässt sollte es funktionieren und keine weiteren neuen Einträge angelegt werden.

LG Helmut

supamicha : Hier ein Patch mit dem mehrere CAM-Einträge mit gleicher ID (<....>) in der camtweaks.conf definiert werden können.

Bei identer ID werden die Tweaks in fortlaufender Reihenfolge zugewiesen, bei statischer CAPMT werden zusätzlich auch die CAIDs berücksichtigt - also die Kombination CAM+Smartcard.

Kannst du testen, ob deine beiden SMIT CAMs damit richtig zugeordnet werden (der Patch sollte bis vdr-2.6.1 passen)

LG Helmut

Quote from Fourty2

Das mit dem Buffer interessiert mich. Warum?

Das war nur eine Idee. Hier in diesem und den folgenden Posts aus einem älteren Thread, zwar mit dem ngene-Treiber, aber ähnliches Problem

CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

Die ngene und ddbridge Treiber sind sehr ähnlich, und in beiden liefert ts_read() erst Daten wenn die angegeben Buffergröße erreicht ist. Je größer der Send/Receive Buffer von ddci2, desto länger kann es dauern bis die Daten von ts_read() aus dem CI weitergegeben werden. Da die Datenrate nicht immer gleich ist und das Füllen des Buffers unterschiedlich lange dauert, wäre es denkbar, dass dem VDR dabei machmal die Daten ausgehen und damit es zu Bildfehlern o.ä. kommt.

Mit einer kleineren Buffergröße würde die Daten schneller und damit flüssiger an den VDR geliefern werden.

Helmut

supamicha : ich werde mich am Wochenende um dein Problem kümmern - das geistige Konzept steht schon :).

LG

Ich würde hier eher ein schwaches Signal vermuten. Wenn es das aber nicht ist und du ein DD-CI verwendest, versuche es einmal mit einer kleineren Buffergröße beim ddci2-Plugin - z.B. mit --bufsz 500 statt dem Default von 1500.

LG Helmut

Das sieht irgendwie seltsam aus:

Quote from jojo61

Feb 18 10:15:35 vdr vdr[2222]: [2232] SDT: channel 51 NID/TID (1/1111) not found, got 1/1111

Hier die Prüfung (Nid/Tid kommt direkt vom Sectionhandler)

if (Source() != lastSource || !ISTRANSPONDER(Transponder(), lastTransponder)) {
        // We expect a change in NID/TID:
        if (Nid && Tid && Nid == lastNid && Tid == lastTid) {
           transponderState = tsWrong;
           dsyslog("SDT: channel %d NID/TID (%d/%d) not found, got %d/%d", Channel()->Number(), Channel()->Nid(), Channel()->Tid(), Nid, Tid);
           return;
           }
        }

Es scheint, als ob if (Source() != lastSource || !ISTRANSPONDER(Transponder(), lastTransponder)) hier einen Transponderwechsel erkennt obwohl Nid/Tid unverändert sind.

Ein retune würde nur nach der Prüfung von TransponderWrong() in cDvbTuner::Action(void)erfolgen was aber offensichtlich nicht der Fall ist.