Posts by HelmutB

    Fourty2 Solche Meldungen habe ich vor längerer Zeit auch einmal im syslog gefunden, die Ursache war damals Datenmüll aus dem Modul.

    Was sagt denn die Info-Datei - gibt es Fehler in der Aufnahme?


    MTD oder die camtweaks mit der statischen CAPMT würde ich als Fehlerquelle ziemlich sicher auschließen da hier nie auf die TS-NULL Pid 0x1FFF gemapped wird. Wenn es aber bei dir öfter vorkommt, kannst du das Debugging des SCA- und MTD Mapping mit dem camtweak Flag 0x3000 dazuschalten. Vielleicht sieht man dann etwas mehr.
    LG Helmut

    Das Problem ist das ciplus-Plugin. Es entfernt in TsPostProcess() immer (!) die scrambled-Bits - daher scheint für den VDR die Entschlüsselung zu funktionieren und es wird kein anderes Modul mehr getestet.

    Feb 4 15:06:19 SERVER vdr: [43229] CAM 2: decrypts channel S19.2E-1-1007-4911

    Das wird sich nur mit händischer Korrektur im cam.data lösen lassen.

    LG Helmut

    Uwe bei Dir (und auch bei allen anderen) passt die Installation. So ist sie von VDR vorgesehen. Gentoo dürfte mittlerweile die einzige Distribution sein, die libsi unter /usr/include/vdr ablegt (Debian hat es vor vielen jahren auch noch so gemacht -> [ANNOUNCE] VDR developer version 1.7.36)


    Im Anhang ein Patch der den VDR Include-Pfad berücksichtigt, und ein etwas "harter" Fix im Makefile für Gentoo.

    Kannst du testen, ob es Nebenwirkungen gibt.

    LG Helmut

    Interessant. Ich habe gerade in vdr-epgsearch nachgesehen. #include <libsi/si.h>* ist so im Code, aber bei gentoo wird vor dem make dieses include durch ein eclass-script in vdr/libsigeändert.

    Code
    1. fix_vdr_libsi_include() {
    2. eqawarn "Fixing include of libsi-headers"
    3. local f
    4. for f; do
    5. sed -i "${f}" \
    6. -e '/#include/s:"\(.*libsi.*\)":<\1>:' \
    7. -e '/#include/s:<.*\(libsi/.*\)>:<vdr/\1>:'
    8. done
    9. }

    Das muss Distributionsabhängig sein. In Ubuntu z.B. liegen die include Dateien unter /usr/include/vdr und /usr/include/libsi.

    Wie es aussieht, ist damit für die Mehrheit <libsi/.....> richtig. Ich werde es so anpassen und mir für gentoo eine andere Lösung überlegen.

    Helmut

    Mit #include "libsi/descriptor.hhabe ich keinen Erfolg.

    Bei mir sind nach einer VDR Installation die Headerdatein in /usr/include/vdr bzw. /usr/include/vdr/libsi zu finden, in den CFLAGS steht -I/usr/include, daher passt das <vdr/libsi/..> beim #include.


    Uwe Hast du die Header Dateien nur lokal im VDR Source-Verzeichnis? -I/home/pi/vdr/include führt dann zu den von make erstellten lokalen Verzeichnissen include/vdr und include/libsi. Darin sind nur Symlinks, die auf /home/pi/vdr zurückführen. Mit -I/home/pi sollte es aber funktionieren. wolfi.m vielleicht ist es bei dir ähnlich - kein installiertes "vdr-devel" Paket?

    Helmut

    Danke für die Info!

    Ich habe pat.c aus vdr-2.5.6 als Vorlage genommen, vermutlich deshalb. Es hat bei mir aber weder ein einfaches make oder auch ein gentoo emerge nie Probleme damit gehabt. ich werde es aber auf jeden Fall ausbessern.

    Helmut


    Edit: Ich sehe gerade, dass in pat.c #include "libsi/descriptor.h"steht und frage mich, warum - und vor allem, wann ich das geändert habe :).

    FireFly cStrings wären auch eine Möglichkeit. Da eine Radiotextzeile aber nur aus max. 64 Zeichen besteht und man die Anzahl der zu speichernden Texte selbst festlegt, habe ich im Extension-Patch von char* auf char-Arrays umgestellt und schreibe direkt in diese Buffer.

    Helmut

    Hier der (ungetestete) V7-Patch gegen den aktuellen Stand im git.


    Das git hat sich nur durch das Dateisplitting von der Version 1.1.0 leider schon so weit entfernt, dass fast jeder Patch doppelte Arbeit bedeutet. Und soweit ich die Code-Änderungen im git nachverfolgen konnte, gibt es gar keine funktionellen Änderungen zur Version 1.1.0.

    Ich weiß nicht genau, wie man das einfach lösen kann. Vielleicht mit einer offiziellen Version 1.1.1, auf der man dann weiter aufbaut.

    Helmut

    Hier die Version 7. Ich habe nun einen Pat/Pmt Parser eingebaut, damit kann das Plugin externe RDS-Pids selbst erkennen und der VDR muß nicht mehr gepatched werden. Das "bitrate" diff von oben ist natürlich enthalten, und das Default für die verbosity ist von "1" auf "0" geändert - Radiotext Debuging müss nun mit "-v 1" aktiviert werden.

    Sonst ist kein weiterer Patch notwendig, der v6-Extension-Patch von Post #13 kann (oder sollte?) zusätzlich auch noch angewendet werden.

    Helmut


    PS: Ich habe mit vdr-2.5.6 und 2.4.7 getestet, vdr-2.2.0 sollte aber auch passen.

    TomJoad hat mich schon vor einer Woche drauf hingewiesen, dass im radio-1.1.0.00-AAC_RDSv6.patch ein Bug enthalten ist, durch den es beim Umschalten zwischen AAC und MPEG1 Radiprogrammen bei der Erstellung des "bitrate" String zu einem double free() mit nachfolgendem segfault kommen kann.

    Ich habe erst heute gesehen, dass Emma53 dieser Fehler auch schon aufgefallen ist: ARD stellt Astra-Hörfunk von MP2 auf AAC um und neuer Kanal


    Als erste Hilfe im Anhang ein diff zur Version6, das diesen Fehler behebt.
    Helmut

    Fourty2 : Ich habe es mit dem Patch gestern nicht mehr getestet, aber gut wenn du es bestätigen kannst.

    Eine kleine Richtigstellung: Es ist natürlich nicht die Timervorlaufzeit sondern TIMERLOOKAHEADTIME (60s) bzw. Setup.VpsMargin (bei mir 120s) innerhalb der auf den Transponder der kommenden Aufnahme geschalten wird. Ich habe es in meinem Post richtiggestellt.

    Helmut

    Vielleicht eine Erklärung, warum dieser Deadlock nicht schon häufiger festgestellt wurde.
    Die Vorrausetzungen sind: Live auf verschlüsseltem Sender mit dem einzigen Device das für eine Aufnahme zur Verfügung steht, ein Aufnahme-Timer für ein Programm auf einem anderen Transponder und zum Zeitpunkt des Timer-Start muss auch tatsächlich das Live-Progarmm aktiv sein.


    Die letzte Punkt ist der Interessante:


    Der VDR will sicherstellen, das zum Zeitpunkt der Aufnahme ein Device tasächlich zur betriebsbereit ist. Dazu wird innerhalb der Timervorlaufzeit TIMERLOOKAHEADTIME schon ein Device ausgewählt und mit diesem auf den Transponder getuned - aber nicht im "Liveview" Modus sondern nur mit IDLE-Priority. Da es sich dabei um das Device mit den verschlüsselten Live-Programm handelt, wird dabei auch der CamSlot entfernt.


    Der VDR main-Loop will aber immer einen Progarmm darstellen, also wird nach kurzer Zeit wieder auf das Live Programm zurückgeschalten. Das ganze wiederholt sich innerhalb der Timervorlaufzeit TIMERLOOKAHEADTIME einige Male.


    Für den Deadlock ist entscheidend, welcher der beiden Zustände beim Timer-Start tatsächlich aktiv ist. Beim Live-Programm kommt ein Deadlock, beim Idle-Programm nicht.

    Da insgesamt länger auf dem Idle-Transponder getuned ist, ist die Wahrscheinlichkeit eines Deadlock geringer als die einer erfolgreichen Aufnahme. Ich musste für zwei Deadlocks 6 Timer Programmieren.


    Hier ein paar Zeilen aus dem syslog. 2min. Vorlaufzeit Setup.VpsMargin, Live ist "3sat HD", Aufnahme um 22:10 auf "ORF1 HD" - in diesem Fall kein Deadlock weil unmittelbar davor auf richtigen Transponder und ohne camslot getuned wird.


    Helmut


    Was mir auffällt: dieses 2 Minuten lange Hin- und Herschalten sieht eigentlich nicht besonders gut aus :).

    Hallo Richard,

    nachdem mit dem mcli5 Patch das Scrambling-Timeout als Plugin-Parameter nach eigenen Bedürfnissen angepasst werden kann, ist es nicht unbedingt notwendig, dem VDR einen bestimmten Wert vorzugeben.

    Allerdings sollte das Scrambling-Timeout nicht größer als MAXBROKENTIMEOUT sein bei dem der VDR bei Aufnahmen einen Restart veranlässt. Deshalb hier die Änderung zum mcli5 patch mit 5 Sekunden-Timeout als default:



    Im Anhang der vdr-2.4.6-mcli6.patch und ein VDR-Binary dazu. Ich hoffe, es läuft.

    LG Helmut

    Da der Deadlock nur wegen camSlot->Assign() entsteht, könnte man das in Detach() auch nur bedingt machen. Dann kann der große MutexLock(&mutexReceiver) bleiben.

    LG Helmut