Burn 0.1.0 Public Beta ab -pre13

ciax · 31. Mai 2006

nachtrag:

hallo,
hier wäre noch als nachtrag das plug-setup (/etc/../setup.conf):
--------------
.
.
burn.BurnSpeed = 0
burn.ChaptersMode = 2
burn.CreateArchiveMarks = 0
burn.CustomDiskSize = 4200
burn.CutOnDemux = 0
burn.DemuxType = 0
burn.DiskSize = 0
burn.DiskType = 0
burn.DVDSize = 4350
burn.HidePathInfo = 1
burn.OfferChapters = 1
burn.OfferCutOnDemux = 1
burn.OfferDiskSize = 1
burn.OfferStoreMode = 1
burn.RemovePath = 0
burn.RenderRecordingIndex = 0
burn.StoreMode = 1
burn.UseIso2UTF = 1
burn.VerifyAfterBurn = 0
.
.
------------

ciax

ciax · 31. Mai 2006

-->> nur als info - die prozesse die nun beim wandeln laufen:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31853 root 35 19 32996 30m 1536 R 45.9 3.4 4:46.13 vdrsync.pl
31855 root 34 19 7368 3816 1032 R 19.9 0.4 2:17.43 mplex
31854 root 34 19 34444 3016 404 S 11.6 0.3 1:53.01 requant
31601 root 35 19 33768 29m 1060 R 4.7 3.3 0:57.15 dvdauthor
31861 root 34 19 3420 1516 664 S 4.3 0.2 0:20.70 burn-buffers
31862 root 34 19 2680 900 664 S 0.3 0.1 0:00.83 burn-buffers

ciax · 31. Mai 2006

--> muß leider ernüchtern:

nun läufts mit den 2 problemdateien. in vdrburn-dvd.sh sollte die option -S bei mplex aktiviert sein! nicht -M!

mplex -f 8 -S 8000 -o $MOVIE_FILE $VIDEO_FILE $AUDIO_FILES
(.. ist 2x im script zu editieren)

die 2 problem-recordings wurden gewandelt (mit bisherig angegebenen optionen/versionen):
---
.
.
[burn] 99.36% done, estimate finish Wed May 31 00:32:57 2006
[burn] 99.59% done, estimate finish Wed May 31 00:32:57 2006
[burn] 99.83% done, estimate finish Wed May 31 00:32:57 2006
[burn] Total translation table size: 0
[burn] Total rockridge attributes bytes: 0
[burn] Total directory bytes: 4096
[burn] Path table size(bytes): 42
[burn] Max brk space used 21000
[burn] 2113593 extents written (4128 MB)
[burn] + exit 0
---

bei einer einzelnen aufnahme, die 5535MB groß ist, kommt's wieder zum spli-error trotz angepasster vdrburn-dvd.sh:

.
.
demux] 5160 Mbytes of 5535 read
[author] STAT: VOBU 13088 at 3895MB, 1 PGCS
[demux] 5170 Mbytes of 5535 read
[author] STAT: VOBU 13104 at 3900MB, 1 PGCS
[mplex] INFO: [mplex] Scanned to end AU 157295
[mplex] ++ WARN: [mplex] No seq. header starting new sequence after seq. end!
[mplex] INFO: [mplex] Sequence end marker! Running out...
[mplex] INFO: [mplex] Run out PTS limit to AU 157297 566293165 SCR=566236452
[mplex] INFO: [mplex] Video e0: buf= 140204 frame=157295 sector=01822521
[mplex] INFO: [mplex] Audio bd: buf= 15453 frame=196617 sector=00099869
[mplex] INFO: [mplex] Audio c1: buf= 2537 frame=262141 sector=00062291
[author] WARN: attempt to update aspect ratio from 4:3 to 16:9; skipping
[mplex] **ERROR: [mplex] Need to split output but there appears to be no %d in the filename pattern /video/burn_plug_tmp/.vdr-burn.ckBmIQ/VDRSYNC.0/movie.mpg
------------------

ciax

LordJaxom · 31. Mai 2006

Zitat

Original von ciax
[mplex] INFO: [mplex] Sequence end marker! Running out...

Und jetzt mach mal -S 8000 und -M

viking · 31. Mai 2006

Hallo,

habt ihr sicherlich auch dran gedacht, aber wenn es nicht anders geht notfalls im script einen kleinen test einbauen

Code

mplex -h 2>&1 |grep -q "\-\-ignore-seqend-markers"
[ $? -eq 0 ] && MPLEXOPT="-M"
mplex $MPLEXOPT ...

Aber schöner wäre natürlich eine lösung ohne ...

Mein mplex (packman suse 9.1) :

# mplex 2>&1|head -1
mjpegtools mplex-2 version 1.8.0 (2.2.4)

# mplex -h 2>&1 |grep "\-\-ignore-seqend-markers"
--ignore-seqend-markers|-M

Gruß
Viking

LordJaxom · 31. Mai 2006

Okay, also ich bin mir inzwischen ziemlich sicher dass der Bruch in der Version 1.8.0 eingefügt wurde.

Ich denke ich werde im Script tatsächlich eine solche Prüfung einbauen, ist ja nun zum Glück kein unlösbares Problem (auch wenn Konsistenz natürlich schöner wäre)

dmh
Der Index ist weggefallen, weil die Recordings eh immer in der richtigen Reihenfolge liegen. Früher wurde ein Index vertauscht und dann die Liste neu sortiert, was ich etwas schwachsinnig fand, deshalb werden jetzt direkt die Elemente getauscht.
Wenn Du selbst über die Recordings gehst, kannst Du den Index also mitzählen, wenn Du den m_current Iterator benutzt kannst Du distance benutzen:

Code

std::distance(get_recordings().begin(), m_current);

foobar42 · 31. Mai 2006

Zitat

Original von viking
habt ihr sicherlich auch dran gedacht, aber wenn es nicht anders geht notfalls im script einen kleinen test einbauen

Und bei der nächsten Änderung rennt das script dann ins Leere. Da man dann eh zu Fuß ran muss, kann man's auch gleich.

LordJaxom · 31. Mai 2006

Bei der nächsten Änderung kann auch ohne Prüfung sonstwas passieren (hier ist sonstwas passiert, weil kein Schwein ahnen konnte dass sowas geändert wird).

Ich denke mit einer Prüfung ist mehr Leuten geholfen als ohne (zumal die Änderung in einer neueren mjpegtools Version stattfand, auf die ich früher oder später auch updaten werde/muss)

ciax · 31. Mai 2006

@LordJaxom:

--> S U C C E S S !!

jetzt hat er auch die lange aufzeichnung (5535MB) in ein ISO gewandelt und geshrinkt!! Danke für den Tipp - beide Parameter [-M -S] werden bei mir nach mplex in der vdrburn-dvd.sh benötigt

"mplex -f 8 -S 12000 -M -o ..."

ciax

ps: dvd.log output
---------
.
.
[burn] 99.56% done, estimate finish Wed May 31 10:33:25 2006
[burn] 99.80% done, estimate finish Wed May 31 10:33:24 2006
[burn] Total translation table size: 0
[burn] Total rockridge attributes bytes: 0
[burn] Total directory bytes: 4096
[burn] Path table size(bytes): 42
[burn] Max brk space used 21000
[burn] 2139352 extents written (4178 MB)
[burn] + exit 0
---------

ciax · 31. Mai 2006

hallo,

ich werde lamgsam lästig, stimmt's. also das mit der großen 5GByte aufzeichnung hat funktioniert. jetzt wollte ich einmal 3 aufzeichnungen, die zusammen ein bißchen weniger als 8GByte benötigen, zu einem ISO wandeln.

--> NEP!

dvd.log:
------
.
.
[demux] 3100 Mbytes of 3111 read
[author] STAT: VOBU 7504 at 1592MB, 1 PGCS
[author] STAT: VOBU 7520 at 1596MB, 1 PGCS
[demux] 3110 Mbytes of 3111 read
[demux] 3111 Mbytes of 3111 read
[demux] 1736665 PES packets processed
[demux] Assuming final sync for stream bd, cause there is no new chunk_start
[demux] Assuming final sync for stream c0, cause there is no new chunk_start
[demux]
[demux] Finished processing /video/Universum/2006-05-16.20.14.50.99.rec/
[author] STAT: VOBU 7536 at 1599MB, 1 PGCS
[demux] No need to finish DVD Image, since there is none
[demux] Last fork ended for vdrsync.pl 14673
[demux] + exit 0
[requant] + exit 0
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=325640484 required(DTS)=325640365
[mplex] ++ WARN: [mplex] Video e0: buf= 40129 frame=090452 sector=00718927
[mplex] ++ WARN: [mplex] Audio bd: buf= 1373 frame=113063 sector=00057429
[mplex] ++ WARN: [mplex] Audio c1: buf= 917 frame=150750 sector=00035822
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=325684370 required(DTS)=325640365
[mplex] ++ WARN: [mplex] Video e0: buf= 0 frame=090452 sector=00719227
[mplex] ++ WARN: [mplex] Audio bd: buf= 0 frame=113063 sector=00057429
[mplex] ++ WARN: [mplex] Audio c1: buf= 0 frame=150750 sector=00035822
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=325728256 required(DTS)=325640365
[mplex] ++ WARN: [mplex] Video e0: buf= 0 frame=090452 sector=00719527
[mplex] ++ WARN: [mplex] Audio bd: buf= 0 frame=113063 sector=00057429
[mplex] ++ WARN: [mplex] Audio c1: buf= 0 frame=150750 sector=00035822
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=325772141 required(DTS)=325640365
.
.
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=325991570 required(DTS)=325640365
[mplex] ++ WARN: [mplex] Video e0: buf= 0 frame=090452 sector=00721327
[mplex] ++ WARN: [mplex] Audio bd: buf= 0 frame=113063 sector=00057429
[mplex] ++ WARN: [mplex] Audio c1: buf= 0 frame=150750 sector=00035822
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=326035456 required(DTS)=325640365
[mplex] ++ WARN: [mplex] Video e0: buf= 0 frame=090452 sector=00721627
[mplex] ++ WARN: [mplex] Audio bd: buf= 0 frame=113063 sector=00057429
[mplex] ++ WARN: [mplex] Audio c1: buf= 0 frame=150750 sector=00035822
[mplex] ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=326079341 required(DTS)=325640365
[mplex] ++ WARN: [mplex] Video e0: buf= 0 frame=090452 sector=00721927
[mplex] ++ WARN: [mplex] Audio bd: buf= 0 frame=113063 sector=00057429
[mplex] ++ WARN: [mplex] Audio c1: buf= 0 frame=150750 sector=00035822
[mplex] **ERROR: [mplex] Too many frame drops -exiting
----------

gruß, ciax

LordJaxom · 31. Mai 2006

Ähm, gut, okay, wenn der Multiplexer (aufgrund von defektem Stream?) die Waffen streckt, kann ich dann auch nichts weiter mehr tun...

Versuch evtl. mal mit ProjectX zu demuxen.

ciax · 31. Mai 2006

..werde ich machen und warte auf deine nächste 0.1.0-pre (mit tcmplex?)

LordJaxom · 31. Mai 2006

Tcmplex ist vom transcode-Team doch (zugunsten mplex) gestrichen worden wie wir festgestellt haben. Ich denke dann macht es auch nicht viel Sinn ihn dennoch zu unterstützen.

Es gibt übrigens mit Sicherheit immer mal wieder ne Aufnahme die sich um's verrecken nicht (vollständig) konvertieren lässt. So habe ich z.B. kürzlich eine Aufnahme gehabt die nur mit ProjectX erfolgreich demuxed wurde, danach eine die nur mit vdrsync demuxed wurde, und zwei, bei denen keiner von beiden die AC3-Spur extrahieren kann (aus denen man aber mit nur-stereo einwandfreie DVDs bekommt).

So mächtig dass es solch "fortgeschrittenen" Situationen (Beispiel: AC3 wird von vdrsync.pl -i erkannt, aber nicht demuxed, bzw. vdrsync erzeugt leere .ac3 Datei) erkennt und vermeidet wird das Plugin zur 0.1.0 wohl auch nicht werden...

ciax · 31. Mai 2006

.. ooops - ja stimmt! sorry, wurde weiter oben diskutiert (bzgl. tcmplex)! was hat es mit "tcmplex-panteltje" eigentlich auf sich?

aber: das plugin ist doch jetzt schon recht "mächtig"! also dickes lob für die unermüdliche arbeit an dich!

skobi · 31. Mai 2006

Kennt jemand VideoTrans? Laut Doku kann es alle Videofiles die mplayer lesen kann nach VOB konvertieren... hab es selbst noch nicht getestet, aber ggf. wäre es ja mal einen Blick wert: VideoTrans

Skobi

dmh · 31. Mai 2006

Hi zusammen,

nach längerer Dürre bin ich nun auch mal wieder am Start. Im Schlepptau die neuste Version des DMH-Archive-Patches. Sie passt für die brandneue Pre14 von LordJaxom, dem ich an dieser Stelle für seine gute, kontinuierliche Arbeit danke und die nicht einmal darunter leidet, wenn sie durch ständige Fragen wie zum Beispiel von mir unterbrochen wird: Thanx!

Änderung gegenüber Version 3:

angepasst an Pre14
Erstellen der symb. Links im Temp-Verzeichnis (vorgeschlagen von amicus@vdrportal)
Übernahme der info.vdr-Dateien in das DMH-Archiv (vorgeschlagen von viking@vdrportal)

Nach Anwenden meines Patches läuft der Submenu-Patch (burn-0.1.0-pre13-submenubg.2.diff) von Samurai ohne Rejects durch. (Habe ihn also nicht eingebaut.)

Die normalen Archiv-DVDs sind gänzlich ungetestet, also bitte testen. Die DMH-DVDs habe ich schon ein paar testweise erstellt, aber weitere Tests schaden nicht...

DMH

EDIT: Bitte nicht vergessen, die vdrburn-dvd.sh und vdrburn-archive.sh in den path zu kopieren!!!

Samurai · 31. Mai 2006

Endlich habe ich Zeit, mir die Pre14 mal anzuschauen.

Ist es Absicht, daß burn-buffers nicht mehr mitgeliefert wird ? Soweit ich das sehe, wird das Programm noch immer als Filter verwendet.

Natürlich habe ich das file noch, aber so etwas verletzt irgendwie meinen Ordnungssinn

ciax · 1. Juni 2006

pre14 läuft nun mit ProjecX demuxer auch mit sämtlichen Problemaufzeichnungen stabil!

gruß, ciax

LordJaxom · 1. Juni 2006

Samurai:
Öh? burn-buffers wird doch beim make all gebaut? (Und make plugins macht in jedem Verzeichnis ein make all)

Ich kann es gerade nur visuell bestätigen, da ich hier nicht alle Dependencies auflösen kann, aber ich sehen keinen Grund warum make plugins -> make all -> make burn-buffers nicht so ablaufen sollte wie bisher....

stefan.h · 1. Juni 2006

Hi,

ich habe das Problem mit pre14, das das Plugin immer versucht auf den DVD Brenner zuzugreifen obwohl ich nur Image erstellen eingestellt habe (Ausführender User hat keine Berechtigung, braucht er auch nicht zum Erstellen des Images).

Gruß
Stefan

Burn 0.1.0 Public Beta ab -pre13

Jetzt mitmachen!

Teilen