scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi, EgLe, hol Dir bitte
https://media-cdn.ubuntu-de.org/forum/attachments/19/01/7999283-cdrecord-fubude-1.gz
und bring den File 7999283-cdrecord-fubude-1.gz in das Verzeichnis
mit den Versuchs-WAV-Files. Dort erstmal entkomprimieren und umnennen:
| gunzip 7999283-cdrecord-fubude-1.gz
mv 7999283-cdrecord-fubude-1 cdrecord-fubude-1
|
Dann schauen, ob das Programm zu Deinem System passt:
| ./cdrecord-fubude-1 -version
|
Das "./" am Anfang ist wichtig, damit das Programm gefunden wird.
Wenn's ok ist, dann muesste gemeldet werden
Cdrecord-ProDVD-ProBD-Clone 3.02a05-fubude-1 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling Wenn es nicht startet, sondern zB. was von "nicht gefunden" erzaehlt,
dann passen die lokalen Libraries nicht zum Programm.
In diesem Fall muesstest Du einen Ubuntu Experten bitten,
die Herstellungsanleitung auf einem passenden System auszufuehren. Mit einem funktionstuechtigen cdrecord-fubude-1 probierst Du dann,
ob das endlich brennt
| sudo ./cdrecord-fubude-1 -V -audio *.wav 2>&1 | tee -i /tmp/cdrecord_fubude_1_log.txt
|
Die Option -V und die Umleitung machen wir, damit wir sie im Erfolgsfall nicht
brauchen. (Wenn's schiefgeht ratseln wir an cdrecord_fubude_1_log.txt rum.) Zur Herstellung: Browser ist Iceweasel aus Debian 8. Javascript is ausgeschaltet.
Auf http://cdrecord.org/ klicke ich auf "Download latest".
Das bringt mich aber nicht nach
http://sourceforge.net/projects/cdrtools/files/latest/download
sondern auf eine leere weisse Seite von cdrecord.org. Wenn ich
das Reload-Icon vom Iceweasel klicke, kommt wieder die Hauptseite. Iceweasel hat einen Debugger. Der sagt:
Load denied by X-Frame-Options: http://sourceforge.net/projects/cdrtools/files/latest/download does not permit cross-origin framing. Ich kopiere also den Link und pappe ihn in die URL Zeile.
http://sourceforge.net/projects/cdrtools/files/latest/download
Das liefert mir ein Binary
$ file cdrecord-prodvd-2.01-pre-x86_64-unknown-linux-gnu
cdrecord-prodvd-2.01-pre-x86_64-unknown-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.1, stripped
"Latest" soll also sowas wie "Antik" heissen, nicht sowas
wie "latest news". Also (wieder mit Copy+Paste) dem Link unter "Download Release 3.01"
gefolgt: http://sourceforge.net/projects/cdrtools/files/
Neuestes Datum ist bei "alpha"
http://sourceforge.net/projects/cdrtools/files/alpha/cdrtools-3.02a05.tar.gz/download In einem Sandkasten packe ich aus
$ tar xzf cdrtools-3.02a05.tar.gz
$ cd cdrtools-3.02
$ view README.compile
$ make
Es meckert ziemlich viel rum ... endet aber mit Exitwert 0.
Ein ausfuehrbarer File ist entstanden
$ ./cdrecord/OBJ/x86_64-linux-cc/cdrecord -version
Cdrecord-ProDVD-ProBD-Clone 3.02a05 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling Die Abhaengigkeiten sind dankenswerterweise sehr wenige
$ ldd ./cdrecord/OBJ/x86_64-linux-cc/cdrecord
linux-vdso.so.1 (0x00007ffed09eb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4454ad8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4454e81000) Ans Werk:
$ cp libscg/scsi-linux-sg.c libscg/scsi-linux-sg.c.orig
$ chmod u+w libscg/scsi-linux-sg.c cdrecord/version.h
$ vi libscg/scsi-linux-sg.c
$ diff -puN libscg/scsi-linux-sg.c.orig libscg/scsi-linux-sg.c
--- libscg/scsi-linux-sg.c.orig 2016-01-09 10:50:43.156000000 +0100
+++ libscg/scsi-linux-sg.c 2016-01-09 10:52:33.924000000 +0100
@@ -1500,7 +1500,7 @@ again:
if (sp->error && sp->ux_errno == 0)
sp->ux_errno = EIO;
- sp->resid = sg_io.resid;
+ sp->resid = 0;
return (0);
}
#else
$ cp cdrecord/version.h cdrecord/version.h.orig
$ vi cdrecord/version.h
$ diff -puN cdrecord/version.h.orig cdrecord/version.h
--- cdrecord/version.h.orig 2016-01-09 11:01:30.864000000 +0100
+++ cdrecord/version.h 2016-01-09 11:01:55.556000000 +0100
@@ -3,4 +3,4 @@
/*
* The version for cdrtools programs
*/
-#define VERSION "3.02a05"
+#define VERSION "3.02a05-fubude-1"
(Warum waren denn die Sourcefiles ohne w-Recht ?) Ich habe kein smake und gehe daher konservativ vor:
$ make clean && make
...
$ ./cdrecord/OBJ/x86_64-linux-cc/cdrecord -version
Cdrecord-ProDVD-ProBD-Clone 3.02a05-fubude-1 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling
$ gzip <./cdrecord/OBJ/x86_64-linux-cc/cdrecord >../cdrecord-fubude-1.gz Have a nice day ☺ Thomas
|
EgLe
(Themenstarter)
Anmeldungsdatum: 29. Juli 2005
Beiträge: 315
Wohnort: BaWü
|
Hallo, mit dem Binarfile kann ich wohl,nix anfangen 🙄 | egle@i7-core-4770:~/test$ mv 7999283-cdrecord-fubude-1 cdrecord-fubude-1
egle@i7-core-4770:~/test$ ./cdrecord-fubude-1 -version
bash: ./cdrecord-fubude-1: Keine Berechtigung
egle@i7-core-4770:~/test$ sudo ./cdrecord-fubude-1 -version
[sudo] password for egle:
sudo: ./cdrecord-fubude-1: command not found
egle@i7-core-4770:~/test$ ls
cdrecord-fubude-1
egle@i7-core-4770:~/test$
|
Selbst wenn ich das file nach /usr/bin kopiere undals root drauf zugreife geht es nicht.. | root@i7-core-4770:/usr/bin# cdrecord-fubude-1 -version
bash: /usr/bin/cdrecord-fubude-1: Keine Berechtigung
root@i7-core-4770:/usr/bin#
|
Ahh habe s doch hinbekommen, das file war nicht ausführbar 😳 | root@i7-core-4770:/usr/bin# cdrecord-fubude-1 -version
Cdrecord-ProDVD-ProBD-Clone 3.02a05-fubude-1 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling
root@i7-core-4770:/usr/bin#
|
Okay hier dann der Test, ist wieder abgebrochen, logfile im Anhang
- cdrecord_fubude_1_log.txt (862.9 KiB)
- Download cdrecord_fubude_1_log.txt
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi, sorry dafuer, dass ich vergessen habe, den chmod u+x Befehl
vorzuschreiben.
Okay hier dann der Test, ist wieder abgebrochen, logfile im Anhang
Das ist diesmal aber viel weiter gekommen beim Schreiben. Es gibt keine "resid:" Meldungen mehr, weil die vermutlich von
der versuchsweisen Codeaenderung vor dem Melder versteckt werden. Das erste WRITE10 Kommando ohne Brennerprotest wird nicht mehr
wiederholt und das Brennen geht wirklich los:
Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB: 2A 00 FF FF FF 6A 00 00 0D 00
cmd finished after 0.001s timeout 200s
Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB: 2A 00 FF FF FF 77 00 00 0D 00
cmd finished after 0.000s timeout 200s Das geht solange gut, bis nach etwa 130 MB ein I/O Error ohne
plausible Erklaerung gemeldet wird:
Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB: 2A 00 00 00 E0 68 00 00 0D 00
cmd finished after 0.013s timeout 200s
Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB: 2A 00 00 00 E0 75 00 00 0D 00
cdrecord-fubude-1: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: cmd timeout after 0.128 (200) s
CDB: 2A 00 00 00 E0 75 00 00 0D 00
cmd finished after 0.128s timeout 200s
cdrecord-fubude-1: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: cmd timeout after 0.128 (200) s
CDB: 2A 00 00 00 E0 75 00 00 0D 00
cmd finished after 0.128s timeout 200s
cdrecord-fubude-1: A write error occured.
cdrecord-fubude-1: Please properly read the error message above. Also wir sind eindeutig ueber das erste Problem hinweg und
in ein weiteres hineingelaufen. Ich glaube nicht, dass der Brenner damit was zu tun hatte.
Da sind wohl wieder cdrecord und das Linux ueberkreuz.
Am .resid kann es aber nicht mehr liegen. Diesmal ist es wohl (sg_io_hdr_t.host_status == 0x03)
Das Linuxgedaerm
#define DID_TIME_OUT 0x03
ist zwar nicht im Userspace definiert, kommt aber in
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html vor.
Man darf sich da wohl drauf beziehen. Joerg ? Gibt's noch andere Pfade zur Timeoutmeldung, wenn
das Kommando gerade mal 0.128 Sekunden lief ?
Nachtrag: Ich dachte erst, dass libburn sich nicht um sg_io_hdr_t.host_status
schert. Das ist aber nicht so. Wenn bei den libburn Laeufen der
host_status 3 gewesen waere, dann haette das recht deutliche Spuren
hinterlassen. U.a. den Text:
0x3 SG_ERR_DID_TIME_OUT (Timed out for miscellaneous reasons)
Das Brennen waere abgebrochen worden. Ich glaube wir brauchen eine neue Theorie fuer den angeblichen Timeout. Have a nice day ☺ Thomas
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi, ich grueble ueber ein Stueck Code in libscg/scsi-linux-sg.c nach. Zeile 1484 ff., Behandlung sonstiger host_status Werte
ausser DID_OK, DID_NO_CONNECT, DID_BAD_TARGET, DID_TIME_OUT
default:
to.tv_sec = sp->timeout;
to.tv_usec = 500000;
__scg_times(scgp);
if (scgp->cmdstop->tv_sec < to.tv_sec ||
(scgp->cmdstop->tv_sec == to.tv_sec &&
scgp->cmdstop->tv_usec < to.tv_usec)) {
sp->ux_errno = 0;
sp->error = SCG_TIMEOUT; /* a timeout */
} else {
sp->error = SCG_RETRYABLE;
} Das sieht doch so aus, als kaeme SCG_TIMEOUT wenn die verbrauchte
Zeit _weniger_ als der eingestellte Timeout betraegt. Zumindest ist scgp->cmdstop->tv_sec das, was in libscg/scsitransp.c
bei der Fehlermeldung als "after ... s" gemeldet wird. Du willst doch wahrscheinlich einen Timeout, wenn die verbrauchte
Zeit groesser ist als die eingestellte Grenze. Unter den "sonstigen" host_status Werten ist auch
0xb SG_ERR_DID_SOFT_ERROR (The low level driver wants a retry)
Der wuerde bei libburn zu einer Wiederholung des Kommandos fuehren
und nicht zum Abbruch. Im Attachment 7994448-cdrskin_log.txt wird der zwar nicht als
Meldung der DEBUG Klasse aufgelistet, was der Fall sein muesste,
wenn er vorgefunden worden waere.
Aber er kann sehr wohl bei den erfolgreichen Braenden mit Xfburn
und Brasero aufgetreten sein.
(Ich gehe mal davon aus, dass BraseroWodim nicht ueber Sektor -150
hinausgekommen waere.) Have a nice day ☺ Thomas
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi EgLe, ich haette da ein bescheidenes Experiment vorzuschlagen.
Naemlich ein cdrecord-fubude-2, das * meldet, wenn resid groesser als 0 ist, bevor der Wert mit
Absicht vergessen wird, * den host_status meldet, wenn es nicht DID_OK ist, * den Timeout bei unerwartetem host_status unter der gegenteiligen
Bedingung ausruft als bisher. Der dritte Teil soll dazu fuehren, dass bei einem unerwarteten
host_status nicht sofort abgebrochen wird. Es mag sein, dass das
den Brenner in den Sumpf faehrt. Aber er ist ja in einer USB-Box.
Wenn sich mehrere Minuten lang kein Fortschritt erkennen laesst,
kann man ihn gnadenhalber abschalten. (Auf die Uhr gucken.
Eine Viertelstunde Geduld muesste reichen.) Wenn wir Pech haben, fangen wir uns bei einer unangemessenen
Wiederholung von WRITE10 wieder die Beschwerde "Invalid address"
vom Brenner ein. Dann hoert er von alleine auf. Schaumermal. Attachment downloaden, gunzippen, umnennen, chmodden auf u+x,
und dann:
| sudo ./cdrecord-fubude-2 -V -audio *.wav 2>&1 | tee -i /tmp/cdrecord_fubude_2_log.txt
|
Der File cdrecord_fubude_2_log.txt interessiert auch im Fall
von Erfolg. Hergestellt nach dem bekannten Verfahren mit diesen Abweichungen
vom originalen cdrtools-3.02a05.tar.gz :
--- libscg/scsi-linux-sg.c.orig 2016-01-09 10:50:43.156000000 +0100
+++ libscg/scsi-linux-sg.c 2016-01-09 23:03:42.196000000 +0100
@@ -127,7 +127,9 @@ static char __sccsid[] =
* Choose your name instead of "schily" and make clear that the version
* string is related to a modified source.
*/
-LOCAL char _scg_trans_version[] = "scsi-linux-sg.c-1.96"; /* The version for this transport*/
+LOCAL char _scg_trans_version[] = "scsi-linux-sg.c-1.96-fubude"; /* The version for this transport*/
+
+#include <stdio.h>
#ifndef SCSI_IOCTL_GET_BUS_NUMBER
#define SCSI_IOCTL_GET_BUS_NUMBER 0x5386
@@ -292,7 +294,7 @@ scgo_version(scgp, what)
* return "schily" for the SCG_AUTHOR request.
*/
case SCG_AUTHOR:
- return (_scg_auth_schily);
+ return ("fubude");
case SCG_SCCS_ID:
return (__sccsid);
case SCG_KVERSION:
@@ -1420,6 +1422,11 @@ again:
sg_io.host_status, sg_io.driver_status);
}
+ if (sg_io.host_status != DID_OK)
+ fprintf(stderr,
+ "cdrecord-fubude: sg_io.host_status = 0x%x\n",
+ (unsigned int) sg_io.host_status);
+
switch (sg_io.host_status) {
case DID_OK:
@@ -1486,9 +1493,9 @@ again:
to.tv_usec = 500000;
__scg_times(scgp);
- if (scgp->cmdstop->tv_sec < to.tv_sec ||
+ if (scgp->cmdstop->tv_sec > to.tv_sec ||
(scgp->cmdstop->tv_sec == to.tv_sec &&
- scgp->cmdstop->tv_usec < to.tv_usec)) {
+ scgp->cmdstop->tv_usec > to.tv_usec)) {
sp->ux_errno = 0;
sp->error = SCG_TIMEOUT; /* a timeout */
@@ -1500,7 +1507,10 @@ again:
if (sp->error && sp->ux_errno == 0)
sp->ux_errno = EIO;
- sp->resid = sg_io.resid;
+ if (sg_io.resid > 0)
+ fprintf(stderr, "cdrecord-fubude: sg_io.resid = %d\n",
+ (int) sg_io.resid);
+ sp->resid = 0;
return (0);
}
#else
--- cdrecord/version.h.orig 2016-01-09 11:01:30.864000000 +0100
+++ cdrecord/version.h 2016-01-09 21:27:18.576000000 +0100
@@ -3,4 +3,4 @@
/*
* The version for cdrtools programs
*/
-#define VERSION "3.02a05"
+#define VERSION "3.02a05-fubude-2" Da ich diesmal nicht einfach einen Vorschlag von Joerg umsetze,
folge ich einigen Forderungen bzgl. "_scg_version and _scg_auth*",
die er in den Sourcecode geschrieben hat.
Fuer eventuelle lizenzmaessige Versaeumnisse bitte ich um Entschuldigung. Have a nice day ☺ Thomas
- cdrecord-fubude-2.gz (224.5 KiB)
- Download cdrecord-fubude-2.gz
|
EgLe
(Themenstarter)
Anmeldungsdatum: 29. Juli 2005
Beiträge: 315
Wohnort: BaWü
|
Hallo Thomas, habe das neue cdrecord nun getestet, im Anhnag das gewünschte logfile 😉 Das brennen war so wie es aussieht erfolgreich, zumindest kann ich die Tracks abspielen von der CD 👍 Hmm, nachtrag: logfile läßt sich direkt hochladen im Forum logfile hat 4MB ☹
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi, probier mal
| gzip /tmp/cdrecord_fubude_2_log.txt
ls -l /tmp/cdrecord_fubude_2_log.txt.gz
|
Ich sehe hier beim (kleineren) cdrecord_fubude_1_log.txt
einen Kompressionsfaktor von 40. Ist halt arg redundant,
so ein SCSI Log. Have a nice day ☺ Thomas
|
EgLe
(Themenstarter)
Anmeldungsdatum: 29. Juli 2005
Beiträge: 315
Wohnort: BaWü
|
Hallo Thomas, ohje daran hatte ich gar nicht gedacht es zu packen, schande über mich 😳 Hier wie gewünscht, im Anhang das gepackte file...
- cdrecord_fubude_2_log.txt.tar.gz (90.1 KiB)
- Download cdrecord_fubude_2_log.txt.tar.gz
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi, Glueckwunsch zum Sieg ueber die Tuecken des Systems. Du koenntest als naechstes versuchen, cdrecord-fubude-2 bei
K3B unterzuschieben. ZB. rausfinden, wo K3B bisher sein
cdrecord hernimmt, dieses umnennen, und cdrecord-fubude-2
an seine Stelle setzen. Das -V brauchen wir erstmal nicht mehr. Wichtig waere zu
erfahren, ob cdrecord-fubude-2 bei mehreren Braenden brav
funktioniert. Ein bisschen laestig ist vermutlich die Bitte, nach jedem
Erfolg in den K3B Logmeldungen nach dem Zeilenanfang
cdrecord-fubude: sg_io.host_status =
zu suchen. Falls sich sowas findet, wuerden mich diese
Logmeldungen interessieren. Vor allem, wie oft die gesuchte
Meldung auftaucht und was jeweils hinter dem "=" Zeichen steht. Bei Misserfolg ist das K3B Log sowieso hochinteressant.
Erkenntnisse aus cdrecord_fubude_2_log.txt Zum resid Problem: Nicht nur das erste akzeptierte Schreibkommando sondern auch
alle folgenden bekommen gemeldet, dass die Bytes noch auf
der Kernelseite der Kommunikation rumlaegen.
"Stimmt so nicht" sagen der Brenner und die abspielbare Musik. Weil fubude-1 und fubude-2 diese Rueckmeldung ignorieren,
kommt das Brennen in Schwung:
...
CDB: 2A 00 FF FF FF 6A 00 00 0D 00
...
Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.000s timeout 200s
Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB: 2A 00 FF FF FF 6A 00 00 0D 00
cdrecord-fubude: sg_io.resid = 30576
cmd finished after 0.000s timeout 200s
Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB: 2A 00 FF FF FF 77 00 00 0D 00
cdrecord-fubude: sg_io.resid = 30576
cmd finished after 0.000s timeout 200s
...
CDB: 2A 00 FF FF FF 84 00 00 0D 00
...
CDB: 2A 00 FF FF FF 91 00 00 0D 00
... . Der Anlass des Abbruchs bei fubude-1 ist leider nicht aufgetreten.
Weder schlug meine Meldung an
cdrecord-fubude: sg_io.host_status = 0x...
noch beschwert sich cdrecord ueber den Ausgang irgendeines
der vielen WRITE10 Kommandos, die es abgeschickt hat. Wir muessen davon ausgehen, dass es sich um eine seltenere
Stoerung handelt als beim resid Problem, das netterweise
zuverlaessig reproduzierbar ist. Ich kann mir nicht sicher sein, ob die Timeout Meldung in
cdrecord_fubude_1_log.txt von der Programmstelle ausgeloest
wurde, an der ich bei fubude-2 herumgefummelt habe. Die Stelle kommt mir aber im Original sehr verdaechtig vor und
wenn mein Verdacht stimmt, wuerde sie sich genauso aeussern wie
in der widerspruchlichen Meldung aus cdrecord_fubude_1_log.txt
cdrecord-fubude-1: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: cmd timeout after 0.128 (200) s
Meine Aenderung wartet hoffentlich die vollen 200 Sekunden,
bevor sie den Timeout ausloest. Have a nice day ☺ Thomas
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi EgLe, ich merke gerade, das cdrecord-fubude-2 bei den "resid" Meldungen
zu geschwaetzig ist, um fuer K3B zu taugen. Darum hier Version 3. Sie meldet nur noch, wenn der host_status
nach Problemmeldung aussieht (und versucht dann weiter den Timeout
erst nach 200 Sekunden auszuloesen). Der aktuelle Stand der Aenderungen in cdrecord-fubude-3: --- libscg/scsi-linux-sg.c.orig 2016-01-09 10:50:43.156000000 +0100
+++ libscg/scsi-linux-sg.c 2016-01-10 13:00:21.924000000 +0100
@@ -127,7 +127,9 @@ static char __sccsid[] =
* Choose your name instead of "schily" and make clear that the version
* string is related to a modified source.
*/
-LOCAL char _scg_trans_version[] = "scsi-linux-sg.c-1.96"; /* The version for this transport*/
+LOCAL char _scg_trans_version[] = "scsi-linux-sg.c-1.96-fubude"; /* The version for this transport*/
+
+#include <stdio.h>
#ifndef SCSI_IOCTL_GET_BUS_NUMBER
#define SCSI_IOCTL_GET_BUS_NUMBER 0x5386
@@ -292,7 +294,7 @@ scgo_version(scgp, what)
* return "schily" for the SCG_AUTHOR request.
*/
case SCG_AUTHOR:
- return (_scg_auth_schily);
+ return ("fubude");
case SCG_SCCS_ID:
return (__sccsid);
case SCG_KVERSION:
@@ -1420,6 +1422,11 @@ again:
sg_io.host_status, sg_io.driver_status);
}
+ if (sg_io.host_status != DID_OK)
+ fprintf(stderr,
+ "cdrecord-fubude: sg_io.host_status = 0x%x\n",
+ (unsigned int) sg_io.host_status);
+
switch (sg_io.host_status) {
case DID_OK:
@@ -1486,9 +1493,9 @@ again:
to.tv_usec = 500000;
__scg_times(scgp);
- if (scgp->cmdstop->tv_sec < to.tv_sec ||
+ if (scgp->cmdstop->tv_sec > to.tv_sec ||
(scgp->cmdstop->tv_sec == to.tv_sec &&
- scgp->cmdstop->tv_usec < to.tv_usec)) {
+ scgp->cmdstop->tv_usec > to.tv_usec)) {
sp->ux_errno = 0;
sp->error = SCG_TIMEOUT; /* a timeout */
@@ -1500,7 +1507,7 @@ again:
if (sp->error && sp->ux_errno == 0)
sp->ux_errno = EIO;
- sp->resid = sg_io.resid;
+ sp->resid = 0;
return (0);
}
#else
--- cdrecord/version.h.orig 2016-01-09 11:01:30.864000000 +0100
+++ cdrecord/version.h 2016-01-10 13:00:45.324000000 +0100
@@ -3,4 +3,4 @@
/*
* The version for cdrtools programs
*/
-#define VERSION "3.02a05"
+#define VERSION "3.02a05-fubude-3" Have a nice day ☺ Thomas
- cdrecord-fubude-3.gz (224.4 KiB)
- Download cdrecord-fubude-3.gz
|
schily
Anmeldungsdatum: 5. November 2008
Beiträge: 178
|
Also das ist jetzt sehr viel und auf alles zu antworten geht in diesem Forum nur extrem schwer. Erstmal: wenn der Linux Kern einen vergleichbaren bug im write(2) Syscall hätte und gelegentlich eine 0 zurückliefern würde obwohl mehr als 30 kB geschrieben wurden, dann dürtfe das alle ordentliche Software zu Abbrüchen zwingen. Wir haben hier also einen schwerwiegenden Kernel Bug, für den ich glaube keinen Workaround anbieten zu können. Hast Du das schon gemeldet, bzw. funktionieren neuere Kernel-Version wieder korrekt? Zum Download: Der Registrar bietet einen Frame zur Einbindung an, der bei allen meinen Browsern funktioniert (speziell Mozilla Firefox). Könnnte es sein, daß dieses Problem auch durch Änderungen von Debian verursacht wird, oder gibt es eine andere Erklärung? Ich habe allerdings vor einiger Zeit mal einen Beschwerde von einem Chrome Nutzer bekommen. Mit der Fehlermeldung kann ich jedenfalls nichts anfangen. Um das Problem (das allerdings in letzter Zeit öfters kommt), benötige ich z.B. mal die URL Ausgabe, die im URL-Cursor Feld kommt wenn man den Cursor über dem Download Link hat. Bei mir wird da eine reine Source-Forge URL angezeigt. Zum Weiteren Vorgehen: Bitte schreibt nochmal eine Antwort, in der alle Punkte zu denen ich Stellung nehmen sollte kurz aufgelistet werden. Wenn es ein Timeout Problem gibt, wo genau soll ich reinsehen? Hinweis: Linux war bei meinen Versuchen ziemlich unzuverlässig bei der korrekten Meldung von Timeouts. Sehe ich das jetzt richtig, daß es da einen Schreibfehler mit dem Vergleichsoperator bei den Timeouts in libscg gab?
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi Joerg,
Wenn es ein Timeout Problem gibt, wo genau soll ich reinsehen?
Pruef bitte meine Theorie, dass in cdrecord 3.02a05, File
libscg/scsi-linux-sg.c, Zeile 1489 bis 1491 die "<" Zeichen
eigentlich ">" oder ">=" sein muessten. (Siehe unten fuer Motivation.) URL Ausgabe, die im URL-Cursor Feld kommt wenn man den Cursor
über dem Download Link hat. Bei mir wird da eine reine Source-Forge
URL angezeigt.
Die Anzeige ist unverdaechtig. Die Browserfunktion "Copy Link
Location" bringt die Source-Forge URL, die prima funktioniert,
wenn man sie ins URL Feld pastet und Return drueckt. Die Iceweasel-Debugger Meldung
Load denied by X-Frame-Options: http://sourceforge.net/projects/cdrtools/files/latest/download does not permit cross-origin framing.
schaut fuer mich nach einer Beschwerde ueber einen HTTP Header
namens "X-Frame-Options:" aus. Die Erkenntnislage zu EgLes Brennproblemen ist folgende: sg_io.resid wird von EgLes System ziemlich routinemaessig
mit Werten > 0 zurueckgegeben. Das kann an der USB Hardware
liegen und/oder am Kernel. Tiefer bohren koennen wir kaum. Die Programme cdrecord-fubude-1 und -2 brennen erstmal los, weil
ich in denen jeweils Deinen Versuchsvorschlag eingebaut habe
- sp->resid = sg_io.resid;
+ sp->resid = 0; Der erste Brennversuch mit dieser Aenderung ist aber nach
gut 128 MB aus einem anderen Grund abgebrochen.
cdrecord-fubude-1: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: cmd timeout after 0.128 (200) s
Ich glaube, das kommt von einem sg_io.host_status != DID_OK,
der in den "default:" case von scgo_send() geraet. In diesem "default:" case glaube ich einen falschen Zeitvergleich
zu sehen, den ich in cdrecord-fubude-2 und cdrecord-fubude-3
versuchsweise geaendert habe.
- if (scgp->cmdstop->tv_sec < to.tv_sec ||
+ if (scgp->cmdstop->tv_sec > to.tv_sec ||
(scgp->cmdstop->tv_sec == to.tv_sec &&
- scgp->cmdstop->tv_usec < to.tv_usec)) {
+ scgp->cmdstop->tv_usec > to.tv_usec)) {
sp->ux_errno = 0;
sp->error = SCG_TIMEOUT; /* a timeout */
Ich glaube, dieser Vergleich verusachte sofortigen Ausruf von
Timeout, obwohl erst 0.128 Sekunden vergangen waren. Der Anlass fuer so einen Abbruch ist aber im voellig erfolgreichen
Lauf mit cdrecord-fubude-2 nicht mehr aufgetreten. Deswegen empfehle ich EgLe, das Programm cdrecord-fubude-3
eine Weile zu benutzen, und nach meinen Meldungen wegen host_status
zu schauen. Dann wuerde man wenigstens wissen, welcher Status
angezeigt wurde, und ob Wiederholung ueberhaupt Sinn macht. libburn wuerde nur wiederholen, wenn sg_io.host_status == 0xB,
oder wenn (sg_io.driver_status & 0xf0) == SG_ERR_SUGGEST_RETRY.
Ansonsten wuerde sie ohne DID_OK das Brennen abbrechen. Es kann also sein, dass libburn beim selben Anlass auch gescheitert
waere. Ich glaube mittlerweile an leicht defekte USB Hardware.
Ein solcher Kernelfehler im Ubuntu LTS aus heiterem Himmel muesste
schon frueher aufgefallen sein. Have a nice day ☺ Thomas
|
schily
Anmeldungsdatum: 5. November 2008
Beiträge: 178
|
Also das mit dem Timeout ist nun klar: es war ein Cut/Paste Feher von scsi-sgi.c und der Code wurde nach der Übernahme falsch angepaßt. Wissen wir denn was der Linux Kern für einen Fehlercode bei diesem "Timeout" gemeldet hat? Dinge wie "suggest retry" aus dem kern sind fehl am Platz, denn verstehen kann (und entscheiden) das nur derjenige, der das Kommando gebaut hat. EgLe sollte aber dringend mal einen neuen Linux Kern testen ob der resid Bug dort beseitigt wurde, denn das Verhalten von Linux ist folgendermaßen zu erwarten: * normalerweise wird resid im Kern auf 0 belassen, weil der Linux Kern das eigentlich nicht unterstürzt. Genauso ist es ja auch dutzende Male vorher passiert * falls der Linux Kern irgenwann Unterstützung für eine Meldung vom Resid Counter eingebaut hat, erwarte ich, daß dies fehlerfrei geschieht. Zum Download: das sieht nach einer Fehlinterpretation aus: sowas könnte ja nur cdrecord.org verbieten und dort wird es nicht getan.
|
scdbackup
Anmeldungsdatum: 7. November 2013
Beiträge: 171
|
Hi,
Also das mit dem Timeout ist nun klar: es war ein Cut/Paste Feher von scsi-sgi.c und der Code wurde nach der Übernahme falsch angepaßt.
Ist meine Versuchskorrektur richtig in dem Sinne, dass
der Code dann macht, was Du in dem Fall beabsichtigst ? Wissen wir denn was der Linux Kern für einen Fehlercode bei diesem "Timeout" gemeldet hat?
Das Log des Laufs (mit leise geloeschten resid) ist in
https://media-cdn.ubuntu-de.org/forum/attachments/54/01/7999588-cdrecord_fubude_1_log.txt
Der Pseudo-Timeout passiert etwa 50 Zeilen vor Schluss.
"Eingabe-/Ausgabefehler" meint wohl EIO. "cdrecord-fubude-1" ist wohl Element 0 aus argv. Durch den Abbrucheifer des "default:" case wissen wir aber
ziemlich sicher, dass es ein sg_io.host_status war, der nicht
in den cases davor abgehandelt wird. Have a nice day ☺ Thomas
|
EgLe
(Themenstarter)
Anmeldungsdatum: 29. Juli 2005
Beiträge: 315
Wohnort: BaWü
|
Hallo Thomas, scdbackup schrieb:
ich merke gerade, das cdrecord-fubude-2 bei den "resid" Meldungen
zu geschwaetzig ist, um fuer K3B zu taugen. Darum hier Version 3. Sie meldet nur noch, wenn der host_status
nach Problemmeldung aussieht (und versucht dann weiter den Timeout
erst nach 200 Sekunden auszuloesen).
Habe die cdrecord-fubude-2 einfach nach /usr kopiert und umbenannt zu "cdrecord", so verwendet die dann K3B Problemlos. Leider klappt das brennen nicht mit K3B und dieser cdrecor-version, hat Laut K3B nach 4% abgebrochen. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178 | Devices
-----------------------
MATSHITA BD-MLT UJ230AS 1.20 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R doppelschichtig, BD-CD-ROM, BD-CD-R, BD-RE, DVD+R, DVD+RW, DVD+R doppelschichtig) [DVD-ROM, DVD-R sequenziell, Zweischichtige DVD-R sequenziell, DVD-RAM, DVD-RW Eingeschränktes Überbrennen, DVD-RW sequenziell, DVD+RW, DVD+R, Zweischichtige DVD+R, CD-ROM, CD-R, CD-RW, BD-CD-ROM, BD-R sequenziell (SRM), BD-R Zufällig (RRM), BD-RE] [SAO, TAO, RAW, RAW/R16, RAW/R96P, RAW/R96R, Eingeschränktes Überschreiben, Zufällige Aufnahme, Sequenzielle Aufnahme, Sequenzielle Aufnahme + POW] [%7]
System
-----------------------
K3b Version: 2.0.2
KDE Version: 4.13.3
QT Version: 4.8.6
Kernel: 3.13.0-74-generic
Used versions
-----------------------
cdrecord: 3.2a05-fubude-3
cdrecord
-----------------------
cdrecord: Vorgang nicht zulässig. Warning: Cannot raise RLIMIT_MEMLOCK limits.
cdrecord: Nicht genügend Hauptspeicher verfügbar. WARNING: Cannot do mlockall(2).
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Vorgang nicht zulässig. WARNING: Cannot set RR-scheduler.
cdrecord: Keine Berechtigung. WARNING: Cannot set priority using setpriority().
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Insufficient 'file read' privileges. You will not be able to open all needed devices.
cdrecord: Insufficient 'file write' privileges. You will not be able to open all needed devices.
cdrecord: Insufficient 'device' privileges. You may not be able to send all needed SCSI commands, this my cause various unexplainable problems.
cdrecord: Insufficient 'memlock' privileges. You may get buffer underruns.
cdrecord: Insufficient 'priocntl' privileges. You may get buffer underruns.
cdrecord: Insufficient 'network' privileges. You will not be able to do remote SCSI.
scsidev: '/dev/sr0'
devname: '/dev/sr0'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
cdrecord: Warning: using inofficial libscg transport code version (fubude-scsi-linux-sg.c-1.96-fubude '@(#)scsi-linux-sg.c 1.96 13/05/28 Copyright 1997-2013 J. Schilling').
SCSI buffer size: 64512
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
Text len: 720
Cdrecord-ProDVD-ProBD-Clone 3.02a05-fubude-3 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling
TOC Type: 0 = CD-DA
Using libscg version 'schily-0.9'.
Driveropts: 'burnfree'
atapi: 1
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identifikation : 'BD-MLT UJ230AS '
Revision : '1.20'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: CD-R
Profile: BD-R sequential recording
Profile: BD-R random recording
Profile: BD-RE
Profile: BD-ROM
Profile: DVD-RAM
Profile: DVD+R/DL
Profile: DVD+R
Profile: DVD+RW
Profile: DVD-RW restricted overwrite
Profile: DVD-RW sequential recording
Profile: DVD-R/DL sequential recording
Profile: DVD-R sequential recording
Profile: DVD-ROM
Profile: CD-RW
Profile: CD-R (current)
Profile: CD-ROM
Profile: Removable Disk
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1179648 = 1152 KB
FIFO size : 4194304 = 4096 KB
cdrecord: Vorgang nicht zulässig. WARNING: Cannot set RR-scheduler.
cdrecord: Keine Berechtigung. WARNING: Cannot set priority using setpriority().
cdrecord: WARNING: This causes a high risk for buffer underruns.
pregap1: -1
Track 01: audio 38 MB (03:48.72) no preemp swab copy
Track 02: audio 36 MB (03:36.24) no preemp swab copy
Track 03: audio 39 MB (03:55.90) no preemp swab copy
Track 04: audio 26 MB (02:35.34) no preemp swab copy
Track 05: audio 39 MB (03:55.84) no preemp swab copy
Track 06: audio 40 MB (04:01.66) no preemp swab copy
Track 07: audio 38 MB (03:46.36) no preemp swab copy
Track 08: audio 38 MB (03:49.36) no preemp swab copy
Track 09: audio 28 MB (02:48.40) no preemp swab copy
Track 10: audio 30 MB (03:00.17) no preemp swab copy
Track 11: audio 42 MB (04:13.08) no preemp swab copy
Track 12: audio 41 MB (04:08.80) no preemp swab copy
Track 13: audio 44 MB (04:22.66) no preemp swab copy
Track 14: audio 44 MB (04:23.14) no preemp swab copy
Track 15: audio 33 MB (03:21.72) no preemp swab copy
Track 16: audio 42 MB (04:13.84) no preemp swab copy
Track 17: audio 36 MB (03:36.14) no preemp swab copy
Track 18: audio 32 MB (03:14.38) no preemp swab copy
Total size: 674 MB (66:51.80) = 300885 sectors
Lout start: 675 MB (66:53/60) = 300885 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 5
Disk Is not unrestricted
Disk Is not erasable
Disk sub type: Medium Type B, low Beta category (B-) (4)
ATIP start of lead in: -11607 (97:27/18)
ATIP start of lead out: 359849 (79:59/74)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 18
Manufacturer: Plasmon Data systems Ltd.
Capacity Blklen/Sparesz. Format-type Type
359849 2048 0x00 Unformated or Blank Media
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 58964
Starting to write CD/DVD/BD at speed 8 in real SAO mode for single session.
Last chance to quit, starting real write in 3 seconds.
2 seconds.
1 seconds.
0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is OFF.
Turning BURN-Free on
Performing OPC...
Sending CUE sheet...
SAO startsec: -11607
Writing lead-in...
Lead-in write time: 22.964s (00:00:22.964)
Writing pregap for track 1 at -150
Starting new track at sector: 0
Track 01: 0 of 38 MB written.
Track 01: 1 of 38 MB written (fifo 100%) 8,1x.
Track 01: 2 of 38 MB written (fifo 100%) [buf 99%] 8,3x.
Track 01: 3 of 38 MB written (fifo 100%) [buf 99%] 8,5x.
Track 01: 4 of 38 MB written (fifo 100%) [buf 100%] 8,3x.
Track 01: 5 of 38 MB written (fifo 100%) [buf 100%] 8,5x.
Track 01: 6 of 38 MB written (fifo 100%) [buf 99%] 8,2x.
Track 01: 7 of 38 MB written (fifo 100%) [buf 99%] 8,5x.
Track 01: 8 of 38 MB written (fifo 100%) [buf 100%] 8,3x.
Track 01: 9 of 38 MB written (fifo 100%) [buf 100%] 8,5x.
Track 01: 10 of 38 MB written (fifo 100%) [buf 99%] 8,2x.
Track 01: 11 of 38 MB written (fifo 100%) [buf 99%] 8,5x.
Track 01: 12 of 38 MB written (fifo 100%) [buf 100%] 8,2x.
Track 01: 13 of 38 MB written (fifo 100%) [buf 100%] 8,5x.
Track 01: 14 of 38 MB written (fifo 100%) [buf 99%] 8,2x.
Track 01: 15 of 38 MB written (fifo 100%) [buf 99%] 8,5x.
Track 01: 16 of 38 MB written (fifo 100%) [buf 100%] 8,2x.
Track 01: 17 of 38 MB written (fifo 100%) [buf 100%] 8,4x.
Track 01: 18 of 38 MB written (fifo 100%) [buf 99%] 8,2x.
Track 01: 19 of 38 MB written (fifo 100%) [buf 99%] 8,4x.
Track 01: 20 of 38 MB written (fifo 100%) [buf 100%] 8,2x.
Track 01: 21 of 38 MB written (fifo 100%) [buf 100%] 8,4x.
Track 01: 22 of 38 MB written (fifo 100%) [buf 99%] 8,1x.
Track 01: 23 of 38 MB written (fifo 100%) [buf 99%] 8,4x.
Track 01: 24 of 38 MB written (fifo 100%) [buf 100%] 8,2x.
Track 01: 25 of 38 MB written (fifo 100%) [buf 100%] 8,4x.
Track 01: 26 of 38 MB written (fifo 100%) [buf 99%] 8,1x.
Track 01: 27 of 38 MB written (fifo 100%) [buf 99%] 8,4x.
Track 01: 28 of 38 MB written (fifo 100%) [buf 100%] 8,1x.
Track 01: 29 of 38 MB written (fifo 100%) [buf 100%] 8,4x.
Track 01: 30 of 38 MB written (fifo 100%) [buf 99%] 8,1x.
cdrecord-fubude: sg_io.host_status = 0x7
cdrecord: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: retryable error
CDB: 2A 00 00 00 35 28 00 00 1B 00
status: 0x0 (GOOD STATUS)
cmd finished after 0.132s timeout 200s
cdrecord: A write error occured.
cdrecord: Please properly read the error message above.
write track data: error after 32006016 bytes
Writing time: 50.891s (00:00:50.891)
Average write speed 143,7x.
Min drive buffer fill was 99%
Fixating...
Fixating time: 1.626s (00:00:01.626)
cdrecord: fifo had 568 puts and 505 gets.
cdrecord: fifo was 0 times empty and 504 times full, min fill was 98%.
cdrecord command:
-----------------------
/usr/bin/cdrecord -v gracetime=2 dev=/dev/sr0 speed=8 -sao driveropts=burnfree textfile=/tmp/qt_temp.Hk4108 -useinfo -audio /tmp/kde-egle/k3b_audio_0_01.inf /tmp/kde-egle/k3b_audio_0_02.inf /tmp/kde-egle/k3b_audio_0_03.inf /tmp/kde-egle/k3b_audio_0_04.inf /tmp/kde-egle/k3b_audio_0_05.inf /tmp/kde-egle/k3b_audio_0_06.inf /tmp/kde-egle/k3b_audio_0_07.inf /tmp/kde-egle/k3b_audio_0_08.inf /tmp/kde-egle/k3b_audio_0_09.inf /tmp/kde-egle/k3b_audio_0_10.inf /tmp/kde-egle/k3b_audio_0_11.inf /tmp/kde-egle/k3b_audio_0_12.inf /tmp/kde-egle/k3b_audio_0_13.inf /tmp/kde-egle/k3b_audio_0_14.inf /tmp/kde-egle/k3b_audio_0_15.inf /tmp/kde-egle/k3b_audio_0_16.inf /tmp/kde-egle/k3b_audio_0_17.inf /tmp/kde-egle/k3b_audio_0_18.inf
|
Warum er schreit das mein Hauptspeicher zu wenig wäre. keine Ahnung 🙄
| egle@i7-core-4770:~$ free -m -t
Gesamt Belegt Frei Gemeinsam Puffer Cache
Speicher: 7900 3513 4387 203 4 2069
-/+ Puffer/Cache: 1439 6461
Auslagerungsdatei: 3814 0 3814
Gesamt: 11715 3513 8202
|
PS: da mein Urlaub vorbei ist und ich wieder arbeite, dauert es nun länger bis ich Testen und Antworten kann ☺ Gruß Egon
|