Burn 0.1.0 Public Beta bis -pre12 [alt]

  • LordJaxom
    Danke.
    Es gab einen Konflikt mit einem Mplex kompiliert mit gcc 3.4 und dem Binary Mplex kompiliert mit gcc 4.0.3
    Derzeit laufen alle Prozesse schön parallel.

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC


    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • Habe folgendes Problem:


    [demux] + vdrsync.pl -o /tmp/.vdr-burn.XXXXXX/VDRSYNC.0 -v-filter ' burn-buffers > vdrsync.mpv' -a-filter 'burn-buffers > vdrsync%%d.mpa' -ac3-filter 'burn-buffers > vdrsync%%d.ac3' /video0/Quarks_extra/2006-02-21.21.42.50.99.rec
    [mplex] INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
    [mplex] **ERROR: [mplex] Unable to open file /tmp/.vdr-burn.XXXXXX/VDRSYNC.0/vdrsync.mpv for reading.
    [mplex] + exit 1



    Mir scheint als ob das Verzeichnis /tmp/.vdr-burn.XXXXXX/VDRSYNC.0 garnicht angelegt wird und deshalb abgebrochen wird? Lege ich das Verzeichnis manuell an, geht es.


    Allerdings wenn ich dann im Plugin auf brennen gehe, geht die CPU Last massiv in die Höhe, VDR hängt in der Fortschrittsanzeige des Plugins fest und reagiert nicht mehr auf Eingaben. VDR wird dann vom Watchdog Timer neu gestartet :(


    Was kann das sein?


    Hierzu ein auszug von top:



    Ich muss dazu sagen, das ich vdrburn-dvd.sh folgendermassen für mein LinVDR abgeändert habe:


    Code
    case $1 in
            render)
                    # XXX TODO !!!!
    #               png2yuv -j $MENU_BACKGROUND -f 25 -n 1 -I t -L 1 | \
                    convert $MENU_BACKGROUND pnm:- | \
                    ppmtoy4m -n 1 -F25:1 -A 59:54 -I t -L -r -v 0 | \
                    mpeg2enc -f 8 -n p -o /tmp/vdrburn-menu-bg.m2v
                    mplex -f 8 -o /dev/stdout /tmp/vdrburn-menu-bg.m2v $MENU_SOUNDTRACK | \
                    spumux -v 2 $MENU_XML > $MENU_MPEG
            ;;



    Das kann aber doch nicht der Grund für den Hänger/Absturz von VDR sein, oder?

  • Habe mal ein Beispiel für das Größenproblem:


    vdrsync.pl gibt folgendes aus:


    Code
    VDRsync    Version 0.1.3PRE1-050322



    Dann mal eine Film ausgewählt:



    movie_size_cut liegt sicherlich nicht völlig daneben. Aber im OSD vom burn-plugin wird als "Gesamtgröße" 228.329 MB angezeigt.


    Wie ruft das Plugin den vdrsync auf? Nicht, das da nicht irgendwo noch eine alte Leiche rumliegt....

  • apex:
    In deinem Log fällt mir zunächst mal auf, dass der garkeine Zufallswerte für die Buchstaben eingesetzt hat. Gibt es denn das Verzeichnis .vdr-burn.XXXXXX überhaupt in /video0 oder ein anderes, mit zufälligen Buchstaben statt XXXXXX? Ich habe an der Stelle im Code zwar etwas getrickst, aber habe nicht damit gerechnet dass sowas dabei herauskommt ( ;) ) - also werde ich auch das noch "ordentlich" machen :]
    Als die CPU-Last massiv in die Höhe schnellte, hattest Du das Brennmenü dann noch offen? Ich vermute eine Endlosschleife bei der Erzeugung der Progressbar, wenn die Prozentwerte (verursacht durch vorhergehende Fehler) negativ werden...


    berndb:
    Die Version habe ich auch, und die Größe ist eigentlich auch nicht unerwartet. Allerdings suche ich nach "video stream xy" bzw. "audio stream xy" gefolgt von der Zeile "App. size (bytes)". Das Kommando ist "vdrsync.pl -i $RECORDING", ohne extra Pfadangabe, genau wie im Burnscript.

  • LordJaxom


    Das kam mir auch komisch vor mit den vielen X'n. Ist es denn auch richtig das die Dateien nach /tmp sollen? Im /video Verzeichnis gibt es ein .vdrburn mit zufallszahen/buchstaben. VDRsync und co schreiben/lesen aber von/nach /tmp? Das ist doch bestimmt falsch?


    Als VDR hing war die Progressanzeige deines Plugins offen, es war aber kein Fortschritt zu sehen, VDR hing auch komplett.


    Meinst Du etwa das:


  • Hallo


    Also auf einer Kiste läuft es hier, auf der anderen nicht?


    Auf beiden gibt vdrsync die größe aus.



    -------------------------


    Auf der wo nichts geht, kann ich Tracks hinzufügen, größe bleibt immer NULL, dann auf brennen kommt "no video track found"....


    Was kann denn das sein, auch im log ist weit und breit nichts von dem Plugin zu sehen?


    Schon mit DEBUG übersetzt, nichts.


    ------------


    Auf der Kiste wo es klappt.


    Code
    Apr 18 12:05:31 vdr: [2627] burn: loaded skin Default using /usr/local/etc/vdr/plugins/burn/menu-bg.png and /usr/local/etc/vdr/plugins/burn/menu-button.png


    Auf der anderen wie gesagt nichts?


    Kann es manchmal etwas mit NLS zu tun haben, das hat die Kiste nähmlich nicht?


    ------------


    Was war noch, kann es daran liegen?


    Code
    crux vdr: [2089] loading plugin: /usr/local/lib/vdr/libvdr-burn.so.1.3.47
    crux vdr: [2089] burn: couldn't stat /dev/dvd, assuming iso-creation only


    Wohl eher nicht, da so gestartet (auf beiden kisten).


    Code
    -d /tmp -i /video0


    MFG Ronny

  • apex:
    Mist ich habs befürchtet, ja genau das meine ich. Im Code wird dann vermutlich für jeden Schritt eine Zeichenkette mit tausenden Leerstellen erzeugt, das bringt die CPU gehörig zum Kochen...


    Hab ich das richtig verstanden, in dem einen Verzeichnis macht er's mit X, in dem anderen mit Zufallswerten ( 8o )? Da kann ich wohl erstmal nur die Tempdir-Erzeugung ändern und Dir ein neues Paket zur Verfügung stellen (abends).


    Dass einiges in /tmp abläuft ist schon richtig, da viele Leute ihr Videoverzeichnis als FAT32 haben. Das neue Burnplugin nimmt mit -d und -t zwei Verzeichnisse entgegen, das eine (-d) muss viel Platz haben, kann aber FAT32 sein, das andere (-t) lagert nur einige Bytes (Fifos und Symlinks), muss aber daher auf einem unixoiden Dateisystem liegen.


    @ronnykornexl:
    Die Meldung "assuming iso-creation only" sagt nur aus dass er gemerkt hat dass er den Default für -D (Brenndevice) nicht als Brenner erkennt und er daher nur ISOs erzeugt.


    Für das Größenproblem: Wenn ich das richtig sehe erscheint auf der "einen" Kiste auch nicht im Log eine Meldung wie "Found video stream e0"? Wenn Du Probleme mit $PATH ausschliessen kannst, kannst Du mir bitte einmal auf beiden Rechnern ein vdrsync.pl -i einer Aufnahme in eine Datei umleiten und mir per PN oder so zukommen lassen?

  • LordJaxom


    Na dann ist der Bug ja schonmal entdeckt ;) (VDR Hänger)


    Zu dem .vdrburn Verzeichnis: In /video ist es mit Zufallswerten vorhanden, in /tmp allerdings nur mit X'n, ja.


    Ich habs nebenbei auch nicht eilig, kommt Zeit kommt bugfix ;)



    Ach ja, was ich sehr vermisse ist das erstellen von Movie-only Video-DVDs, also ohne Menü. Ist das viel arbeit das einzubauen? Ich brenne eigentlich meist nur Movie only mit burn 0.0.0.8 .

  • Zitat

    Original von LordJaxom
    @ronnykornexl:
    Die Meldung "assuming iso-creation only" sagt nur aus dass er gemerkt hat dass er den Default für -D (Brenndevice) nicht als Brenner erkennt und er daher nur ISOs erzeugt.


    Für das Größenproblem: Wenn ich das richtig sehe erscheint auf der "einen" Kiste auch nicht im Log eine Meldung wie "Found video stream e0"? Wenn Du Probleme mit $PATH ausschliessen kannst, kannst Du mir bitte einmal auf beiden Rechnern ein vdrsync.pl -i einer Aufnahme in eine Datei umleiten und mir per PN oder so zukommen lassen?


    Hallo


    Genau, keinerlei messages vom Plugin im syslog... (einzig "assuming iso-creation only")


    Zu Datei umleiten -> verglichen, die Ausgabe ist auf beiden identisch, PATH passt auch.


    Die letzte aus dem CVS lief auch noch, was kann das denn noch sein?


    ----


    Achso beide laufen mit -log 3, auf der Kiste wo es funktioniert sieht man im Syslog folgendes.


    Code
    vdr: [3060] burn: check_waiting_user


    Auf dem anderen nichts.


    MFG Ronny

  • @ronnykornexl:
    Sag mal bitte die gcc- und glibc-Versionen.
    Mit NLS kann es eigentlich nur beim direkten Scriptaufruf zu tun haben, da kann ich höchstens versuchen die Locale noch zurückzusetzen vor dem Aufruf des Scripts (bei allen anderen Aufrufen wird das schon gemacht). Warum auf einem Rechner nichtmal Logausgaben erscheinen, erschliesst sich mir im Moment noch absolut nicht, deutet aber darauf hin dass da irgendwas beim Starten gehörig schief läuft (fast so als würde er die Plugin-Start Methode nicht ausführen).


    Falls Dir noch Ideen kommen, was den Unterschied zwischen den Maschinen ausmacht, immer her damit, bietet immerhin die Möglichkeit zu spekulieren.

  • Hi


    gcc-3.4.4 / glib-2.3.5


    Hätte noch gedacht.


    Code
    +++ ver : 1.3.47 ...
    +++ cmd : make REMOTE=LIRC all plugins -C /usr/local/src/VDR ...
    +++ opt : CXXFLAGS = -fPIC -g -O2 -Wall -Woverloaded-virtual -D__user= PREFIX = /usr/local SRCDIR = $(PREFIX)/src VDRDIR = $(SRCDIR)/VDR PKG_CONFIG_PATH = $(PREFIX)/lib/pkgconfig:/usr/lib/pkgconfig DVBDIR = /usr/src/linux DVBDIR = $(SRCDIR)/DVB VIDEODIR = $(shell echo $${VIDEODIR:-/video0}) DEFINES += -D_GNU_SOURCE LIRC_DEVICE = /dev/lircd RCU_DEVICE = /dev/ttyS1 VFAT = 1 ...
              chain-dvd.c:155:2: warning: #warning error handling


    Aber die Warnung ist auf beiden kisten, noch eine andere Platte zum testen.


    gcc-4.0.3 / glib-2.3.6


    Komme erst Abends dazu.


    -------


    Habe ehrlich gesagt auch keinen Plan was das sein kann, gibt es da noch mehr als DEBUG = 1?


    MFG Ronny

  • Doch schon eher geworden, auf.


    Linux crux 2.2 / 2.6.15.6 #2 Mon Apr 10 20:03:28 CEST 2006 i686 pentium3 i386 GNU/Linux
    gcc-4.0.3
    glib-2.3.6


    Geht es seinen Gang, auf nicht?


    Linux crux 2.1 / 2.6.11.7 #4 Thu Apr 6 14:58:32 CEST 2006 i686 pentium3 i386 GNU/Linux
    gcc-3.4.4
    glib-2.3.5


    MFG Ronny

  • LordJaxom
    Bezüglich bugfixing:
    Apr 18 19:29:19 vdr: [27625] ERROR[burn]: unknown condition while accessing /dev/dvd: Input/output error
    Apr 18 19:29:19 vdr: [27625] burn: subprocess watcher thread ended (pid=27625, tid=27625)
    Apr 18 19:29:19 vdr: [1006] burn: no translation found for 'Burn DVD job active' in language 1 (Deutsch)
    Apr 18 19:29:19 vdr: [1134] burn: removing finished job
    Apr 18 19:29:19 vdr: [1134] burn: executing 'rm -rf /mnt/system/vdr/video0/.vdr-burn.NkMwBf'
    Apr 18 19:29:19 vdr: [1134] burn: starting sh -c 'rm -rf /mnt/system/vdr/video0/.vdr-burn.NkMwBf' (pid = 30895)
    Apr 18 19:29:19 vdr: [1134] burn: process temp (pid = 30895) exited gracefully (exit code 0)
    Apr 18 19:29:19 vdr: [1134] burn: executing 'rm -rf /mnt/system/vdr/video0/.vdr-burn.A62N9m'
    Apr 18 19:29:19 vdr: [1134] burn: starting sh -c 'rm -rf /mnt/system/vdr/video0/.vdr-burn.A62N9m' (pid = 30911)
    Apr 18 19:29:26 vdr: [1126] changing pids of channel 1191 from 901+901:902:204 to 701+701:702:204
    Apr 18 19:29:31 vdr: [1134] burn: process temp (pid = 30911) exited gracefully (exit code 0)
    Apr 18 19:29:31 vdr: [1006] info: Ein Brennauftrag war erfolgreich.
    Apr 18 19:29:31 vdr: [1006] status: cStatusTest::OsdStatusMessage 'Ein Brennauftrag war erfolgreich.'
    Apr 18 19:29:42 vdr: [1006] status: cStatusTest::OsdClear


    Der Vorgang wurde ca. 19:23 Uhr gestartet (iso+brennen), war zwar nur 1 Fiilm, hätte aber eigentlich noch nicht fertig sein können. Mehr ist leider nicht im Log.
    Zusätzlich hatte ich versucht zwei Aufnahmen als iso zu erstellen. Der erste Film wurde offensichtlich erstellt, beim zweiten war Schluss.
    Anbei der für mich wenig aufschlussreiche Log (in rar umbennen).

    Dateien

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC


    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • stevie101:
    Das Log schaue ich mir gleich an, könnte also sein dass ich in diesem Beitrag nochmal was dranhänge, aber nur schonmal vorweg:


    Wie war der Status Deines Brenners als das passiert ist? Scheibe drin? Wenn ja, was für eine genau? Der Fehler (erste Zeile) sagt mir dass libcdio wegen I/O-Error das DVD-Laufwerk nicht ansprechen konnte. Dass es nicht zu einem Fehler kommt ist natürlich noch murks. Und, hast Du vom syslog noch die sagen wir letzten 20 Zeilen vor dem ERROR?


    So, zum Log:
    Ich erkenne eigentlich nur dass vdrsync, requant und mplex für den zweiten Film angelaufen sind während dvdauthor die VOBUS gefixt hat. Als dvdauthor dann anfing den zweiten Film zu lesen ist scheinbar der komplette Vorgang abgestürzt (daran zu sehen dass im Log nicht mehr "+ exit 0" vom Shellscript zu lesen ist). Hier wäre nun der Rest vom syslog aufschlussreich ;)

  • LordJaxom
    Nur zur Klärung:
    Die Auszüge aus Messages stammen vom Versuch einen Film als ISO zu erstellen. Ein Medium war eingelegt. Habe den Prozess nochmal gestartet, hoffe dass ich Dir mehr geben kann.
    Das dvd.log File stammt aus einem anderen Versuch, 2 Filme als ISO+Brennen zu testen. Der zweite Film hatte zwei Audiochannels.

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC


    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • Code
    6. (optional) Create a directory "skins" in "plugins/burn" inside your VDR
       configuration directory. Create sub-directories for each skin you'd like
       to be offered by the plugin. Place menu-bg.png and/or menu-button.png files
       inside to use them as skins for the menus of your DVDs.
    
    
       vdr-1.3.41 # mkdir /etc/vdr/plugins/burn/skins
       vdr-1.3.41 # mkdir /etc/vdr/plugins/burn/skins/Star_Trek_TNG
       vdr-1.3.41 # cp ~/images/star_trek_pal.png \
                         /etc/vdr/plugins/burn/skins/Star_Trek_TNG/menu-bg.png


    ----------


    Nabend


    Hast sicher besseres zu tun.


    Finde das ^^^^^ ein wenig umständlich, für jeden Bild extra ein verzeichnis zu erzeugen.


    Wie wäre es einfach alle anzuzeigen, die auf die Erweitung png hören?


    An Hand der größe sollte man erkennen können, ob Button oder Background.


    Dann im Menu.


    Code
    Aussehen (Button):      <button-1.png>
    Aussehen (Background):  <angel-1.png>


    Villeicht hat das image-plugin bis Dato auch ein Service Interface, welches man nutzen könnte, um die Sachen vorher noch anzeigen zu lassen.


    MFG ronny

  • @ronnykornexl:
    Das ganze wird sicher späternoch eleganter aufgezogen, im Moment bin ich mit solchen Sachen beschäftigt wie gcc-4.0.3 mit glibc-2.3.6 klarzumachen :D. Du musst auch nicht für jedes Bild ein Verzeichnis anlegen, kannst auch einen menu-bg und menu-button zusammen in ein Verzeichnis legen. Im OSD wird das Verzeichnis dann angeboten und statt den Defaults eben Hintergrund und Button aus dem Verzeichnis genommen. Was es ist möchte ich schon lieber am Namen erkennen (oder später mal in einem echten Skinfile definieren).


    stevie101:
    Ok, also demnächst bitte nur Logs die auch zusammengehören ;)

  • LordJaxom
    Sorry, vergiss mein Posting von eben, habs durcheinander gebracht:


    a) Erstellung von ISO+Brennen; 1xFilm
    Im Anhang der komplette Output. Diesmal war kein Medium drin. Resultat gleich.


    b) War Erstellung von nur "ISO"; 2x Filme, 2 Film mit 2 Audiospuren, Abbruch beim 2. Film, dvd.log hast Du.

    Dateien

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC


    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • Hallo zusammen,


    wollte mal meine Erfahrung berichten.


    Also ich habe das gleich Phänomen: Die Größe wird bei geschnittenen Filmen falsch angezeigt, bei unbehandelten Filmen ok, die habe ich aber noch nicht versucht umzuwandeln.


    Bei geschnittemen Film ist (wie bei Stevie) angeblich die Umwandlung "ruckzuck" erfolgreich beendet. Ergebnis = 0.


    Tja, nicht sonderlich hilfreich, aber ein "Leidensgenosse".


    Gruß, Jens

    :)
    Hardware: 1 x DVB Rev 1.6, AMD 2600 Sempron, 512MB Speicher, HD: 2 x Samsung 160 GB, blaues GraphLCD 240x 128
    Software: Ubuntu 7.10, vdr-1.6.0

Jetzt mitmachen!

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