[Announce] Burn-Plugin 0.2.0-beta6 und beta7

    Hallo,

    nach langer, langer Zeit gibts mal wieder was neues vom Burn-Plugin.

    Voraussetzungen

    • Voraussetzung ist ein neueres Project X : empfohlen wird Versison 0.91.0 (aber die CVS-Versionen ab 0.90.4.00.b29 sollten auch funktionieren). Version 0.90.4.00 ist zu alt! vdrsync.pl wird nicht mehr unterstützt
    • VDR 1.7.18+ (sollte auch mit VDR 1.6 funktionieren, aber das ist derzeit ungetestet)
    • Für Videotext-Untertitel (ab VDR 1.7.11) muss der VDR mit dem normalen TTXT-Patch (z.B. vdr-1.7.14-tpid*.patch) aus dem ttxtsubs-Plugin gepatched sein
    • Anpassung bzw. Ersetzen der ProjectX.ini und vdrburn-dvd.sh durch die neuen Versionen im tar-Archiv
    • Spass am Basteln und Eigeninitiative bei der Fehlersuche ;D

    Die wichtigsten Änderungen zwischen 0.2.0-beta5 und 0.2.0-beta6

    • neue Menüstruktur, die das Umbenennen des Filmtitels anhand von EPG Titel, EPG Shorttest oder Aufnameverzeichnis erlaubt (Danke an Brougs78 für die Ideen)
    • H.264 Aufnahmen (HD) werden jetzt wieder in der Auswahl angezeigt, sind aber nicht anwählbar
    • neue Option in den Einstellungen, ob Untertitel (DVB & Videotext) standardmäßig erstellt werden sollen - die Vorgabe nach der Installation ist AUS!
    • ionice für alle Diskaktivitäten beim Konvertieren
    • leere TS-Streams werden jetzt heraussgefiltert (z.B. die ARD und RTL DVB-Untertitelspuren, die keine Nutzdaten enthalten wenn keine Untertitel vorhanden sind)
    • Aufnahmelänge wird jetzt im Auswahldialog angezeigt


    Die Auswahl des Filmtitels funktioniert jetzt folgendermaßen: Im Spurenmenü wird jetzt auch der Filmtitel angezeigt. Steht die Auswahl auf dem Filmtitel, kann man mit der roten Farbtaste ein neues Menü aufrufen. Dort stehen zur Auswahl:
    - EGP-Titel
    - EPG-Titel - EPG-Kurzschreibung
    - EPG-Kurzbeschreibung
    - Name der Aufnahme
    Falls keine EPG-Kurzbeschreibung existiert entfallen die beiden mittleren Möglichkeiten. Mit Ok kommt man wieder ins Spurenmenü zurück und der Titel wird übernommen. Jetzt können noch Änderungen gemacht werden, indem man wie für Text üblich die Nach-Rechts-Taste drückt. Auch hier dient wieder Ok zur Übernahme der Änderung und Back zum Abbrechen. (Danke an Brougs78 für die Idee und den Hinweis auf EPGSearch und an Winni für die EPGSearch-Quelltexte ;D)

    Die wichtigsten Änderungen zwischen 0.2.0-beta6 und 0.2.0-beta7

    • kompiliert wieder mit VDR 1.6, sowie mit 1.7.18 und 1.7.21, jeweils mit und ohne liemikutio Patch
    • Einrückung in der Aufnahmeauswahl korrigiert
    • Statusmenu Updates korrigiert
    • Einstellungen für Project X in vdrburn-dvd.conf ausgelagert (Danke an Keine_Ahnung@vdr-portal.de)

    Hinweise und Einschränkungen

    • Es können Prinzip bedingt nur MPEG2-Videoströme (SD) auf DVD gebrannt werden. H.264-Videoströme (HD) werden nicht unterstützt
    • Es muss Project X als Demuxer benutzt werden, vdrsync.pl wird nicht mehr unterstützt
    • Untertitel werden jetzt standardmäßig NICHT mehr erstellt. Das kann über die Plugineinstellungen generell oder im Spurenmenü für jede Aufnahme einzeln geändert werden
    • ab 0.2.0-beta7: Java und Project X werden jetzt über die vdrburn-dvd.conf im Verzeichnis .../plugins/burn konfiguriert

    Download: vdr-burn-0.2.0-beta6.tgz
    Download: vdr-burn-0.2.0-beta7.tgz

    Homepage

    Happy Burning
    FireFly

    Hallo,

    ich bekomme die folgende Fehlermeldung beim kompilieren:

    Code
    common.c: In function 'std::string vdr_burn::get_recording_osd_line(const cRecording*, int)':
common.c:181:16: error: 'Length' is not a member of 'cIndexFile'
make[1]: *** [common.o] Error 1
make[1]: Leaving directory `/usr/local/src/vdr-1.7.19/PLUGINS/src/burn-0.2.0-beta6'

    VDR-1.7.19
    gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)
    Target: x86_64-redhat-linux

    gibts hier für eine Patch ?

    Gruß MartinKG

    Fedora 41 kernel-6.12.7-200.fc41.x86_64 Gnome Desktop vdr 2.6.9 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

    Gehts um die Aufnahmelänge?

    Schau mal ins Restfulapi-Plugin, da wird anderst drauf zugegriffen (geht für den ungepatchten ab >= 1.7.5). Und da liegt unter Patches auch was für den vdr < 1.7.5. (braucht den STREAMDEVEXT Patch oder ne manuelle Änderung)

    Das extrecmenu läuft komplett ungepatcht ab >= 1.6, liest aber anscheinend das index (oder die Dateigrösse) ein.

    BTW: Auf den STREAMDEVEXT Patch zu setzen ist IMHO wesentlich sinnvoller als auf den Liemikuutio Patch, denn soweit ich es sehe ist der STREAMDEVEXT Patch einzig aus dem Grund da um Pluigns Zugriff auf Infos zu geben die sie sonst nicht hätten. Ist also genau für den geforderten Anwendungsfall da.

    cu

    Zitat von FireFly

    Habe grade gesehen, dass cIndexFile::Length vom Liemikuutio Patch kommt - du willst den nicht vielleicht installieren? ;D
    Für die nächste Version überleg ich mir was

    ok, ich hatte gedacht, ich hätte ihn bereits installiert.
    Nun gut, es kompiliert durch.
    http://www.saunalahti.fi/~rahrenbe/vdr/…o-1.30.patch.gz

    Vielen Dank nochmals. :]

    Gruß MartinKG

    Fedora 41 kernel-6.12.7-200.fc41.x86_64 Gnome Desktop vdr 2.6.9 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

    Zitat von Keine_Ahnung

    Schau mal ins Restfulapi-Plugin, da wird anderst drauf zugegriffen (geht für den ungepatchten ab >= 1.7.5). Und da liegt unter Patches auch was für den vdr < 1.7.5. (braucht den STREAMDEVEXT Patch oder ne manuelle Änderung)

    Das ist ja kein Problem das anders zu programmieren, ich war mir nur nicht bewusst, dass das ne Erweiterung vom liemukuutio ist sonst hätte ich das gleich anders gemacht.

    Da fehlen einige "#if APIVERSNUM >= XXXXX" für ältere VDRs. Möchtest du nen Patch oder machst du das lieber selber?

    Code
    g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -DUSE_DAUPROOFMODE -DUSE_CMDRECCMDI18N -DUSE_CMDSUBMENU -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DDEPGENTRY -DUSE_DELTIMESHIFTREC -DUSE_DVLRECSCRIPTADDON -DUSE_DVLVIDPREFER -DUSE_JUMPPLAY -DUSE_LIEMIEXT -DUSE_MAINMENUHOOKS -DUSE_SETUP -DUSE_NOEPG -DUSE_PARENTALRATING -DUSE_PINPLUGIN -DUSE_SOURCECAPS -DUSE_STREAMDEVEXT -DUSE_TIMERCMD -DUSE_TIMERINFO -DUSE_VALIDINPUT -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DNDEBUG -DPLUGIN_NAME='"burn"' -DPLUGIN_NAME_I18N='"burn"' -D_GNU_SOURCE -D_LARGEFILE_SOURCE -DTTXT_SUBTITLES -DTMPDIR='"/tmp"' -DDVDDEV='"/dev/dvdrw"' -DISODIR='"/pub/export"' -I/usr/src/linux/include -I../../../include -I. -I/usr/include -o common.o common.c
common.c: In function ‘std::string vdr_burn::get_recording_osd_line(const cRecording*, int)’:
common.c:181: error: ‘const class cRecording’ has no member named ‘IsPesRecording’
common.c:183: error: ‘const class cRecording’ has no member named ‘FramesPerSecond’
make: *** [common.o] Fehler 1

    BTW: Die Shellscripte der vorherigen Version funktionierten bei mir nicht, wenn die aktuellen auch nicht gehen, hast du Interesse am unterstützenden debugging (alleine bekomme ich das nicht hin)?

    Edit: Gerade gabs nen Absturz bei der Auswahl von Filmen

    cu

    Zitat von Keine_Ahnung

    Da fehlen einige "#if APIVERSNUM >= XXXXX" für ältere VDRs.

    Ja, das Testen für 1.6 ist diesmal etwas zu kurz gekommen (um nicht zu sagen untergegangen, da ich mittlerweile auf 1.7 umgestiegen bin) Es ist wohl das einfachste, wenn ich das mal selbst ausprobiere. Mit VDR 1.7.20 wird sich auch das cIndexFile::Length ändern.

    Zitat von Keine_Ahnung

    BTW: Die Shellscripte der vorherigen Version funktionierten bei mir nicht, wenn die aktuellen auch nicht gehen, hast du Interesse am unterstützenden debugging (alleine bekomme ich das nicht hin)?

    Bei den Shellskripten hat sich eigentlich nichts wesentliches verändert, das größte war das ionice vor allen Befehlen. Schicke oder poste einfach das Log, dann sollten wir das schon hinkriegen.

    OK, ich habs gerade mal probiert (waren nur die beiden Sachen im Quellcode). Hier ist das erste Log. Das Problem ist das die Dateien im falschen Verzeichnis gefunden werden.

    Code
    -P'burn -t /dev/shm/.vdr/vdr/tmp -d /srv/BIGTMP -i /srv/VIDEO/DVD_IMAGE'

    Aber wenn ich beide nach /tmp lege bleibt er später hängen, da ist dann das grössere Problem.

    Im Moment läuft bei mir 0.1.0-pre22-ff1 mit dessen Scripten.

    cu

    Der Demuxer (Project X) kann nicht gestartet werden:

    Code
    [demux] ionice: execvp failed: Datei oder Verzeichnis nicht gefunden

    Wo liegt denn Dein java und Dein Project X, also ProjectX.jar ? Da gibts kein Standard, das kann sonstwo liegen. Dementsprechend müsstest Du im Skript am Anfang das
    export JAVA_HOME=/opt/j2re1.4.2
    und
    export PROJECTX_HOME=/opt/ProjectX
    anpassen (einfacher) oder (besser) als Umgebungsvariablen in Dein VDR-Startskript aufnehmen. Beim JAVA_HOME wird vom Skript noch das bin-Verzeichnis drangehängt.
    Mit den falschen Verzeichnissen verstehe ich ehrlich gesagt nicht, was Du meinst.

    Zitat von FireFly

    Der Demuxer (Project X) kann nicht gestartet werden:

    Code
    [demux] ionice: execvp failed: Datei oder Verzeichnis nicht gefunden

    Wo liegt denn Dein java und Dein Project X, also ProjectX.jar ? Da gibts kein Standard, das kann sonstwo liegen. Dementsprechend müsstest Du im Skript am Anfang das
    export JAVA_HOME=/opt/j2re1.4.2
    und
    export PROJECTX_HOME=/opt/ProjectX
    anpassen (einfacher) oder (besser) als Umgebungsvariablen in Dein VDR-Startskript aufnehmen. Beim JAVA_HOME wird vom Skript noch das bin-Verzeichnis drangehängt.

    Sorry, das war mein Fehler, weil das hätte ich eigentlich wissen müssen (da hing ich bei der letzten Installation schon Stunden dran).

    Aber jetzt habe ich völlig schockiert festgestellt das der Test erfolgreich verlief ;) Und das obwohl ich eine zu alte PX Version gewählt hatte. Irgendwie seltsam, beta5 hatte ich überhaupt nicht zum laufen bekommen.

    Zitat von FireFly

    Mit den falschen Verzeichnissen verstehe ich ehrlich gesagt nicht, was Du meinst.

    Bei beta5 musste ich --tempdir und --datadir auf selbe Verzeichnis legen, sonst brach er gleich am Anfang ab.


    - Also was bleibt ist der Absturz im Menü (gerade schon wieder passiert) wenn man die Aufzeichnung wählte und dann zum Konvertieren gehen will.
    - Ferner wäre es schön wenn es im Script eine Möglichkeit gäbe das Logfile an nen bestimmten Ort zu verschieben (evtl. per gesetzter Enviroment Variable?).
    - Ferner wird im --datadir ne nicht FAT taugliche Datei (vdrsync.mpv) abgelegt, sollte die nicht ins --tempdir? Weil die Tennung gibts doch wegen UNIX Files an einen Ort und viel Platzbedarf Files an nen anderen. Oder?
    - Desweiteren, könnte man die ProjektX Settings gleich am Anfang des Scriptes testen (Verzeichnisse und Dateien auf Existenz prüfen) um dann gleich mit ner deutlichen Fehlermeldung im Log abzubrechen?


    Ansonsten, wow das war ja jetzt doch einfach, dafür das ich bei beta5 nach Stunden des Probierens aufgegeben hatte. Danke erstmal für die Hilfe, ich stelle jetzt mal auf diese Version um und teste längerfristig.

    Hier nochmal der zweite Absturz, ist die selbe Stelle und ich kanns hier zuverlässig reproduzieren.

    cu

    Zitat von Keine_Ahnung

    - Also was bleibt ist der Absturz im Menü (gerade schon wieder passiert) wenn man die Aufzeichnung wählte und dann zum Konvertieren gehen will.

    Der backtrace von unten? Das statusmonitor.cpp:273 gibts weder in Burn noch im VDR. Welche Plugins nutzt Du denn? Das muss dort gefixed werden.

    Zitat von Keine_Ahnung

    - Ferner wäre es schön wenn es im Script eine Möglichkeit gäbe das Logfile an nen bestimmten Ort zu verschieben (evtl. per gesetzter Enviroment Variable?).
    - Ferner wird im --datadir ne nicht FAT taugliche Datei (vdrsync.mpv) abgelegt, sollte die nicht ins --tempdir? Weil die Tennung gibts doch wegen UNIX Files an einen Ort und viel Platzbedarf Files an nen anderen. Oder?
    - Desweiteren, könnte man die ProjektX Settings gleich am Anfang des Scriptes testen (Verzeichnisse und Dateien auf Existenz prüfen) um dann gleich mit ner deutlichen Fehlermeldung im Log abzubrechen?

    Das Logfile wird am Ende der Konvertierung immer mit dem ISO zusammen abgelegt. Noch mehr Komplexität möchte ich eigentlich nicht einbauen, das Logfile finden sowieso schon nicht alle Nutzer, deshalb steht im Syslog ja jetzt drin, wo es hinkopiert wurde.
    Das mit dem vdrsync.mpv muss ich mir ansehen - das dürfte dann aber schon einige Jahre falsch sein.
    Man könnte viel testen, da Burn ziemlich viele externe Programme nutzen muss und da immer Probleme auftreten können. Ne richtige Fehlerbehandlung über das OSD ist aber nicht wirklich realisierbar. Aber falls Du nen Patch zum Testen der Projct X Settings für das Skript liefern möchtest ... ;D

    Zitat von FireFly

    Der backtrace von unten? Das statusmonitor.cpp:273 gibts weder in Burn noch im VDR. Welche Plugins nutzt Du denn? Das muss dort gefixed werden.

    Das ist dann das restfulapi Plugin. Seltsam das es nur hier auftritt, habs dort im Thread gemeldet.

    Zitat von FireFly

    Aber falls Du nen Patch zum Testen der Projct X Settings für das Skript liefern möchtest ... ;D

    Jup, schaue ich mit mal an. Das sollte ich noch irgendwie hinbekommen. echo und exit 1 am Anfang sollten ja reichen.

    cu

    BTW: was hälst du davon die java/projectx Config optional im Plugindir setzbar zu machen?

    Also so
    --
    [ -r $CONFIG_PATH/settings.conf ] && . $CONFIG_PATH/settings.conf
    --

    und in settings.conf dann z.B.:
    --
    export JAVA_HOME=/usr
    export PROJECTX_HOME=/usr/share/java
    --

    Dann müsste man nicht mehr am VDR Startscipt oder am vdrburn-*.sh Script rumeditieren. Beides wird ja im Zweifel eh wieder durch Packetupdates überschrieben.


    Mir gehts halt darum die Dinge an denen ich gescheitert bin etwas zu verbessern. Ich bastle das denn auch hin und teste das, will halt nur vorher wissen obs dann auch so übernommen wird.


    BTW: Den Rest habe ich mir dann so vorgestellt (ungetestet):
    --
    # check $JAVA_HOME setting
    if [ -d $JAVA_HOME ];
    then
    if [ !(-x $JAVA_HOME/bin/java) ]; then
    echo "\"$JAVA_HOME/bin/java\" do not exists or ist not executlebare"
    exit 1
    fi
    else
    echo "\"$JAVA_HOME\" do not exists or ist not an Directory"
    exit 1
    fi

    # check $PROJECTX_HOME setting
    if [ -d $PROJECTX_HOME ];
    then
    if [ !(-x $PROJECTX_HOME/ProjectX.jar) ]; then
    echo "\"$PROJECTX_HOME/ProjectX.jar\" do not exists or ist not executlebare"
    exit 1
    fi
    else
    echo "\"$PROJECTX_HOME\" do not exists or ist not an Directory"
    exit 1
    fi
    --

    Dann ist das (java/px) wenigstens schonmal eindeutig erledigt. Und das ist ja auch das einzig User Konfigurierbare.

    cu

    Leider läuft die neue Version 0.91 von ProjektX nicht bei mir:

    [demux] Exception in thread "main" java.lang.NoClassDefFoundError: net/sourceforge/dvb/projectx/common/Start
    [demux] Caused by: java.lang.ClassNotFoundException: net.sourceforge.dvb.projectx.common.Start
    [demux] at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
    [demux] at java.security.AccessController.doPrivileged(Native Method)
    [demux] at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
    [demux] at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
    [demux] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
    [demux] at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
    [demux] Could not find the main class: net.sourceforge.dvb.projectx.common.Start. Program will exit.

    Wo bekomme ich die fehlende Java-Klasse her ?

    Grüße,

    Dirk

    Da ist was beim compilieren von Project X bei Dir schief gegangen, das musst Du nochmal machen. Evtl. Disk voll? Du kannst das Project X auch direkt mit "java -jar ProjectX.jar aufrufen um das außerhalb vom Burn-Plugin zu debuggen (benötigt X server). Mit der Anleitung innerhalb der Project X Source sollte es eigentlich funktionieren wenn man sich exakt daran hält.

    Ich hatte das selbe Problem: Projektx unter Debian zum laufen bekommen?

    Wenns nicht geht scheib mal genauer was du versucht hast.

    cu

    Für die nächste Version entweder das benutzen - oder noch besser die fertig berechnete Länge wie von Klaus vorgeschlagen auf der ML (was dann hoffentlich in der nächsten Version kommt)

    Zitat

    - The length (as number of frames) of a recording's index file can now be determined
    by a call to cIndexFile::GetLength() (suggested by Christoph Haubrich).

    Die Sachen müssten dann halt als backport Patches integriert werden für Leute die alte Entwicklerversionen benutzen müssen/wollen.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    vdr-wiki YaVDR |YaVDR Blog

    Hallo,
    ich versuche gerade meinem vdr (1.7.21) wieder ein burn (0.2.0-beta6) zu verpassen und scheitere leider dabei.

    Die ungepatchte Version erzeugt den schon beschriebenen Fehler:

    Code
    common.c: In function ‘std::string vdr_burn::get_recording_osd_line(const cRecording*, int)’:
common.c:181:16: error: ‘Length’ is not a member of ‘cIndexFile’

    Die mit vdr-1.7.21-liemikuutio-1.31.patch gepatchte Version liefert diesen Fehler:

    Code
    common.c: In function ‘std::string vdr_burn::get_recording_datetime(const cRecording*, char)’:
common.c:145:10: error: no matching function for call to ‘cRecording::Title(char, bool, int, bool) const’
../../../include/vdr/recording.h:121:15: note: candidate is: const char* cRecording::Title(char, bool, int) const
common.c: In function ‘std::string vdr_burn::get_recording_osd_line(const cRecording*, int)’:
common.c:181:16: error: ‘Length’ is not a member of ‘cIndexFile’

    Leider habe ich als Nichtprogrammierer keine Ahnung, wie ich den Fehlern beikommen kann. Den Fehler in Zeile 145 konnte ich noch durch den Hinweis in der Fehlermeldung (letzten bool entfernen) vermeiden, aber bei dem Fehler in Zeile 181 bin ich aufgeschmissen.

    Schön wäre auch, wenn ein ungepatches vdr funktionieren würde. Freue mich über jede Hilfe.

    Danke,
    4ndreas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden