Burn 0.1.0 Public Beta bis -pre12 [alt]

    Zitat

    Original von wilderigel
    dvd.log gibts dazu auch?
    Vieleicht steht da ja was interessantes drinnen?


    Ne, da steht nicht interessantes!



    Vielleicht kommt libcdio mit den erkennen der Medien nicht klar?


    Gruss,
    Chuck

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

    Hi , wilderigel


    Das is es ja grade > dvd.log und auch syslog
    schweigen sich aus.
    Nirgends ein aufschlussreicher Hinweis.


    Gruss , Bert

    Hardware: Intel Core i9-9900K, ASUS ROG Maximus XI Hero, MSI GeForce GTX 1050 Ti (vdpau), Dvbsky S952 V3 mit 2X DVB-S2 Tuner
    Multibootsystem (yavdr-ansible auf Ubuntu-20.04, Kubuntu-20.04 Focal Fossa, Win10)
    yavdr-ansible, Ausgabe über Nvidia vdpau

    Bert: ich nutze die aktuellste Project X Version (0.90.4.00)


    dad401:

    Das kann so sein, muß aber nicht. Ich habe was im Hinterkopf, daß VDR mittlerweile die Sream-IDs beim remuxen selbst vergibt, so daß z.B. der Video Stream jetzt immer E0 ist - ich habe aber auch noch Aufnahmen mit E4. Und wenn jetzt im OSD ein Audio-Stream abgewählt wird - welcher ist es dann?? Und wenn's mehr als zwei mp2-Streams sind ...
    Schön wäre es, wenn das burn-plugin neben den zu ignorierenden Streams in $IGNORE auch die zu übertragenden Streams in einer Umgebungsvariablen liefern würde, dann könnte man das direkt als Parameter Project X übergeben. Ebenso die Reihenfolge der Streams wäre in einer Umgebungsvariablen interessant.
    In der info.vdr steht noch die Sprachen aller Audiostreams, es wäre auch schön, wenn man die direkt an dvdauthor übergeben kann (im Tag <audio lang="xx">) - da gibts noch einiges zu basteln ....


    FireFly

    Hi,


    @ FireFly


    Thanks, die hab ich auch eben hier installiert.


    Gruss , Bert

    Hardware: Intel Core i9-9900K, ASUS ROG Maximus XI Hero, MSI GeForce GTX 1050 Ti (vdpau), Dvbsky S952 V3 mit 2X DVB-S2 Tuner
    Multibootsystem (yavdr-ansible auf Ubuntu-20.04, Kubuntu-20.04 Focal Fossa, Win10)
    yavdr-ansible, Ausgabe über Nvidia vdpau

    Wenn man eine DVD mit Menü und mehreren Filmen erzeugt, dann ist im Menü der DVD der erste Titel immer als "Hauptüberschrift" zu sehen. Zweitens ist immer nur ein Teil der Filmnamen zu sehen obwohl noch genug Platz da wäre. Sind DVD-Menüs so unfelexibel?

    vdrchuck:
    Der will die DVD eigentlich ejecten, weil er meint es liegt kein leerer Rohling drin.


    Kann die Erkennung der libcdio wirklich so unzuverlässig sein?! Wozu gibt es sie dann und wieso schaffen andere Programme (growisofs!) das dann auch? Warum entschliesse ich mich überhaupt eine fertige Lib einzusetzen, statt selbst zu erkennen, wenn die Lib eh für'n Hintern ist? :§$%


    Eigentlich war das als Service gedacht, aber naja im Zweifel wirds wieder wie früher gemacht, wenn growisofs fehlschlägt wird penetrant nach nem Rohling gefragt (auch wenn der Fehler aussagt dass der Brenner sich grad auflöst, egal)


    Also wird es am Wochenende ein Testprogramm geben um die verschiedenen Ergebnisse mit der libcdio und evtl. Alternativen (?) mal zu protokollieren.


    wilderigel:
    Im Log kommt nichts weil die Arbeit von cdio im VDR stattfindet, im dvd.log landen nur die separaten Unterprozesse.


    @Fluffy01:
    Bei den Breiten der Titel könntest Du Recht haben (hast Du ne Vorlage probiert wo der Titel eingerahmt ist? Da musses passen ;) ). Den Titel der DVD kannst Du editieren wie die der Aufnahmen. Da der Job beim Hinzufügen der 1. Aufnahme erzeugt wird nimmt er halt deren Titel als Jobtitel.


    Zu ProjectX kann ich nur sagen - ich lese mit und ich grüble mit - und ausprobieren (bzw. dann auch einbauen) werde ichs auch am Wochenende, nur unter der Woche komme ich kaum dazu ;)


    FireFly:
    Um eine Liste der zu verwendenden IDs werde ich mich kümmern, das ist kein Problem.


    Mit einer nagelneuen DVD+RW konnte ich einmal erfolgreich brennen, dannach gabs es mit dieser Scheibe immer Fehler (ich habe jetzt keine neue mehr zum testen).
    Das brennen über Script DVDSwitch (growisofs) funktioniert dagegen einwandfrei.
    Wenn ich mir mit ldd groisofs anschaue wird dort die libcdio nicht benutzt(?).


    Leider kann ich an den Tests am WE nicht teilnehmen :( , da ich eine Woche im Urlaub bin. :sonne



    Gruss,
    Chuck

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

    Zitat

    Original von LordJaxom
    vdrchuck:
    Kann die Erkennung der libcdio wirklich so unzuverlässig sein?! Wozu gibt es sie dann und wieso schaffen andere Programme (growisofs!) das dann auch? Warum entschliesse ich mich überhaupt eine fertige Lib einzusetzen, statt selbst zu erkennen, wenn die Lib eh für'n Hintern ist? :§$%


    Also beim dvdswitch Schreib-Script wird dvd+rw-mediainfo (dvd+rw-tools) verwendet um herauszufinden welcher Datenträger im Laufwerk ist.
    Ev wäre das zuverlässiger?

    Zitat

    Original von wilderigel
    Also beim dvdswitch Schreib-Script wird dvd+rw-mediainfo (dvd+rw-tools) verwendet um herauszufinden welcher Datenträger im Laufwerk ist.
    Ev wäre das zuverlässiger?


    Also das Script was ich einsetzt (damals aus dem Wiki) prüft nicht welches Medium eingelegt ist.
    Dieses Script kannte ich bis jetzt noch gar nicht, ich poste mal hier die relevate Ausgaben bei meiner DVD+RW:


    dvd+rw-mediainfo /dev/dvd


    dvd+rw-mediainfo /dev/dvd | grep "^ Disc status" | cut -d":" -f2 | sed -e ' s/ //g'

    Code
    complete


    dvd+rw-mediainfo /dev/dvd | grep "^ Mounted Media" | cut -d" " -f13

    Code
    DVD+RW

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

    Zitat

    Original von FireFly
    Das kann so sein, muß aber nicht. Ich habe was im Hinterkopf, daß VDR mittlerweile die Sream-IDs beim remuxen selbst vergibt, so daß z.B. der Video Stream jetzt immer E0 ist - ich habe aber auch noch Aufnahmen mit E4. Und wenn jetzt im OSD ein Audio-Stream abgewählt wird - welcher ist es dann??


    Ok, ich hab es nur vermutet, dass sie gleich sind (da ich immer nur diesselben gesehen habe. Allerdings ist die Trackauswahl doch nicht nötig, wie ich festgestellt habe. Hier nochmal meine vdrburn-dvd.sh Änderungen (inkl. Deiner):

    Es ist egal, was PJX erstellt und was dann gepipt wird, da mplex (durch das Burn-Plugin) sich anscheinend eh nur bestimmte (die ausgewählten Tracks) vdrsync.* vornimmt. Unschön ist evtl. nur, dass die abgewählten Spuren unnötig umgelenkt werden. Davon abgesehen, fehlt auch noch die Information wieviele Tracks benötigt werden. Momentan werden im obigen Beispiel nur 3(mp2)+1(ac3) behandelt. Ansonsten läuft das ganze schonmal sehr gut. Getestet mit requant, ohne requant und mit einem Filmstück, dass AC3 und 2xMP2 enthält (in unterschiedlichen Kombinationen getestet) - vdrsync.pl stieg mir bei dem Film immer aus ;)


    Zitat

    Original von FireFlyin $IGNORE auch die zu übertragenden Streams in einer Umgebungsvariablen liefern würde, dann könnte man das direkt als Parameter Project X übergeben.


    Im Source (chain-dvd.c) des Burnplugins muss man IMHO nur eine neue Variable mit put_environment hinzufügen...


    Zitat

    Original von FireFly
    In der info.vdr steht noch die Sprachen aller Audiostreams, es wäre auch schön, wenn man die direkt an dvdauthor übergeben kann (im Tag <audio lang="xx">) - da gibts noch einiges zu basteln ....


    Jetzt wo Du es erwähnst - wäre toll :) - hab bei meinen Test auch nur immer Audio1 und Audio2 auswählen können, statt Deutsch und AC3 etc...


    @all


    Da ich hier das Burn-Plugin für VDR 1.3.36 übersetzt habe, musste ich die Funktion Skins.QueueMessage durch die alte? Skin.Message ersetzten. Bisher gab es noch keine spürbaren Probleme, aber trotzdem mal die Frage: könnte es welche geben, oder ist das kein Problem?

    My VDRs:

    Zitat

    Original von dad401
    Im Source (chain-dvd.c) des Burnplugins muss man IMHO nur eine neue Variable mit put_environment hinzufügen...


    Naja und in jobs.c eine Funktion die einen String mit Hex-Zahlen und Kommas aus dem Array der benutzten Spuren aggregiert, aber das bau ich Euch schon ;)


    EDIT:


    Zitat

    Da ich hier das Burn-Plugin für VDR 1.3.36 übersetzt habe, musste ich die Funktion Skins.QueueMessage durch die alte? Skin.Message ersetzten. Bisher gab es noch keine spürbaren Probleme, aber trotzdem mal die Frage: könnte es welche geben, oder ist das kein Problem?


    Prinzipiell dieselben Probleme die das Burn-Plugin früher selbst hatte ;D - nämlich dass man Message (im Gegensatz zu QueueMessage) nicht aus einem fremden Thread heraus starten darf, sondern nur im Menücode. Wenn nun allerdings das eigene Menü nicht offen ist nutzt einem das nicht sonderlich viel, da man sich in fremde Menüs nicht einmischen kann.

    Zitat

    Original von LordJaxom
    ... aber das bau ich Euch schon ;)


    Danke :) - lass Dir ruhig Zeit...


    Zu QueueMessage: ab V1.3.37 ist´s im VDR - und ich hab 1.3.36 :( - naja solang es erstmal geht lass ich es - hab keine Lust den VDR mit allen Plugins nochmal neu zu kompilieren + testen...

    My VDRs:

    LordJaxom: viking hat mich auf diesen Thread hier aufmerksam gemacht. Würde nun gerne die dmh-video-archiv-dvd einbauen und Dir als Patch zukommen lassen. Nun ein paar Fragen dazu:


    1. Ich benutze im Moment vdr 1.3.44. Sollte die Version damit laufen?


    2. Soll ich die CVS-Version Deines Plugins nehmen oder welche?


    3. Gibt's da noch irgendetwas zu beachten? Hinweise o. Ratschläge?




    Besten Dank. DMH

    Hardware: AMD Duron 900 MHz, 256 MB Ram, 1 x 400 GB und 2 x 200 GB Maxtor, 1 x 500 GB USB 2.0, Nec DVD-RW ND-3500AG, 1 x TT 1.6 FF DVB-S, 1 x Twinhan Budget DVB-T
    Software: VDR 1.4.1, BigPatch, DMH-DVD-Archive-Patch, Kernel 2.6.12
    ---
    "Hörma, wie heißt nomma dat Instrument mit den 3 Knöppen oben drauf...? - Ja richtig, Flöte!"

    dmh:
    Gerne ;)


    zu 1. Jup, eigentlich sollten (noch :mua) alle ab 1.3.37 laufen
    zu 2. Am besten CVS, am zweitbesten die letzte -pre ;)
    zu 3. Bereite Dich darauf vor dass die meisten Funktionen aus dem C-Standard durch C++-Pendants ersetzt wurden, und dass die Klassenhierarchie jetzt Namespace-aware ist und kein Klassenprefix (cMenu) mehr benutzt.

    Ich wuerde mich erstmal auf die bestehenden Bugs,etc.
    beschraenken , anstatt gleich wieder jedes Feature einzubauen.
    Sonst heisst es bald wieder vdrplugin-burn-0.1.90000i-pre100 ;)


    Der Ansatz war doch gut ..Zeit lassen aber dafuer richtig , ohne
    Workarounds.
    Das mit ProjectX sieht mir doch schon wieder a bisserl danach aus. ;)

    @Morone:
    Klar werden jetzt hauptsächlich Bugs gefixt. Aber wenn man absehen kann dass sich bestehende Verhaltensweisen durch einen Patch nicht ändern (also nur neue Funktionen hinzugefügt und irgendwo aufgerufen werden), habe ich auch nichts dagegen ihn zu adaptieren... ;)


    EDIT:
    Und "Zeit lassen - richtig machen" war sowieso die Devise der Überarbeitungen - deshalb hat's ja so lange gedauert. Aber ich hoffe durch die Restrukturierung auch erreicht zu haben dass Änderungen und Ergänzungen künftiger leichter von der Hand gehen. Und ich möchte schon, dass burn 0.1.0 (ohne -pre hintendran) in LinVDR 0.8 enthalten ist ;D - also wird sowieso nichts mehr passieren was die Stabilität ernsthaft gefährden könnte (die Menücode-Umstellung war in der Richtung die letzte Aktion, auch wenn der Rendering-Code eigentlich auch mal neu gehört).

    dad401:

    Zitat
    Code
    +               if [ ! -z $REQUANT_FACTOR ]; then
+                   cat "$MPEG_PATH/pjx.m2v" | /usr/local/bin/requant $REQUANT_FACTOR > "$MPEG_PATH/pjxreq.m2v"
+                   mv "$MPEG_PATH/pjxreq.m2v" "$MPEG_PATH/pjx.m2v"
+               fi    
                ...
+               test -f "$MPEG_PATH/pjx.m2v" && { cat "$MPEG_PATH/pjx.m2v" >"$MPEG_PATH/vdrsync.mpv"& }


    Grmmmpfff. So hatte ich das nicht gemeint, eher so (Vorsicht, habs nicht ausprobiert)

    Code
    REQUANTCMD=""
                if [ ! -z $REQUANT_FACTOR ]; then
                        REQUANTCMD="| requant $REQUANT_FACTOR "
                fi
                ...
                test -f "$MPEG_PATH/pjx.m2v" && { cat "$MPEG_PATH/pjx.m2v" $REQUANTCMD >"$MPEG_PATH/vdrsync.mpv"& }


    Sonst wird ja doch wieder ne temporäre Datei gescchrieben und genau das soll ja mit der neuen Version (möglichst) vermieden werden. Dummer weise muß das Pipe-Zeichen genau auf der anderen Seite stehen als beim vdrsync.pl X(


    Greets
    FireFly

    Zitat

    Original von FireFly
    Grmmmpfff. So hatte ich das nicht gemeint, eher so (Vorsicht, habs nicht ausprobiert)


    Hast ja recht - ich habe dies jedoch nur gemacht, da es als zusätzliche pipe (so wie in Deinem ungetesteten Codeanhang) nicht funktionieren wollte?! Wenn´s bei Dir klappt gib Bescheid...


    Momentan habe ich allerdings ein anderes Problem festgestellt: Ich habe hier einen Film (1x Video, 1x Audio, kein AC3), aus welchen ich mit vdrsync.pl ohne Probleme ein iso erstellen kann.
    Nehme ich nun aber PJX (also die geänderte vdrburn-dvd.sh (requant mal aussen vor gelassen)), dann bricht er zum Schluss bei dvdauthor ab :( - d.h. dvdauthor arbeitet einwandfrei (STAT: ...) und ab einem gewissen Zeitpunkt (nach einer der vielen STAT:-Ausgaben) ist Schluss und die Konvertierung wird im Burn-Plugin als fehlerhaft gemeldet.



    (Die Punkte kennzeichnen Auslassungen)



    Ideen?!

    My VDRs:

    Einmal editiert, zuletzt von dad401 ()

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden