vdr-burn: Bei Requantisierung bleibt burn stehen..

    Hallo, liebe Gemeinde


    Folgendes Problem: . Sobald das Burn-Plugin zum Brennen requantisieren muss, bleibt, das Plugin stehen, d.h. es geht nicht mehr weiter. Bevor ich hier jetzt tonneweise Log-Files poste, erst einmal nur eine kleine Verständnisfrage:


    Schaut Euch mal bitte die Ausgabe von "ps -axf an"
    Zuerst mit "Transcode":



    und nun mit "m2vrequantizer"



    Stutzig machen mich die Prozesse :


    tcrequant -f 1.37043
    requant 1.24584 3 464474108


    Für mich sieht es so aus, als ob dort der Befehl unvollständig ist.
    Wenn man den jedenfalls den Befeht so in eine Shell eingibt, kommt da eine Versionsangabe und das wars dann auch schon. Jedoch kehr das Programm dann nicht wieder zur Shell zurück und blockiert somit den ganzen Brennvorgang.
    Passend dazu ist dann auch die Ausgabe von "top":



    Dort sieht man nichts , was auf irgendeine Aktivität des Burn-Plugin schließen täte. Die Prozent-Anzeige bleibt auch dann eine ganze Nacht bei 0% stehen (dann habe ich abgebrochen)
    Ist einem von Euch schon mal Gleiches passiert ? Ich schicke Euch doch mal das Logfile mit. Vielleicht fällt ja jemandem etwas auf.
    Ach ja , ohne Requant -Funktion funktioniert das Brennen von DVD's einwandfrei...


    Viele Grüße


    gehlhajo

    Dateien

    dvd.zip 6,83 kB – 105 Downloads

    VDR-1: streamdev-server | Hummingboard2| TT 3600 USB | Siemens S500 Gehäuse | Archlinux mit eigen Skripten
    VDR-2: streamdev-client | rpihddevice | Raspberry 2b | Siemens S450 Gehäuse| Remote: URC6410 | LG 42LV4500 |     Archlinux mit eigenen Skripten


    Hallo,


    eine Lösung habe ich jetzt zwar nicht aber versuch es doch mal manuell....
    Da beim konvertieren mit dem burn Plugin alles über Pipes geht muss man jetzt erstmal heraus bekommen wo es "hängt".


    Welche requant Version setzt du ein?


    Aus dem burn README:

    Zitat


    requant - http://metakine.com/files
    ** ATTN: Currently only the snapshot from around July 2004 is supported
    ** For convenience, I've uploaded the package to:
    ** http://www.xeatre.tv/community…rib/M2VRequantizer.tar.gz


    Versuch doch manuell mal folgendes:


    Code
    vdrsync.pl -o /tmp/mein_output_dir -cut '/mnt/data/video/Frasier/%Der_gute_Sohn_(The_Good_Son)/2008-01-14.15.40.50.99.rec/'


    Code
    requant 1.245840 3 541913420 < /tmp/mein_output_dir/vdrsync.mpv > /tmp/mein_output_dir/requant.mpv


    Wobei "541913420" bei Dir die Filesize von vdrsync.mpv sein sollte (keine Ahnung ob dies nun so korrekt ist ? ). Ich habe es nur mit einer kleineren Datei getestet, eigentlich würde ich hier irgendwas über 4,4GB erwarten....


    Code
    mplex -f 8 -S 0 -M -o /tmp/mein_output_dir/movie.mpg /tmp/mein_output_dir/requant.mpv /tmp/mein_output_dir/vdrsync0.mpa


    Eigentlich sollte man jetzt feststellen können wo es "hängen" bleibt....
    Wenn es bei vdrsync.pl hängt (evtl. wegen AC3?) versuch es doch mal ProjectX.....


    Zitat

    Original von gehlhajo
    Stutzig machen mich die Prozesse :
    requant 1.24584 3 464474108


    Das ist glaube ich normal für requant, aus der "vdrburn-dvd.sh":

    Code
    requant)
                requant $REQUANT_FACTOR 3 $VIDEO_SIZE < "$VIDEO_FILE" > "$REQUANT_FILE"
                rm -f "$VIDEO_FILE"
        ;;


    Was mich eher was stutzig macht ist 464474108 oder wird dies in kByte übergeben?
    [EDIT]
    Ups, bei kByte wäre es dann doch etwas zu groß für ein DVD ......
    [/EDIT]


    Gruß,
    Chuck

    1- yavdr 0.5 - DVB-C
    1- VDR-1.7.14 - Xine Pugin - XBMC - DVB-C
    2- Activy 300 mit Gen2VDR V2

    Einmal editiert, zuletzt von vdrchuck ()

    Hi vdrchuck


    Schön, dass doch noch jemand geantwortet hat: Also arbeiten wir einmal die Liste ab:


    Zitat

    Original von vdrchuck
    Welche requant Version setzt du ein?


    Scheint ene Version von 2006 zu sein (M2VRequantizer-20060306.tgz)
    Habe ich aber keinen Einfluß drauf ist die akzuelle Version im Portage-tree



    Zitat

    Original von vdrchuck
    Versuch doch manuell mal folgendes:


    Code
    vdrsync.pl -o /tmp/mein_output_dir -cut '/mnt/data/video/Frasier/%Der_gute_Sohn_(The_Good_Son)/2008-01-14.15.40.50.99.rec/'


    funktioniert



    Zitat

    Original von vdrchuck

    Code
    requant 1.245840 3 541913420 < /tmp/mein_output_dir/vdrsync.mpv > /tmp/mein_output_dir/requant.mpv


    Wobei "541913420" bei Dir die Filesize von vdrsync.mpv sein sollte (keine Ahnung ob dies nun so korrekt ist ? ). Ich habe es nur mit einer kleineren Datei getestet, eigentlich würde ich hier irgendwas über 4,4GB erwarten....


    Mist, fuktioniert auch...


    Zitat

    Original von vdrchuck

    Code
    mplex -f 8 -S 0 -M -o /tmp/mein_output_dir/movie.mpg /tmp/mein_output_dir/requant.mpv /tmp/mein_output_dir/vdrsync0.mpa


    und funktioniert auch. Also wenn ich alles in Einzelschritte aufteile ,geht das requantisieren..


    Aber ich habe etwas folgendes herausgefunden. Unmittelbar nach Start legt burn 10 verschiedene tmp Verzeichnisse an. Soweit so gut. Sind ja auch 10 Dateien , die auf die DVD sollen. Aber es werden in diesen Verzeichnissen unmittelbar nach Start ebenfalls 4 Dateien


    movie.mpg
    requant.mpv
    vdrsync.mpv
    vdrsync0.mpa


    mit der Größe 0Byte angelegt. Und zwar in jedem der 10 Verzeichnisse.
    Experimentell konnte ich dann nachvollziehbar ermitteln, dass vdrsync dagegen knallt. D.h. vdrsync mag es nicht wenn diese Dateien schon da sind . vdrsync kann diese Dateien nicht löschen oder überschreiben.
    Der vdrsync-Prozess bleibt einfach stehen oder wartet auf etwas. Ein Löschen dieser Dateien bringt nicht. Nur wenn man l sie öscht und den vdrsync-Prozess neu startet funktioniert es.
    Der Owner dieser Dateien ist vdr.
    Nu bin ich ratlos....



    NACHTRAG: Gleiches Verhalten, wenn vdr als rot gestartet wird. Nur der Owner der Dateien hat sich entsprechend geändert.


    Viele Grüße


    gehlhajo

    VDR-1: streamdev-server | Hummingboard2| TT 3600 USB | Siemens S500 Gehäuse | Archlinux mit eigen Skripten
    VDR-2: streamdev-client | rpihddevice | Raspberry 2b | Siemens S450 Gehäuse| Remote: URC6410 | LG 42LV4500 |     Archlinux mit eigenen Skripten


    Einmal editiert, zuletzt von gehlhajo ()

    Zitat

    Original von gehlhajo
    ..... mit der Größe 0Byte angelegt. Und zwar in jedem der 10 Verzeichnisse.


    Sind das echte Daten oder special files? (ls -l) burn legt fifo-Files an, damit vdrsync da reinschreibt und die Daten direkt an das nächste Programm weitergibt. Ich denke vdrsync hängt eher, weil es auf Eingaben wartet.
    Das Problem ist aber nicht das altbekannte mit dem Hänger bei DD-Ton von vdrsync?

    Hi

    Zitat

    Original von FireFly
    Das Problem ist aber nicht das altbekannte mit dem Hänger bei DD-Ton von vdrsync?


    Ich kenne das Problem zwar nicht, aber ich denke nicht.
    vdr-burn funktioniert einwandfrei, wenn es nicht requantisieren muss.
    Ich habe gerade eben nocheinmal eine Versuch mit 5 Frasier-Dateien gemacht. Auch hier werden diese wie Du schreibst FIFO-Files angelegt. Aber vdrsync fängt dann an an zu arbeiten. D.h es ist unter "top" an erster Stelle zu finden.
    Wenn requant ins Spiel kommt scheint vdrsync auf etwas zu warten. Nur auf was ?

    VDR-1: streamdev-server | Hummingboard2| TT 3600 USB | Siemens S500 Gehäuse | Archlinux mit eigen Skripten
    VDR-2: streamdev-client | rpihddevice | Raspberry 2b | Siemens S450 Gehäuse| Remote: URC6410 | LG 42LV4500 |     Archlinux mit eigenen Skripten


Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden