Beiträge von ravenclaw_78

ich hab jetzt die 0.0.6h mit dem requant-fix für linvdr mit mt+cody 1.3.31 compiled ...und einen test gemacht ...durchgelaufen ist es ...nur mein brenner hat mir einen io-error geschenkt ...er hat allerdings diesmal beide filme drauf

falls es euch interessiert könnt ihrs damit ausprobieren
http://tunix.dyndns.org/vdr/li….0.6h-requant-fix.tar.bz2

lg
Robert

steini
wollt mir grad die i version mit dem h-requant patch übersetzen ...
und finde auf der burn download page die i version als -buggy umbenannt ...

jetzt müsste man hald wissen ob mit buggy das eine problem oder noch andere auch gemeint sind ...kacke *G*

welche wäre sonst noch stabil ...
0.0.6h mit dem h-requant-fix ?

Zitat

Original von SchienW
Lass einfach mal dein % beim Verzeichnisnamen weg.

ok, dachte dass die % nicht das problem machen ...hab nur punkte,beistriche und hochkomma entfernt ...

jetzt ...wo nur noch buchstaben und _ im Verzeichnisnamen waren, lief es durch ...
DANKE

das von dir im anderen thread erwähnte problem hat mich diesmal nicht ereilt ...hatte nur eine audio spur ...glück gehabt *grins*

EDIT: man sollte vorher auch die dvd kontrollieren ...genau das hat mich ereilt

steini,
Ich hab jetzt die 0.0.6ipre2 vom letzten cody patch drauf und problem besteht noch ...

SchienW,
Der Thread den du verlinkt hast spricht ein anderes problem an ...
hab weder deren fehlermeldungen noch 2 audio tracks im ordner ...

und eigentlich hab ich bei den beiden aufnahmen auch kein ac3 ...also zumindest gibts kein file dafür und im log steht auch nix davon...

pat, wiki lesen ...http://www.vdr-wiki.de/wiki/index.php/Burn-plugin

Zitat

Bitte beachten, daß das "Schrumpfen" der Daten maximal mit Faktor 2 erfolgen kann. Sind die Ergebnisse immer noch zu gross für das Zielmedium, dann findet in den internen Skripten ein Fehler statt, der Rohling ist "verbrannt" und das Ergebnis unbrauchbar. Also immer darauf achten, dass nicht zu viele Filme auf eine DVD kommen sollen.

der fehler im log sagt mir sonst eigentlich nix ...(tut mein fehler auch ned :))

Das Wiki sei dein freund ...

http://vdr.unetz.com/download/burn/

also der beistrich wars nicht ...

diesmal hab ich folgendes

Zitat

++ started: sh -c 'vdrburn.sh MPLEX '/video0/.vdr-burn.ORU5aP/VDRSYNC.0' 'G~^H' '/video0/.vdr-burn.ORU5aP/VDRSYNC.1/vdrsyn
root: <MPLEX /video0/.vdr-burn.ORU5aP/VDRSYNC.0 G~^H /video0/.vdr-burn.ORU5aP/VDRSYNC.1/vdrsync0.mpa >
root: Starting <nice -n 19 mplex -f 8 -vbr -v 1 -o /video0/.vdr-burn.ORU5aP/VDRSYNC.0/movie.mpg G~^H /video0/.vdr-burn.ORU5
INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
**ERROR: [mplex] Unable to open file G~^H for reading.

und wieder wurde statt dem filenamen speichermüll übergebn ...

kann man das burn plugin irgendwie mit debug starten, oder muss ichs mit DEBUG=1 übersetzen ?

hab hier nen beistrich drinnen, werd das gleich mal ohne "sonderzeichen" probieren ...
"%%Verflucht,_verdammt_und_Halleluja"

Zitat

Original von azuver
root: <MPLEX /video0/.vdr-burn.VvvGaU/VDRSYNC.0 /video0/.vdr-burn.VvvGaU/VDRSYNC.0/vdrsync.mpv D >
root: Starting <nice -n 19 mplex -f 8 -vbr -v 1 -o /video0/.vdr-burn.VvvGaU/VDRSYNC.0/movie.mpg /video0/.vdr-burn.VvvGaU/VDRSYNC.0/vdrsync.mpv D>
INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
**ERROR: [mplex] Unable to open file D for reading.

habe hier das selbe problem ...

Hier mein log file ...

Zitat

root: <MPLEX /video0/.vdr-burn.v2rZGQ/VDRSYNC.0 /video0/.vdr-burn.v2rZGQ/VDRSYNC.1/vdrsync.mpv ž^Yô·ž^Yô·Ì >
root: Starting <nice -n 19 mplex -f 8 -vbr -v 1 -o /video0/.vdr-burn.v2rZGQ/VDRSYNC.0/movie.mpg /video0/.vdr-burn.v2rZGQ/VDRSYNC.1/vdrsync.mpv ž^Y
INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
**ERROR: [mplex] Unable to open file ž^Yô·ž^Yô·Ì for reading.

ich vermute dass das am burn plugin liegt ...das das vdrburn.sh anscheinend mit diesem parameter aufegrufen wird "ž^Yô·ž^Yô·Ì" (bei dir "D")
sieht für mich wie speichermüll aus ...
ach ja meine beiden recordings haben kein ac3 ...
auftreten tut das gefühlsmäßig zu 50% der zeit ...

kann das sein das im burn plugin ein pointer/index vermurkst ist ?

hab das so gelöst (statt der fb hab ich das extb per lirc-serial dran)

http://www.vdr-portal.de/board…?postid=307456#post307456

lg
Robert

Meines wissens gabs vom TBE Extention board nur eine Auflage und die ist lange schon vergriffen.

Ich hab damals eines erwischt, und für meinen 2. vdr hab ich mir grad ein AVBoard bestellt...da gibt es gerade eine neue auflage ...

(auch das AVBoard wird an den J2 angeschlossen)

http://www.vdrportal.de/board/thread.php?threadid=19693&sid=&hilight=bestellung+board

Zitat

AVBoard Neuauflage im Oktober/November 2005.
Bestellungen sind weiterhin möglich.

Bestellung: http://www.rf-link.de/AVBoard_Bestellung.txt
Manual: http://www.rf-link.de/avboard_13.zip
Fragen: AVBoard

lg
Robert

Zitat

Original von wolfgang61
Nein. Wir haben ein paar neue Felder eingefuehrt, aber GiantDisc sollte das nicht stoeren. Das gilt bis 0.1.8

na wenn 0.1.9 da is kann ich mir das gdwebint mal anschaun und vieleicht nen kleinen patch dazu basteln ...vorrausgesetzt er zeigt mir bis dahin die tracklängen an *G*

Zitat

Original von wolfgang61
bei mir stehen sinnvolle Werte fuer die Laenge in der Datenbank. Du kannst sie ja mal direkt abfragen: "select length from tracks";

bei mir eh auch ...war nur der gedanke dass sich das was geändert haben könnte db-structure mäßig ...

Zitat

Original von wolfgang61
Da vertraust Du zu sehr in meine Kristallkugel.:D

grins, hab ich nur der vollständigkeit halber angeführt *G*
versuchen kann mans ja

Zitat

Original von wolfgang61

Weder GiantDisc noch muggle verwenden eine Table namens titel. Es gibt nur ein Feld namens title (nicht titel).

Wirklich sehr seltsam.

äääääh ...tabelle tracks mein ich

da war der gedanken wohl schon einen schritt weiter oder daneben :gaga

Zitat

Original von wolfgang61

auch da wuerde mich der Output von mugglei mit Option -v5 interessieren - zumindest die ganze Fehlermeldung (die eigentlich den ganzen SQL - Befehl enthalten sollte), und auch der Output von Valgrind. Das duerfte wohl eine ganze Weile laufen...

Das ist sicher nochmal der boese g++-2.95

nun ...das derzeitige mugglei binary mag valgrind nicht ...
http://tunix.dyndns.org/vdr/valgrind-muggle-0.1.8_try3.txt

ein neuerliches importieren ohne valgrind in GiantDisc3 hat nun funktioniert und hat 31090 tracks, ein fehlerfreies log und eine weiterhin funktionsfähige tracks tabelle ...

hat wohl mit meiner mysql version am server zu tun gehabt ...

eine andere frage hätte ich noch bezüglich der db struktur ...is die noch original GiantDisc ?
hab mir nämlich das GD Web interface aufgesetzt und der zeigt zb bei den tracks immer 0:00 als länge an und bei der albenauflistung bringt er gar fehler ...

ich hatte gerade etwas seltsames ...
mugglei hat mir 28954 titel importiert ...und dann meinte mysql das die table titel "in use" sei ...

das kann doch eigentlich nur mit dem mysql am server zu tun haben oder ??
passiert allerdings immer wenn ich alle mp3 importiere ...

und erst nach einem
repair table titel ging wieder was

so läuft muggle nun ohne probleme ...wenn ich wieder etwas zeit hab werd ich versuchen das genauer zu analysieren.

libmad-0.15.1b
mysql-4.1.14
taglib-1.4

habs jetzt ohne embeddet compiled ...
und mugglei importet brav ...

mit valgrind, stürzt allerdings valgrind ab (2.2er version von valgrind)

ich brauche zum glück nur den remote mysql server ...nur da es bei MT funktionierte, hab ich dacht rein damit ...kann ned schaden ...so kann man sich irren *G*

werde nach dem import lauf das mit dem Default Constructor ausprobieren ...

Danke für die tolle unterstützung

sieht aus als ob er mit dem patch weiterkommt ...

http://tunix.dyndns.org/vdr/valgrind-muggle-0.1.8_try2.txt

ich würd liebend gerne einen neuen gcc verwenden ...*warten auf linvdr 0.8*
linvdr 0.7, woody is leider noch mit 2.95 übersetzt

wärst du so lieb und würdest die änderung an anderen stellen auch noch machen ...

hast du auch die 2. msg von cody gelesen ... ?

http://www.vdr-portal.de/board/thread.php?threadid=32894&sid=

lg
Robert

valgrind sourcen + patches damits unter woody compilen findest hier ...
http://www.backports.org/debian/dists/woody/valgrind/source/

mein letzter lauf mit all den vorhergenannten patches ...
http://tunix.dyndns.org/vdr/valgrind-muggle-0.1.8.txt

im ddd bin ich dem segfault bis nach "basic_string" nachgegangen, in folgende zeile ...

if (length () == 0) return null_str; terminate (); return data ();

mit folgendem output von gdb ...

(gdb) nexti
0 '\0'
1: this->length () = 
Program received signal SIGSEGV, Segmentation fault.
Disabling display 1 to avoid infinite recursion.
0x08053ba5 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::length (this=0xbffff4ce) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/std/bastring.h:154
/usr/include/g++-3/std/bastring.h:154:4644:beg:0x8053ba5

ich hab jetzt ein debian woody aufgesetzt wie von cody in den faq's beschrieben ist. (danke)

und folgende Packete übersetzt und per stow (der sauberkeit halber) installiert

libmad-0.15.1b
mysql-4.1.14
taglib-1.4

und muggle-0.1.8 mit mysql server und embedet ...

wenn ich mugglei gegen meinen mysql server laufen lasse ...
krieg ich wie vorher ein segfault...

diesmal hab ich valgrind von backport.org selbst übersetzt und jetzt lauft valgrind ...

folgenden output hab ich bekommen ...

Importing 01 - Swamped.mp3
Using TCP for connecting to server 192.168.0.200 as user muggle.
1BB884C0:1 rows: SELECT cddbid FROM album WHERE title='Comalies' AND artist='Lacuna Coil'
1BB884C0:1 rows: SELECT id from tracks WHERE mp3file='01 - Swamped.mp3'
==24890==
==24890== Invalid read of size 4
==24890==    at 0x8055520: mgSQLStringImp::quoted(void) const (mg_db.c:166)
==24890==    by 0x805513D: mgSQLString::quoted(void) const (mg_db.c:98)
==24890==    by 0x805D86A: mgDb::SyncFile(char const *) (mg_db.c:1165)
==24890==    by 0x80563B1: mgDb::Sync(char *const *) (mg_db.c:332)
==24890==  Address 0x1CFA40B4 is 4 bytes inside a block of size 16 free'd
==24890==    at 0x1B9004A7: __builtin_delete (vg_replace_malloc.c:155)
==24890==    by 0x80554F5: mgSQLStringImp::~mgSQLStringImp(void) (mg_db.c:159)
==24890==    by 0x8070123: mgSQLStringMySQL::~mgSQLStringMySQL(void) (mg_db_gd_mysql.c:28)
==24890==    by 0x8054DF0: mgSQLString::~mgSQLString(void) (mg_db.c:43)
==24890==
==24890== Invalid read of size 4
==24890==    at 0x805552C: mgSQLStringImp::quoted(void) const (mg_db.c:168)
==24890==    by 0x805513D: mgSQLString::quoted(void) const (mg_db.c:98)
==24890==    by 0x805D86A: mgDb::SyncFile(char const *) (mg_db.c:1165)
==24890==    by 0x80563B1: mgDb::Sync(char *const *) (mg_db.c:332)
==24890==  Address 0x1CFA40B8 is 8 bytes inside a block of size 16 free'd
==24890==    at 0x1B9004A7: __builtin_delete (vg_replace_malloc.c:155)
==24890==    by 0x80554F5: mgSQLStringImp::~mgSQLStringImp(void) (mg_db.c:159)
==24890==    by 0x8070123: mgSQLStringMySQL::~mgSQLStringMySQL(void) (mg_db_gd_mysql.c:28)
==24890==    by 0x8054DF0: mgSQLString::~mgSQLString(void) (mg_db.c:43)
pure virtual method called
==24890==
==24890== Process terminating with default action of signal 6 (SIGABRT)
==24890==    at 0x1B95BA4B: pthread_kill (vg_libpthread.c:1666)
==24890==    by 0x1B95BB4A: raise (vg_libpthread.c:1676)
==24890==    by 0x1BA66BE0: abort (in /lib/libc-2.2.5.so)
==24890==    by 0x1BA010E7: __default_terminate (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
==24890==
==24890== ERROR SUMMARY: 2091 errors from 8 contexts (suppressed: 4198 from 3)
==24890== malloc/free: in use at exit: 50633644 bytes in 40586 blocks.
==24890== malloc/free: 83730 allocs, 43144 frees, 86694623 bytes allocated.
==24890== For a detailed leak analysis,  rerun with: --leak-check=yes
==24890== For counts of detected errors, rerun with: -v
Aborted