Out of Memory mit vdr-burn-0.1.0-pre2

Irgendwie habe ich befürchtet dass es dazu kommen würde..

Zur Erklärung wie es dazu kommt:
Um genau zu sein laufen nicht alle Prozesse parallel. Sie werden nur parallel gestartet, dann öffnet dvdauthor die Fifos nacheinander und arbeitet die Videos komplett ab bevor es das nächste anfängt. Dummerweise benötigen die Prozesse in der Pipe vorab ihren Speicher...

Ich werde morgen mal sehen wie ich die Prozessstruktur umgekrempelt bekomme um dvdauthor die Files nacheinander anzugeben, ohne die Pipe aufgeben zu müssen...

LordJaxom:

Gibt es hier schon eine Lösung von dir zum burn-Plugin?

Bei mir bleibt mit burn-0.1.0-pre2 immer die Konvertierung stehen, sobald ich soviel auf eine DVD quetschen will, dass das requatisieren notwendig wird. DVD erstellen ohne requant geht problemlos.

Ich habe ebenfalls nur 128 MB RAM.

Viele Grüße
TeeRose

Hallo,
ich habe jetzt mal von 128Mb auf 640MH Hauptspeicher aufgerüstet. Allerdings bricht der burn-Vorgang immer noch ab, wenn ich z.B. wie hier 5 Star Trek Folgen auf eine DVD bringen will und burn das Requantsieren aufruft:

...
   INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
+ REQUANTCMD=
+ '[' '!' -z 1.120000 ']'
+ REQUANTCMD=requant 1.120000 |
+ IGNORE=
+ '[' '!' -z ']'
+ vdrsync.pl -o /tmp/.vdr-burn.suMIHQ/VDRSYNC.3 -v-filter 'requant 1.120000 | burn-buffers > vdrsync.mpv' -a-filter 'burn-buffers > vdrsync%%d.mpa' -ac3-filter 'burn-buffers > vdrsync%%d.ac3' $'/data/video0/test/Star_Trek_-_Das_n\344chste_Jahrhundert/%1.04_-_Der_Ehrenkodex/2006-03-02.17.15.40.99.rec'
+ mplex -f 8 -o /tmp/.vdr-burn.suMIHQ/VDRSYNC.3/movie.mpg /tmp/.vdr-burn.suMIHQ/VDRSYNC.3/vdrsync.mpv /tmp/.vdr-burn.suMIHQ/VDRSYNC.3/vdrsync0.mpa
   INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
+ REQUANTCMD=
+ '[' '!' -z 1.120000 ']'
+ REQUANTCMD=requant 1.120000 |
+ IGNORE=
+ '[' '!' -z ']'
+ vdrsync.pl -o /tmp/.vdr-burn.suMIHQ/VDRSYNC.4 -v-filter 'requant 1.120000 | burn-buffers > vdrsync.mpv' -a-filter 'burn-buffers > vdrsync%%d.mpa' -ac3-filter 'burn-buffers > vdrsync%%d.ac3' $'/data/video0/test/Star_Trek_-_Das_n\344chste_Jahrhundert/%1.05_-_Der_W\303\244chter/2006-03-03.17.13.40.99.rec'
+ mplex -f 8 -o /tmp/.vdr-burn.suMIHQ/VDRSYNC.4/movie.mpg /tmp/.vdr-burn.suMIHQ/VDRSYNC.4/vdrsync.mpv /tmp/.vdr-burn.suMIHQ/VDRSYNC.4/vdrsync0.mpa
+ dvdauthor -x /data/video0/.vdr-burn.cF3Qm0/dvd.xml
   INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
DVDAuthor::dvdauthor, version 0.6.11.
Build options: gnugetopt magick iconv freetype fribidi
Send bugs to <dvdauthor-users@lists.sourceforge.net>


INFO: Locale=C
INFO: Converting filenames to ANSI_X3.4-1968
INFO: dvdauthor creating VTS
STAT: Picking VTS 01


STAT: Processing /data/video0/.vdr-burn.cF3Qm0/VDRSYNC.0/menu-bg-0.mpg...


INFO: Video pts = 0.184 .. 0.224
INFO: Audio[8] pts = 0.184 .. 1.168
INFO: Audio[32] pts = 0.184 .. 0.184
STAT: VOBU 1 at 0MB, 1 PGCS


INFO: Generating VTSM with the following video attributes:
INFO: MPEG version: mpeg2
INFO: TV standard: pal
INFO: Aspect ratio: 4:3
INFO: Resolution: 720x576
INFO: Audio ch 0 format: mp2/2ch, 48khz 20bps


STAT: Processing /tmp/.vdr-burn.suMIHQ/VDRSYNC.0/movie.mpg...
Parameter validation not complete yet
Checking lock file /tmp/vdrsync_lock_3055
Parameter validation not complete yet
Checking lock file /tmp/vdrsync_lock_3057
Parameter validation not complete yet
Checking lock file /tmp/vdrsync_lock_3051
lock file /tmp/vdrsync_lock_3055 not there
lock file /tmp/vdrsync_lock_3051 not there
lock file /tmp/vdrsync_lock_3057 not there
Parameter validation not complete yet
Checking lock file /tmp/vdrsync_lock_3044
lock file /tmp/vdrsync_lock_3044 not there
lock file /tmp/vdrsync_lock_3051 created
Parameter validation not complete yet
lock file /tmp/vdrsync_lock_3055 created
lock file /tmp/vdrsync_lock_3057 created
lock file /tmp/vdrsync_lock_3044 created
Checking lock file /tmp/vdrsync_lock_3048
lock file /tmp/vdrsync_lock_3048 not there
lock file /tmp/vdrsync_lock_3048 created
Initialising and analysing the streams....
Initialising and analysing the streams....
Initialising and analysing the streams....
Initialising and analysing the streams....
Initialising and analysing the streams....






  10 Mbytes of 996 readM2VRequantiser by Makira.
Using 1.120000 as factor.




  10 Mbytes of 908 readM2VRequantiser by Makira.
Using 1.120000 as factor.
  10 Mbytes of 1003 readM2VRequantiser by Makira.
Using 1.120000 as factor.
  10 Mbytes of 940 readM2VRequantiser by Makira.
Using 1.120000 as factor.
  10 Mbytes of 979 readM2VRequantiser by Makira.
Using 1.120000 as factor.
   INFO: [mplex] File /tmp/.vdr-burn.suMIHQ/VDRSYNC.1/vdrsync.mpv looks like an MPEG Video stream.
   INFO: [mplex] File /tmp/.vdr-burn.suMIHQ/VDRSYNC.1/vdrsync0.mpa looks like an MPEG Audio stream.
   INFO: [mplex] Video stream 0: profile 8 selected - ignoring non-standard options!
   INFO: [mplex] Found 1 audio streams and 1 video streams
   INFO: [mplex] Selecting dvdauthor DVD output profile
   INFO: [mplex] Multiplexing video program stream!
   INFO: [mplex] Scanning for header info: Video stream e0 (/tmp/.vdr-burn.suMIHQ/VDRSYNC.1/vdrsync.mpv)
   INFO: [mplex] VIDEO STREAM: e0
   INFO: [mplex] Frame width     : 720
   INFO: [mplex] Frame height    : 576
   INFO: [mplex] Aspect ratio    : 4:3 display
   INFO: [mplex] Picture rate    : 25.000 frames/sec
   INFO: [mplex] Bit rate        : 15000000 bits/sec
   INFO: [mplex] Vbv buffer size : 229376 bytes
   INFO: [mplex] CSPF            : 0
   INFO: [mplex] Scanning for header info: Audio stream c0 (/tmp/.vdr-burn.suMIHQ/VDRSYNC.1/vdrsync0.mpa)
   INFO: [mplex] MPEG AUDIO STREAM: c0
   INFO: [mplex] Audio version  : 1.0
   INFO: [mplex] Layer          :        2
   INFO: [mplex] CRC checksums  :      yes
   INFO: [mplex] Bit rate       :    24576 bytes/sec (192 kbit/sec)
   INFO: [mplex] Frequency      :     48000 Hz
   INFO: [mplex] Mode           :        0 stereo
   INFO: [mplex] Mode extension :        0
   INFO: [mplex] Copyright bit  :        0 no copyright
   INFO: [mplex] Original/Copy  :        0 copy
   INFO: [mplex] Emphasis       :        0 none
   INFO: [mplex] SYSTEMS/PROGRAM stream:


  20 Mbytes of 979 read
  30 Mbytes of 979 read
  40 Mbytes of 979 read

Die Prozesse rund um burn hängen, sind aber noch da:

vdr       3038  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh demux
vdr       3039  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh mplex
vdr       3040  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh demux
vdr       3041  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh mplex
vdr       3042  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh demux
vdr       3043  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh mplex
vdr       3045  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh demux
vdr       3047  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh mplex
vdr       3049  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh demux
vdr       3052  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh mplex
vdr       3054  1882  0 19:21 ?        00:00:00 /bin/sh /usr/local/bin/vdrburn-dvd.sh author
vdr       3059  3054  0 19:21 ?        00:00:00 dvdauthor -x /data/video0/.vdr-burn.cF3Qm0/dvd.xml

Woran kann das liegen?

Viele Grüße
TeeRose

Hallo,

ich hatte mit burn-0.1.0-pre auch Probleme.

Ich weiß nicht ob das so schon hilft:

(1) Der C-Code ermittelte - falls er requantisieren soll - IMMER Faktor 1,12
Das habe ich im C-Code ausgebessert, aber ich kam noch nicht dazu
nachzusehen, woran das lag (mit gcc 4)

(2) Das nachfolgend laufende requant-Programm erwartete den Faktor
in englischer (1-PUNKT-1231231) Form, das Plugin hat ihn in deutscher
Form geliefert (1-KOMMA-1231231). Die Nachkommastellen wurden also
grundsätzlich weggeworfen. Ich habe die Requant-Source dann so geändert,
dass es sowohl Deutsch als auch Englisch kann.

(3) Das "Hängenbleiben" habe ich auch ein paar mal beobachtet. Da dass aber
nur passiert ist, während ich herumprobiert habe und es dann später nicht
mehr auftrat, habe ich mich nicht weiter darum gekümmert.

Aus Zeitmangel konnte ich leider noch nicht tiefer schürfen...

MfG - HjW

Zitat

Original von hjwd
(2) Das nachfolgend laufende requant-Programm erwartete den Faktor
in englischer (1-PUNKT-1231231) Form, das Plugin hat ihn in deutscher
Form geliefert (1-KOMMA-1231231). Die Nachkommastellen wurden also
grundsätzlich weggeworfen.

Folgenden Patch im burn-Verzeichnis anwenden, dann stimmt's mit dem . und ,

--- process.h   2006-03-08 14:03:23.000000000 +0100
+++ process.h.mod       2006-03-08 14:04:19.000000000 +0100
@@ -13,6 +13,7 @@
 #include "environment.h"
 #include <vdr/thread.h>
 #include <string.h>
+#include <locale.h>


 class cBurnEnvironment;


@@ -83,7 +84,13 @@


 inline void cBurnProcess::PutEnvironment(const char *Name, double Value)
 {
+       char *old_locale, *saved_locale;
+       old_locale = setlocale (LC_NUMERIC, NULL);
+       saved_locale = strdup (old_locale);
+       setlocale (LC_NUMERIC, "POSIX");
        mEnvironment.Put(Name, cString::sprintf("%f", Value));
+       setlocale (LC_NUMERIC, saved_locale);
+       free (saved_locale);
 }


 inline void cBurnProcess::PutEnvironment(const char *Name, int Value)

Bitte die C-Profis nochmal prüfen ob da alles korrekt ge-free-ed wird, ich hab das nur ziemlich dreist aus dem glibc-Handbuch kopiert: http://www.gnu.org/software/li…e.html#Setting-the-Locale

Zitat

Original von hjwd
(1) Der C-Code ermittelte - falls er requantisieren soll - IMMER Faktor 1,12
Das habe ich im C-Code ausgebessert, aber ich kam noch nicht dazu
nachzusehen, woran das lag (mit gcc 4)

Postest Du mal, was Du gemacht hast?
Ich hab dem Plugin gerade sehr genau auf die Finger geschaut, bei mir wird bei einer (leicht zu großen) Zusammenstellung ein Faktor von 1.000802069 + 0.12 ermittelt, also nicht genau 1.12

Allerdings ist das dann bei der Übergabe an's Environment dann 1.1200000, das stimmt...

EDIT:
Habs gefunden:

mEnvironment.Put(Name, cString::sprintf("%f", Value));

Das %f beschränkt auf drei Nachkommastellen.

Absicht?

Zitat

Postest Du mal, was Du gemacht hast?
Ich hab dem Plugin gerade sehr genau auf die Finger geschaut, bei mir wird bei einer (leicht zu großen) Zusammenstellung ein Faktor von 1.000802069 + 0.12 ermittelt, also nicht genau 1.12

Allerdings ist das dann bei der Übergabe an's Environment dann 1.1200000, da stimmt...

Hab die Source leider zu Hause. Kanns heute abend mal posten. Ich wollte für meine
Frau schnell was brennen, was nicht auf eine Scheibe ging. Ich konnte nicht auf
Anhieb erkennen, warum der existente Code das verkehrt macht und hab's dann
einfach schnell gehackt.

Ansonsten klappt das bei mir recht gut, danke!

MfG - HjW

Zitat

EDIT:
Habs gefunden:

Ich glaub daran lag's nicht. Hatte bei Faktor 1.5 auch noch 1.12 im Environment, aber
wie gesagt da muss ich noch genau hinschauen. Aber vielleicht war das noch vor
der Komma/Punkt-Geschichte.

MfG - HjW

so, jetzt hab ich nachgesehen.

Datei: process-dvd.c

Hier wird einem "double" das Ergebnis einer 64-bit integer-division + 0.12 zugewiesen:

Zitat

mFactor = vsize / ((off64_t)mJob->DiskSize() * MEGABYTE(1) - asize) + .12;

es kommt eine 64-bit-integer-Zahl plus 0.17 heraus.
(gcc 4-02)

Habe es ersetzt mit

Zitat

double v = vsize;
double d = (off64_t)mJob->DiskSize() * MEGABYTE(1);

mFactor = v / (d - asize) + .12;

MfG - HjW

Hallo zusammen,

ich habe die zwei Tipps (Patch von Thomas und Änderung von hjwd) von oben ausprobiert, aber leider ohne Erfolg für meinen Fehler.

Der Requantisierungsfaktor ist nun <>1.12. Aber dennoch bleibt das Requantisieren in dem Beispiel bei 40MB stehen.

Kann das evtl. daran liegen, dass per Default das Verzeichnis /tmp für irgendwelche Dateien herhalten muss. Meine root-Partion (mit /tmp) hat allerdings nur noch 131 MB frei.
Allerdings benutzt burn auch mein Verzeichnis /data/video0/.vdr-... und zusätzlich liegen Dateien in /tmp/.

PS: Ich habe mir auch den neuesten Snapshop aus dem burn-cvs gezogen, wie im VDR-Wiki zum burn-Plugin erwähnt:

cvs -z3 -d:pserver:anoncvs@vdr-developer.org:/var/cvsroot co burn

Aber auch hier bleibt mein Brennversuch stehen.
Und ich habe gesehen, dass Thomas Patch wohl schon eingearbeitet ist.

Viele Grüße
TeeRose

Zitat

Original von TeeRose
Allerdings benutzt burn auch mein Verzeichnis /data/video0/.vdr-... und zusätzlich liegen Dateien in /tmp/.

In /tmp werden nur fifos usw angelegt - nichts, was größentechnisch von Bedeutung wäre.

Zitat

Und ich habe gesehen, dass Thomas Patch wohl schon eingearbeitet ist.

Der double- und locale-Patch ist bereits eingearbeitet, ja.

Hallo,

habe noch ein Problem entdeckt:

Die Aufnahmen auf der DVD sind ein bisschen zu kurz, d.h. sie ENDEN ca einige
Sekunden früher als die original .vdr Dateien. Ist meiner Tochter aufgefallen, weil
ich ihr Spongebob-Doppelfolgen auseinanderschneiden musste, und jetzt fehlt
auf der DVD immer der Schluss... Wenn die Aufnahme einen längeren Abgesang
hat fällt das nicht so auf, da ich mir den Abspann nicht bis zum Ende ansehe.

Hat das schon mal jemand beobachtet? Falls nein, werde ich mir das wohl mal
genauer ansehen müssen.

MfG - HjW

ich schrieb:

Zitat

Die Aufnahmen auf der DVD sind ein bisschen zu kurz, d.h. sie ENDEN ca einige
Sekunden früher als die original .vdr Dateien.

ich habe das jetzt mit ein paar kurzen Aufnahmen ausprobiert. Es fehlen immer
die letzten 20-30 Sekunden.

Ich versuche mal herauszufinden, an welcher Stelle die verloren gehen. Muss
mich aber erst durch die ganzen Pfeifen wühlen.

Tritt das nur bei mir auf?

MfG - HjW

Ich habe das jetzt etwas genauer angesehen:

(1) Ich habe so das Gefühl, dass das mit den Pipes zusammenhängt. Irgendwelche
gehen da zu früh zu Ende. Da ich mit kurzen Aufnahmen gearbeitet habe, fand
KEIN requant statt.

(2) Die Länge des fehlenden Stücks (am Schluss) hängt von der Rechnerlast ab.

(3) Ein und die selbe Aufnahme immer wieder zum vob gemacht ist unterschiedlich
lang.

(4) Wenn ich die Pipes zerpflücke und mir diverse Zwischenergebnise ansehe,
fehlt nix (bis hin zum ge-mplexten (also vor der übergabe an dvdauthor)).

(5) In den Pipes werden weniger video-frames als audio-frames gefunden. Die
Anzahl der fehlenden Frames ist bei jedem Lauf (bei gleicher Aufnahme) unterschiedlich.

(6) Software: burn (pre1 etwas älter und auch cvs von 2006-03-15 abends), dvdauthor
(letzte stabile von Anfang 2005 und auch letzte alpha) - egal was ich verwende, Verhalten
ist immer das gleiche.

(7) Ein älteres Burn-Plugin (also vor der pre1) hatte ich nie im Einsatz, wahrscheinlich
taucht das Problem dort nicht auf sondern hat mit den umstrukturierten Pipes zu tun.

(8 ) Ich will nicht ausschließen, dass je nach Rechner/Kernel/Last auch längere Stücke
am Schluss fehlen bzw. vorzeitig abgebrochen wird (was auch das Problem von TeeRose
erklären könnte).

MfG - HjW

Ich bin gerade erst auf diesen Thread gestoßen...

Zitat

Original von Jarod
Ich habe in meinem VDR 256MB RAM und da ich per NFS boote, keine Swap Partition...

Keine Swap Partition zu haben ist i.A. keine so gute Idee. Wie Du Swap per NFS nutzen
kannst, ist in diesem Thread erklärt.

Hallo zusammen,

ich habe jetzt mal mein Verzeichnis /tmp gelöscht, welches auf einer Partition mit nur ca. 130 MB freiem Platz war.
Dann habe ich einen Link von /tmp auf /data/video0/tmp gelegt, also ein Verzeichnis in meiner Video-Partition, welche noch zig GB freien Platz hat.

...und siehe da, jetzt läuft meine ansonsten gescheiterte Zusammenstellung, und das mit Requantisierung.

Von Dauer will ich aber diese Frickel-Lösung mit dem umgebogenen /tmp nicht haben. Also muss ich mal die Einstellungen in den Skripten rund um burn prüfen.
1. Im vdrburn-dvd.sh ist mehrfach /tmp in den einzelnen Befehlen (beim render), was vermutlich nicht das Problem ist.
2. Da wäre im vdrsync.pl eine Variable für tmp: $tmp_dir. Vermutlich kann ich damit etwas bewirken. Habe ich aber noch nicht getestet.

Oder kann ich irgendwo in einer config zum Plugin burn etwas einstellen?
Es gab ja mal die Config-Datei .../conf/plugins/burn/vdrburnscript.conf.
In wie weit dort welche Parameter noch gültig sind, steht leider in keinem aktuellen Readme. Schön wäre es, wenn man dort ein alternatives tmp angeben kann. Dann braucht man nicht die vdrsync.pl zu ändern.

Viele Grüße
TeeRose

Fehlalarm, burn kommt jetzt nur bis ca. 1.5GB und bleibt an folgender Stelle hängen, ohne dass ich weiß, was los ist. Die Prozesse sind noch da, aber es tut sich nichts mehr:

STAT: fixing VOBU at 740MB (5521/5582, 98%)
STAT: fixing VOBU at 742MB (5537/5582, 99%)
STAT: fixing VOBU at 744MB (5553/5582, 99%)
STAT: fixing VOBU at 746MB (5569/5582, 99%)
STAT: fixed 5582 VOBUS
INFO: dvdauthor creating VTS
STAT: Picking VTS 03


STAT: Processing /data/video0/.vdr-burn.gkUTLp/VDRSYNC.2/menu-bg-0.mpg...


INFO: Video pts = 0.184 .. 0.224
INFO: Audio[8] pts = 0.184 .. 1.168
INFO: Audio[32] pts = 0.184 .. 0.184


STAT: Processing /data/video0/.vdr-burn.gkUTLp/VDRSYNC.2/menu-bg-1.mpg...


INFO: Video pts = 0.184 .. 0.224
INFO: Audio[8] pts = 0.184 .. 1.168
INFO: Audio[32] pts = 0.184 .. 0.184
STAT: VOBU 2 at 0MB, 2 PGCS


INFO: Generating VTSM with the following video attributes:
INFO: MPEG version: mpeg2
INFO: TV standard: pal
INFO: Aspect ratio: 4:3
INFO: Resolution: 720x576
INFO: Audio ch 0 format: mp2/2ch, 48khz 20bps


STAT: Processing /tmp/.vdr-burn.4QunXS/VDRSYNC.2/movie.mpg...