You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

mindless

Intermediate

Posts: 330

Location: Wien

Occupation: IT Architect

  • Send private message

121

Monday, January 17th 2005, 8:44pm

Frage zu vdr-requant-list

Hi,

Ok, ich hab jetzt vdr-requant-list.sh in mein vdrconvert Queuemanagement integriert. Was ich aber noch nicht herausgefunden hab, wie kann ich jetzt vdr-requant den Faktor über die Commandline mit auf den weg geben?

bye
Marcus.
AMD Athlon 64, Asus K8V-X mit VIA 8237 Chipsatz, 2 x Nexus-S
VDR 1.6.x on Debian Lenny, latest e-tobi packages

mhunstig

Intermediate

Posts: 321

Location: Ostwestfalen

  • Send private message

122

Monday, January 17th 2005, 8:48pm

Requant verkürzt/beschleunigt Aufnahmen

Hallo gonz,

wenn sich bei vdrsync.pl so oft etwas geändert hat, sollten wir da wirklich von weg. Ich habe deinen Code mit tcprobe ausprobiert, funktioniert bei mir. Kannst es meinetwegen gerne so einbauen.

Noch etwas, ist mir eben aufgefallen: Bei mir werden requantisierte Aufnahmen immer etwas kürzer als die Originale, aus einer Stunde werden etwa 59 Minuten. Ich kann aber nicht feststellen, dass irgendwo etwas fehlt. Verliert Requant evtl. mal hin und wieder einen Frame oder wie ist das zu erklären?

Gruß,

mhunstig
Mein VDR
ist mittlerweile nur noch ein umgebautes Dell Optiplex GX1-Gehäuse mit P2-333 und 192MB RAM

This post has been edited 1 times, last edit by "mhunstig" (Jan 17th 2005, 8:48pm)


123

Monday, January 17th 2005, 8:54pm

RE: Frage zu vdr-requant-list

Hi mindless,

Quoted

Ok, ich hab jetzt vdr-requant-list.sh in mein vdrconvert Queuemanagement integriert. Was ich aber noch nicht herausgefunden hab, wie kann ich jetzt vdr-requant den Faktor über die Commandline mit auf den weg geben?

es wird in vdr-requant-list.sh fuer jede Aufnahme "vdr-requant.sh after pfad/zu/video"
ausgefuehrt. Bei dem Parameter after wird von vdr-requant.sh der DEFAULT_FACTOR
verwendet (normal 1.3), den Du im Script selbst aendern kannst.

cu
gonz

mindless

Intermediate

Posts: 330

Location: Wien

Occupation: IT Architect

  • Send private message

124

Monday, January 17th 2005, 9:00pm

RE: Frage zu vdr-requant-list

Quoted

Original von gonz
es wird in vdr-requant-list.sh fuer jede Aufnahme "vdr-requant.sh after pfad/zu/video"
ausgefuehrt. Bei dem Parameter after wird von vdr-requant.sh der DEFAULT_FACTOR
verwendet (normal 1.3), den Du im Script selbst aendern kannst.


Ja, das hab ich befürchtet :-( Das ist ein Punkt, der mir an vdrconvert überhaupt nicht gefällt, daß ich keine Möglichkeit hab aus dem OSD ein Skript mit unterschiedlichen Parametern aufzurufen - aber naja, damit muß ich wohl leben :-)

bye
Marcus.
AMD Athlon 64, Asus K8V-X mit VIA 8237 Chipsatz, 2 x Nexus-S
VDR 1.6.x on Debian Lenny, latest e-tobi packages

125

Monday, January 17th 2005, 9:11pm

vdr-requant-0.0.42a

Hi,

hier also die neue Version, die nun tcprobe zum Feststellen der Bitrate verwendet :)

@mhunstig: Bzgl. der kuerzer gewordenen Aufnahmen kann ich nur vermuten dass
genindex da etwas "nicht ganz korrekt" macht. Den Effekt hab ich auch schon bemerkt,
fehlende Frames oder zu schnelles Abspielen konnte ich jedoch nicht feststellen...
(Thomas und LordJaxom haben mir glaubhaft versichert dass die index.vdr zurate
gezogen wird bei der Laufzeitberechnung durch VDR).

cu
gonz
gonz has attached the following file:

mhunstig

Intermediate

Posts: 321

Location: Ostwestfalen

  • Send private message

126

Thursday, February 17th 2005, 5:48pm

RE: vdr-requant-0.0.42a

Hallo,

da bin ich wieder und gleich wieder mit Problemen:
Wie sich hier herausgestellt hat, waren die bisherigen Versionen der Requantisierungsfaktorberechnung fehlerhaft, da sie nicht die tatsächliche Bitrate als Ausgangspunkt verwendeten, sondern die von den Sendern angegebene, die teilweise um mehr als den Faktor 2 abweicht.

Ich habe nun vor, die Ausgangsbitrate aus der Größe der .vdr-Dateien und der Länge der Aufnahmen zu bestimmen.
Leider scheitert mal wieder vieles daran, dass ich nicht gut genug in Shellskripten bin.

Die Gesamtgröße der Datei bekomme ich mit:
du -c ???.vdr | grep -v vdr | awk -F' ' '{print $1}'

Ich habe keine Ahnung, wie ich an die Länge der Aufnahmen komme. Wie es in C geht, steht wohl hier, aber mit C kenne ich mich garnicht aus, außerdem soll es ja möglichst ein Shellskript bleiben. Gibt es irgendein Kommandozeilenprogramm, dass die Länge einer Aufnahme aus der index.vdr holt? Da müsste sie doch eigentlich drinstehen.

Die Audiobitraten müsste ich ja eigentlich von der errechneten Gesamtbitrate abziehen. Mit
vdrsync.pl -audio-only -i 001.vdr | grep Bitrate | awk -F' ' '{print $2}'
bekomme ich eine Liste. Ich hoffe, dass das mit anderen vdrsync.pl-Versionen auch klappt. Da müsste dann die erste Hälfte der Zahlen aufaddiert werden. Tja, meine Programmierkenntnisse... Wenn ich es nicht hinbekomme, ziehe ich einfach einen festen Wert ab, sollte reichen, da vdr-requant den mitgegebenen Faktor sowieso nicht ganz exakt umsetzt.

Ihr seht, ich brauche Hilfe, sonst bekomme ich das nicht hin. Danke schonmal im Voraus.

Matthias
Mein VDR
ist mittlerweile nur noch ein umgebautes Dell Optiplex GX1-Gehäuse mit P2-333 und 192MB RAM


ralf1970

Intermediate

Posts: 296

Location: Erfurt

Occupation: Softwareentwickler

  • Send private message

127

Thursday, February 17th 2005, 6:57pm

RE: vdr-requant-0.0.42a

Tipp:

du -s (anstatt du -c) bringt dir gleich die eine Zeile, die du dir mit "grep vdr" am Ende aufwendig baust.

Wenn du noch einen gestarteten Prozess sparen willst, und nebenbei die gesuchte Dateigröße auch gleich auf einer Variablen haben möchstest, empfehle ich folgende Zeile:

read SIZE NAME < <(du -s ???.vdr)

Danach steht auf $SIZE die Größe und auf $NAME noch mal der Name der Datei ($NAME kannst du ja ignorieren - angegeben werden muß die zweite Variable ansonsten landet die ganze Zeile die "du" liefert auf der ersten Variablen und das ist ja nicht so richtig das was wir erreichen wollten).

Entsprechend bekommt man mit

read DUMMY BIT_RATE < <(vdrsync.pl -audio-only -i ???.vdr | grep Bitrate)

die gesuchte Bitrate auf $BIT_RATE.

Zum eigentlichen Thema: wenn ich es richtig verstanden habe steht in index.vdr für jeden Frame ein Record der die Nummer des eigentlichen .vdr Files, die Art des Frames und den Offset an dem der Frame im File zu finden ist enthält. D.h. die Länge des Files ist direkt proportional zu Länge des Films. Die Recordgröße ist 8 Byte (ein int, 2 char, ein short als Filler).

Bei 25 Herz pro deinterlastem Frame biete ich folgende Berechnung:

read IDX_SIZE DUMMY < <(du -b index.vdr)
SECONDS_OF_MOVIE=$(( $IDX_SIZE / ( 25 * 8 ) ))

Das bringt zumindest bei mir sinnige Werte. Vielleicht kannst du ja damit was anfangen.

Ralf
vdr-2.0.2 balta3; SuSE 12.3 Tumbleweed; kernel 3.10.9; some plugins
VDR: Core i5-4570T 2.9GHz; 4GB; 12TB via NFS; TT-connect S2-3600
Datengrab: Core i3 2.6GHz; 4GB; 5*1.5TB + 3*3TB in 2 RAID5's -> 12TB; Gigabit Ethernet
Und so siehts nicht mehr aus.

mhunstig

Intermediate

Posts: 321

Location: Ostwestfalen

  • Send private message

128

Thursday, February 17th 2005, 10:02pm

RE: vdr-requant-0.0.42a

Hallo Ralf,

Danke für die Hilfe.

Quoted

du -s (anstatt du -c) bringt dir gleich die eine Zeile, die du dir mit "grep vdr" am Ende aufwendig baust.
Das hatte ich von dem Parameter -s auch erwartet. Leider tut er das nicht, sondern gibt mir genau die Zeilen von du -c zurück, die ich _nicht_ haben will.

Quoted

Wenn du noch einen gestarteten Prozess sparen willst, und nebenbei die gesuchte Dateigröße auch gleich auf einer Variablen haben möchstest, empfehle ich folgende Zeile:

read SIZE NAME < <(du -s ???.vdr)
Guter Tipp, hab ich gleich umgesetzt.

Quoted

Entsprechend bekommt man mit

read DUMMY BIT_RATE < <(vdrsync.pl -audio-only -i ???.vdr | grep Bitrate)

die gesuchte Bitrate auf $BIT_RATE.

Das Funktioniert, wenn ich nur eine Audiospur habe. Aber was, wenn ich mehrere habe, z.B. eine Stereo und eine AC3? Dann muss ich Zahlen, die in zwei oder mehreren Zeilen stehen, addieren. Und dafür habe ich leider noch keinen Bash-Befehl gefunden.

Quoted

Zum eigentlichen Thema: wenn ich es richtig verstanden habe steht in index.vdr für jeden Frame ein Record der die Nummer des eigentlichen .vdr Files, die Art des Frames und den Offset an dem der Frame im File zu finden ist enthält. D.h. die Länge des Files ist direkt proportional zu Länge des Films. Die Recordgröße ist 8 Byte (ein int, 2 char, ein short als Filler).
Scheint zu stimmen. Ich habe es an drei Aufnahmen ausprobiert und es hat 36,32,39 Sekunden mehr ausgegeben, als der VDR anzeigt. Wahrscheinlich steht noch irgendwas anderes in der index.vdr. Ich ziehe jetzt einfach immer 35 Sekunden ab, das reicht an Genauigkeit locker.

Bleibt nur noch das Problem mit der Audiobitrate, dann kann ich mal ein paar Testläufe mit vdr-requant starten.

Gruß,

Matthias
Mein VDR
ist mittlerweile nur noch ein umgebautes Dell Optiplex GX1-Gehäuse mit P2-333 und 192MB RAM


ralf1970

Intermediate

Posts: 296

Location: Erfurt

Occupation: Softwareentwickler

  • Send private message

129

Friday, February 18th 2005, 8:47am

RE: vdr-requant-0.0.42a

Mehrere Audiospuren gehen natürlich auch:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
IDX=1
CUMULATED_BIT_RATE=0
while read DUMMY BIT_RATE; do
    BIT_RATES[$IDX]="$BIT_RATE"
    CUMULATED_BIT_RATE=$(( ${BIT_RATES[$IDX]} + $CUMULATED_BIT_RATE )) 
    IDX=$(( $IDX + 1 ))
done < <(vdrsync.pl -audio-only -i ???.vdr | grep Bitrate)

for i in ${BIT_RATES[@]}; do
    echo $i;
done
echo "=$CUMULATED_BIT_RATE"


Ich hoffe ich hab jetzt nicht irgendwo 'ne Klammer vergessen - bin bei einem Kunden und kann das Script gerade nicht testen ...

Ralf
vdr-2.0.2 balta3; SuSE 12.3 Tumbleweed; kernel 3.10.9; some plugins
VDR: Core i5-4570T 2.9GHz; 4GB; 12TB via NFS; TT-connect S2-3600
Datengrab: Core i3 2.6GHz; 4GB; 5*1.5TB + 3*3TB in 2 RAID5's -> 12TB; Gigabit Ethernet
Und so siehts nicht mehr aus.

This post has been edited 1 times, last edit by "ralf1970" (Feb 18th 2005, 8:47am)


130

Friday, February 18th 2005, 10:03am

RE: vdr-requant-0.0.42a

Quoted

Original von mhunstig


Ich habe keine Ahnung, wie ich an die Länge der Aufnahmen komme. Wie es in C geht, steht wohl hier, aber mit C kenne ich mich garnicht aus, außerdem soll es ja möglichst ein Shellskript bleiben. Gibt es irgendein Kommandozeilenprogramm, dass die Länge einer Aufnahme aus der index.vdr holt? Da müsste sie doch eigentlich drinstehen.



Das gleiche Problem hatten xpix und hulk mit xxv auch.
xxv-Release
Zuerstwurde "vdrsync -i" benutzt, was aber wohl sehr Ressourcenhungrig ist.
Dann wurde "du" benutzt und durch die bitrate geteilt -> Nachteil: sehr ungenauer Wert, auch wenn eine CBR benutzt wird
Hulk hat es dann mittels index.vdr geschafft (siehe letzter Post im obigen Link):

Quoted

Original von Hulk
Ich bin gerade auf den Gedanken gekommen, das man doch nur index.vdr verwendet werden muss...

Den die Datei speichert die Byte Positionen aller Frames ab.

lt. VDR Quellcode
Anzahl der Frames = Dateigröße von index.vdr / sizeof(struct tIndex) - 1
also => Anzahl der Frames = Dateigröße von index.vdr / 8
Filmlänge = Frames / FRAMESPERSEC (25)

Damit passen die Zeiten :
(pearl)

Source code

1
2
3
4
5
6
7
8
    # diskusage aufrufen für Duration
    if($obj->{diskusage}) {
        my $vdir = dirname($files[0]);
        my $cmd = sprintf("%s -Lbs %s/index.vdr", $obj->{diskusage}, $vdir);
        my $dur  = `$cmd`;
        my ($bytes) = $dur =~ /^(\d+)/;
    	$status->{duration} = ($bytes / 8) / 25;
    }



Wenn das mit pearl ging sollte das doch auch mit der shell gehen, oder?

cu

cP
easyVDR 0.6: VDR: Asus M2N-VM DVI, 2GB RAM, AMD A64 X2 4000+ EE, Samsung SpinPoint T166 400GB SATA II, LG Electronics GSA-H62N schwarz DVD Brenner, TT1.5 FF, TT Budget verpackt in einem Silverstone LC17 Gehäuse.
Client: MediaMVP

yavdr 0.3a:Asus M4A78LT-M LE, 4GB RAM, AMD Athlon II X2 240e, Asus Geforce ENGT520, 320GB Samsung Spinpoint M7 HM320II, 300W be quiet! Pure Power L7, TT-Budget S2-1600, EKL Alpenföhn Panorama, verpackt in einem Techsolo TC-380 HTPC Gehäuse

yavdr 0.5: Intel DH67GD, Intel Pentium G620 2x 2.60GHz So.1155, 60GB Corsair Force 3 SSD, 8GB Ram, Linux4Media S2 ver 5.4, Asus ENGT 520 Silent, CoHaus CIR

TV: Panasonic 42" Plasma TH-42PV45

ark

Intermediate

Posts: 344

Location: Ruhrgebiet

  • Send private message

131

Friday, February 18th 2005, 10:59am

RE: vdr-requant-0.0.42a

Hallo Matthias,

wenn ich die bisherige Diskussion richtig verstehe, dannn möchtest Du alles mit einem Shell-Skript erledigen und micht mit perl. Persönlich würde ich zu perl raten, auf Grund der Mächtigkeit der Möglichkeiten, aber es geht auch irgendwie mit der bash.

1. Größe des Films
du -c ???.vdr liefert zeilenweise die Größe der Dateien und in einer abschließenden Zeile die Summe der Größen. Was fehlt ist ein -L (also: du -cL ???.vdr), damit werden Links verfolgt, was bei einer Verteilung auf mehrere video-Verzeichisse passieren kann. Wenn Du die Größe in Bytes brauchst, kommt noch ein -b dazu. Um nur die letzte Zahl zu lesen, geht beispielsweise:
while read S NAME ; do SIZE=$S ; done < <(du -cbL ???.vdr)
Dann steht in $SIZE die Summe der Größen.

2. Länge des Films
Ich kenne die Definition von index.vdr nicht, wenn tatsächlich jeder Frame und nicht nur I-Frames drin steht, dann ergibt sich die Länges des Films durch (Länge von index.vdr in Bytes) / 8 Bytes / 25 und damit gelten die Zeilen von Ralf:
read IDX_SIZE DUMMY < <(du -b index.vdr)
SECONDS_OF_MOVIE=$(( $IDX_SIZE / ( 25 * 8 ) ))

Gruß,
Armin
VDR
ASUS A7N8X-X, AMD 2600+, 2 GB, 320 GB HD, Hauppauge DVB-S 1.3, Hauppauge Nova-S-Plus, Funktastatur
Debian 4.0/Etch-Kernel 2.6.18-5-486
c't-VDR 6.1 mit e-tobi 1.6.0 (neu gepatched ohne sortrecordings), acpi, vdradmin-am, burn, osdteletext, ffnetdev, audiorecorder, infosatepg, ...
Client
dbox2 (Sagem 2xI_C) mit Neutrino-Derivat

mhunstig

Intermediate

Posts: 321

Location: Ostwestfalen

  • Send private message

132

Friday, February 18th 2005, 7:06pm

RE: vdr-requant-0.0.42a

Hallo,

Die neue Version ist einsatzfähig. Danke für die vielen Tipps, besonders an Ralf, ohne den das ganze nicht laufen würde.

In der vdr-requant.sh gibt es eine Zeile (114 in gonz' letzter Version):

Source code

1
				BRINPUT=$( vdrsync.pl -script-output -i $2/001.vdr | grep Bitrate | head -n 1 | awk -F: '{print $2 }' | sed -n '$ p' )
Die muss ersetzt werden durch:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
			read FILESIZE DUMMY < <(du -c $2/???.vdr | grep -v vdr)
			#read INDEXSIZE DUMMY < <(du -b $2/index.vdr)		# Schöner, aber führt auf meinem System zu einem Fehler
			INDEXSIZE=$(du -b $2/index.vdr | awk -F' '  '{print $1}') # Bewirkt das gleiche wie vorhergegangene Zeile.
			SECONDS=$(($INDEXSIZE / ( 25 * 8 ) -35))
			# Code von Ralf1970 - Danke
			 IDX=1
			 BRAUDIOx2=0
			 while read DUMMY BIT_RATE; do
		    	 	BIT_RATES[$IDX]="$BIT_RATE"
    				BRAUDIOx2=$(( ${BIT_RATES[$IDX]} + $BRAUDIOx2 )) 
				IDX=$(( $IDX + 1 ))
			 done < <(vdrsync.pl -audio-only -i $2/???.vdr | grep Bitrate)
			BRAUDIO=$(($BRAUDIOx2/2))
			BRINPUT=$(echo "scale=0; $FILESIZE/$SECONDS*8-$BRAUDIO/2000" | bc )
Ich hatte keine Zeit, es ausgiebig zu testen, sondern hab nur zwei South Park-Folgen mit unterschiedlicher Bitrate auf 3000kbps bringen lassen. Die Dateien sind hinterher ungefähr gleich groß, scheint also geklappt zu haben. Die Qualität ist auch OK, aber bei dem Fall, in dem der Faktro größer war (etwa 1.6) sind bei Szenenwechseln teilweise äuffällige bunte Artefakte zu sehen.

Viel Spaß beim Testen. Schreibt doch mal, was für Bitraten ihr so nutzt.

Matthias
Mein VDR
ist mittlerweile nur noch ein umgebautes Dell Optiplex GX1-Gehäuse mit P2-333 und 192MB RAM


dmh

Intermediate

Posts: 517

Location: NRW

Occupation: Student kurz vor dem Diplom

  • Send private message

133

Thursday, October 13th 2005, 2:23pm

RE: vdr-requant-0.0.42a

Wollte mal ausprobieren, was das vdr-requant so leistet. Also installiert und versucht. (Mit meinen Spongebob-Folgen) Allerdings sind bei den Faktoren 1.5, 1.4 und 1.3 (in der Reihenfolge) bei Bildwechseln ziemlich störende, über den ganzen Bildschirm verteilte, bunte Klötzchen zu sehen. Das war für mich nicht tragbar. Mit welchen Faktoren arbeitet Ihr denn?

Dann hab ich gedacht, dass das an dem Zeichentrick liegt. Aber auch bei Realfilmen war die Quali nicht überzeugend und bei Schnitten (nicht vdr-Schnittmarken, sondern Bildwechsel im Film selbst) kamen häufig die bunten Klötzchen! :§$%

@tüddelkopp:
Mit welchem Faktor hast Du die Simpsons-Folgen recodiert? Der Unterschied zu dem Original ist zwar sichtbar, dennoch traten keine bunten Bilder bei Schnitten auf.

Probleme:
  • Ein Problem gibt es mit der Umstellung von summary.vdr -> info.vdr. Da könnte man sich vielleicht nochmal drum kümmern.
  • Wenn die Filme nicht mit "%" anfangen, dann gibt es da mit dem REMOVE ein Problem. Hab gestern Spongebob-Folge Nr. 1 dadurch verloren... :§$%


Beste Grüße 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!"

tüddelkopp

Professional

Posts: 1,057

Location: Paderborn, NRW

  • Send private message

134

Thursday, October 13th 2005, 2:28pm

Die Simpsons requantisiere ich immer mit Faktor 1.4 - 1.5
Gruß Tüddelkopp

dmh

Intermediate

Posts: 517

Location: NRW

Occupation: Student kurz vor dem Diplom

  • Send private message

135

Thursday, October 13th 2005, 8:52pm

Dann werd ich das mit meinen Simpsons-Folgen auch mal versuchen... Ist es ein Unterschied, ob man requant oder tcrequant benutzt? Hatte meine Versuche mit tcrequant ausgeführt...
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!"

tüddelkopp

Professional

Posts: 1,057

Location: Paderborn, NRW

  • Send private message

136

Thursday, October 13th 2005, 8:57pm

Ich habe auch immer tcrequant benutzt und kann daher zu unterschieden nichts sagen.
Gruß Tüddelkopp

georg3003

Trainee

Posts: 74

Location: Köln/Bonn NRW

Occupation: Medizinischer Bereich

  • Send private message

137

Friday, January 27th 2006, 9:57am

Aufnahmen > 4GB

Hallo,
ich finde dieses teil wirklich klasse, jedoch wie sieht das mit der unterstützung von großen Dateien aus? 192 minuten 3sat und größe etwa 8-9GB

was muss ich da einstellen damit ich es konvertieren kann?
das sind die dateigrößen nach abbruch mit fehler im ersten lauf

drwxr-xr-x 2 root root 4096 Jan 27 01:37 .
drwxrwxr-x 4 root users 4096 Jan 27 01:36 ..
-rw-r--r-- 1 root root 228298752 Jan 27 02:08 vdrsync0.mpa
-rw-r--r-- 1 root root 114126848 Jan 27 02:08 vdrsync1.mpa
-rw-r--r-- 1 root root 4942012416 Jan 27 02:08 vdrsync.mpv


ich vermute es liegt irgendwo an einer 4gb max. dateigröße es ist ein ext3 fehler? danke ich nicht eher vdrsync macht da nicht mit :-(

hier noch die abbruchfehlermeldung

part 1/4 - vdrsync.pl

DEBUG: starting: vdrsync.pl
ERROR: vdrsync.pl exited with error.

EDIT: Ich vermute das Problem hat sich wohl erledigt, da die Aufnahme wohl dermassen defekt ist und sich mit vdrsync nicht bearbeiten lässt.

This post has been edited 3 times, last edit by "georg3003" (Jan 27th 2006, 6:23pm)


138

Sunday, January 29th 2006, 8:23pm

RE: Aufnahmen > 4GB

hi georg3003,

in der tat ist hier vdrsync.pl das problem, bzw. die defekte aufnahme. vdr-requant.sh sollte grosse aufnahmen automatisch korrekt handhaben.

cu
gonz

ratata

Intermediate

Posts: 190

Location: Oldenburg

  • Send private message

139

Friday, February 17th 2006, 10:24am

RE: Aufnahmen > 4GB

Hi,
ich glaube nicht das vdrsync das Problem ist, bei mir wird durch die Benutzung von vdr-requant.sh aus einem

[tcprobe] MPEG packetized elementary stream (PES)

mit dem vdrsync.pl umgehen kann, ein

[tcprobe] MPEG program stream (PS)

den vdrsync.pl dann nicht mehr versteht.

Gibt es dafür einen Lösungsansatz?

ratata
--
Antec Skeleton | Asus M3N-H/HDMI | TT DVB-C 1501 + CI | Technisat Cablestar HD2 | Hauppauge WinPVR 350 | yaVDR 0.4

Mase

Master

Posts: 2,155

Location: Saarlouis

  • Send private message

140

Friday, March 31st 2006, 12:52pm

Wäre es nicht besser, auf eine neuere vdrsync-Version zu wechseln?
Die 0.1.1.2 steigt oft mit Fehlern aus.
Die 0.1.1.3 funktioniert bei mir besser.
Allerdings haben die Outputs damit andere Namen.
Oder hab ich was verpasst?
VDR1:
Gehäuse: Thermaltake Element Q
Mainboard: Zotac IONITX-P-E
Arbeitsspeicher: KVR1066D3N7K2/4G
HDD: 1TB SATA
500GB SATA für HDD-Archive im Front-Wechselrahmen
DVD: LG GH22NSRBBB
DVB: Digital Devices Cine S2 PCIe
OS: Debian Jessie
VDR: Dev-Version mit MainMenuHooks P
atch, div. Plugins
Sonstiges: XBMC, XFCE

VDR2:
Samsung SMT-7020S mit Wakeup-Board
HDD: 160GB 2,5" IDE
OS: Debian Wheezy
VDR:
Dev-Version mit MainMenuHooks Patch, div. Plugins

VDR3:
Raspberry Pi
OS: Raspbian
VDR:
Dev-Version mit VNSI
Sonstiges: XBMC
(noch im Aufbau)

May the force be with us!