Posts by HelmutB

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

    Code
    1. Apr 07 17:49:51 CoreELEC kernel: wintv_usb2ci: probe succesfull
    2. Apr 07 17:49:51 CoreELEC kernel: wintv_usb2ci: cam_state_set : 00 -> 01
    3. Apr 07 17:49:55 CoreELEC kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
    4. ...
    5. 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

    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

    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

    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:

    Code
    1. Feb 20 21:07:11 SERVER vdr[380974]: [381029] CAM 4: system ids: 0FFF
    2. Feb 20 21:07:11 SERVER vdr[380974]: [381029] CAM 4: Tweaks [disabled]: Flags: 0x0, Limit: 0 ()
    3. Feb 20 21:07:14 SERVER vdr[380974]: [381029] CAM 4: system ids: 0650
    4. 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

    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

    Das sieht irgendwie seltsam aus:

    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)

    Code: sdt.c
    1. if (Source() != lastSource || !ISTRANSPONDER(Transponder(), lastTransponder)) {
    2. // We expect a change in NID/TID:
    3. if (Nid && Tid && Nid == lastNid && Tid == lastTid) {
    4. transponderState = tsWrong;
    5. dsyslog("SDT: channel %d NID/TID (%d/%d) not found, got %d/%d", Channel()->Number(), Channel()->Nid(), Channel()->Tid(), Nid, Tid);
    6. return;
    7. }
    8. }

    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.