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

  • 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 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.

    Bekomme hier ein Fehler beim bauen des Plugins mit vdr-2.6.0 ....




    Edit: So klappt es:

    C
    1. /*
    2. * rdspatpmt.c: PAT section filter
    3. */
    4. - #include <vdr/libsi/descriptor.h>
    5. + #include <libsi/descriptor.h>
    6. #include "rdspatpmt.h"
    7. #include "radioaudio.h"
    8. #define PMT_SCAN_TIMEOUT 2000 // ms


    Gruß

    Uwe

    The post was edited 1 time, last by Uwe ().

  • Hallo,


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

    hatte den gleichen Fehler im PPA.
    Nach anpassen der include #include <libsi/descriptor.h> Build mit VDR-2.2.0 im PPA Ok!


    Gruss

    Wolfgang

    TT S2-6400 - saa716x kompilieren unter 20.04(Focal)

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

  • 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

  • Für opensuse musste ich es auch in #include "libsi/descriptor.h"abändern. Auch etliche andere Plugins nutzen das so:

    Code
    1. PLUGINS/src> grep -R "#include" *|grep libsi
    2. burn/scanner.c:#include <libsi/si.h>
    3. dvbhddevice/dvbhdffdevice.c:#include <libsi/si.h>
    4. epgsearch/conflictcheck.c:/*#include <libsi/si.h>*/
    5. vnsiserver/demuxer.c:#include <libsi/si.h>
    6. vnsiserver/videoinput.c:#include <libsi/section.h>
    7. vnsiserver/videoinput.c:#include <libsi/descriptor.h>
  • Hallo,

    wolfi.m vielleicht ist es bei dir ähnlich - kein installiertes "vdr-devel" Paket?

    build der Pakete erfolgt in Launchpad. ...vdr-dev ist als depends bei allen Plugins im file debian/control enthalten.

    Wie bei FireFly ist auch unter debian/ubuntu der Pfad libsi/descriptor.h

    Code
    1.  wolfi@Ku-Aspire:~/Git/1_gitlab/five/v$ grep -rnwi './' -e 'descriptor.h'
    2. ./vdr-plugin-eepg-0.0.6pre.git20150215/dish.h:14:#include <libsi/descriptor.h>
    3. ./vdr-plugin-eepg-0.0.6pre.git20150215/eit2.h:4:#include <libsi/descriptor.h>
    4. ./vdr-plugin-eepg-0.0.6pre.git20150215/eepg.c:37:#include <libsi/descriptor.h>
    5. ./vdr-plugin-eepg-0.0.6pre.git20150215/dish.c:15://#include <libsi/descriptor.h>
    6. ./vdr-plugin-radio-1.1.0/rdspatpmt.c:5:#include <libsi/descriptor.h>
    7. ./vdr-plugin-vnsiserver-1.8.0/videoinput.c:37:#include <libsi/descriptor.h>
    8. ./vdr-plugin-xine-0.9.5+git20160102/vdr172remux.c:33:#include "libsi/descriptor.h"


    Gruss

    Wolfgang

    TT S2-6400 - saa716x kompilieren unter 20.04(Focal)

  • 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

    Hallo Helmut,


    erstmal, vielen Dank für den tollen Patch! :)

    Ja, ich habe aus Bequemlichkeit die Sourcen der Plugins in den Sourcen von VDR(git)... (~/vdr/PLUGINS/src), aber die Header werden jedes mal mit make install unter Debian auch ins "System" installiert.


    Hier befinden sich die speziellen Header aus dem Ordner "libsi", hier:

    Die restlichen Header befinden sich hier:


    Gruß

    Uwe

    The post was edited 3 times, last by Uwe ().

  • 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

  • Bei mir funktioniert dies nun sehr gut, wenn alles neu erstellt, sowie neu gebaut wird… 👍

    Hier mal die Ausgaben:

  • Uwe hat oben schon darauf hingewiesen:

    Code
    1. radioaudio.c:1962:22: warning: unused variable 'j' [-Wunused-variable]
    2. 1962 | for (int j = 0; !found && a[i]; i++)

    da und in den folgenden Zeilen muss i durch j ersetzt werden

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • 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

  • Was für ein Ausgabedevice hast Du?

    Mit softhddevice kriege ich zwar bei Live-Radio das dafür konfigurierte Stillpicture angezeigt, aber nicht bei Wiedergabe einer Radioaufnahme. Ich hatte gehofft, damit folgendes Problem umgehen zu können:


    Wenn man im softhddevice-Plugin die Option "Black picture" aktiviert, startet die Wiedergabe der Radioaufzeichnung zwar mit einem Schwarzbild, aber sobald man in der Aufzeichnung "spult", kommt das Bild vom zuletzt aktiven TV-Sender.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • 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

  • Das dürfte ein uraltes Problem sein, aber wenn es einer lösen kann, dann Du :)

    Mit StillPicture kriege ich auch Ton bei Wiedergabe von Radio-Aufzeichnungen. ClearOnSwitch und BlackPicture sind bei softhddevice aktiviert.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • das funktioniert!

    Nun ist die Frage, warum wurde es damals deaktiviert? Aus der HISTORY geht die Deaktivierung für replay nicht hervor.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.