ubuntuusers.de

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:

1
2

gunzip 7999283-cdrecord-fubude-1.gz
mv 7999283-cdrecord-fubude-1 cdrecord-fubude-1

Dann schauen, ob das Programm zu Deinem System passt:

1

./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

1

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

Hallo,

mit dem Binarfile kann ich wohl,nix anfangen 🙄

1
2
3
4
5
6
7
8
9

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..

1
2
3

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 😳

1
2
3

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

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

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

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:

1

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

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 ☹

Hi,

probier mal

1
2

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

Hallo Thomas,

ohje daran hatte ich gar nicht gedacht es zu packen, schande über mich 😳

Hier wie gewünscht, im Anhang das gepackte file...

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

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

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?

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

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.

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

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 🙄

1
2
3
4
5
6

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