Posts by HelmutB

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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 :).

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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.

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    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

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    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

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    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 :).

  • [gelöst] mcli ERROR: video data stream broken

    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

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    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

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    kls mit "nicht so wichtig", meinte ich eher, ein Weglassen des Lock auf mutexReceiver in DetachAllReceivers() hat wahrscheinlch weniger Nebenwirkungen als das auf den Device-mutex in SetCamSlot().

    Der Aufruf von Detach() kann nur von außerhalb des "großen" mutexReceiver-Lock stattfinden. Wie wäre es, innerhalb eines kurzen Lock die *Receiver in ein lokale Kopie auzulesen und nach dem Lock das Detach() über die Kopie aufzurufen.

    So in etwa:

    LG Helmut

  • [radio-1.1.0] RDS/Radiotext und AAC-Audio

    Ich bin inzwischen bei Version 6 des AAC_RDS Patch angelangt. v4 und v5 haben TomJoad ich intern bei testen"verbraucht". Die <DSE> Erkennung ist inzwischen ziemlich gut und es gehen fast keine RDS-Messages mehr verloren.


    Ich habe festgestellt, das das radio-plugin mit asprintf() arbeitet um den Radiotext zu speichern. Leider wird aber fast überall auf ein free() der nicht mehr benötigten Daten vergessen.

    Ich habe daher noch einen "extension" Patch der nun char-Arrays mit fixer Länge verwendet, viele unnötige Zeilenumbrüche entfernt die den Code zum Teil schwer lesbar gemacht machen und der auch einige kleinere Korrekturen enthält.

    Zusätzlich zeigt das Plugin nun bis zu 6 RT+ Tags an - zu Titel und Interpret jetzt auch Album, Orchester, Komponist und Dirigent die z.B. bei BR Klassik sehr zuverlässig mitübertragen werden.

    Dieser Erweiterunsgspatch ist etwas grösser, die grundsätzliche Funktiosweise des Plugins bleibt aber gleich.


    Für den des AAC_RDSv6 Patch habe ich auch eine Version für den aktuellen Stand auf https://projects.vdr-developer.org/git/vdr-plugin-radio.git/ vom 15.7.2018 von Ulrich Eckhardt .

    Hier zwei Screenshots.


    Helmut

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Dann bin ich ziemlich sicher, dass der Deadlock hier ausgelöst wurde. Da durch DetachAllReceivers() alle Receiver auf "NULL" gesetzt werden, ist hier ein Lock auf die Receiverliste vermutlich auch nicht so wichtig.


    Backref-Fehler sagt mir jetzt nichts. Die 750 TS-Fehler zu Beginn sind unverschlüsselten Pakete die man bei einem Programmwechsel zwangsläufig erhält. Es dauert etwas bis die erste ECM empfangen wird und das Modul mit der Entschlüsselung beginnen kann. Das ist im Live Modus nicht anders, ein Bild gibt es erst mit entschlüsselten TS-Paketen.


    LG Helmut

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Vielleicht kommt der Deadlock von cDevice::DetachAllReceivers.

    Wenn Thread 1 bereits hier den Lock auf mutexReceiver hält, wird er in cDevice::Detach() nicht freigegeben. Und damit würde der Thread 41 in cDevice::Action() nicht aus der for-Schleife herauskommen und das Unlock() am Ende von while(Running() nie stattfinden.

    Kommentiere einmal die MuteLock Zeile() in DetachAllReceivers aus.

    Code
    1. void cDevice::DetachAllReceivers(void)
    2. {
    3. // cMutexLock MutexLock(&mutexReceiver); <<------- hier
    4. for (int i = 0; i < MAXRECEIVERS; i++)
    5. Detach(receiver[i]);
    6. }

    Ich frage mich allerdings, wieso dann ein normales Umschalten von einem verschlüsseltem Sender funktioniert. Veilleichts liegt es an DDCI2.

    Helmut