ubuntuusers.de

EgLe schrieb:

Hoffentlich ist der dann in der 16.04 Ubuntuversion dann auch gleich mit drinn 😉

Die Chancen, dass Debian sich überhaupt - und dann auch noch in einer solchen Geschwindigkeit - dazu entschließt, die cdrtools in die Paketquellen aufzunehmen würde ich optimistisch gesehen mit äußerst gering ansetzen.

Vielleicht schaltet libburn ja BurnProof per Default an und vermeidet dadurch den Buffer undderrun?

Cdrecord tut das nicht, weil dieses Feature die Audioqualität geringfüfig verschlechtert.

Es sind natürlich auch zufällige Timing-Effekte möglich.... Dieses Problem ist jedenfalls typisch für Linux und wurde noch von keinem der anderen 30 unterstützten Plattformen berichtet.

Wenn libburn keine Fehlermeldungen bei Mode Sense bekommt, heißt das nur daß es weniger kann als cdrecord, denn SCSI ist ein Protokoll, daß davon lebt, das bestimmte Kommandos mit einem scheinbaren "Fehler" beendet werden um anzuzeigen das im LW etwas nicht unterstützt wird was vom Programm nachgefragt wurde.

Libburn behauptet ja unter Linux ohne root Rechte oder vergleichbares auszukommen. Das ist ein weiterer Hinweis darauf, daß libburn weniger Features hat als cdrecord, denn cdrecord benötigt für seine Features SCSI Kommandos die auch auf Linux nicht ohne erweiterte Rechte funktionieren.

Achja: cdrecord sieht nicht nur auf Linux ioctl Returnwerte, sondern hält sich an die Festlegungen des SCSI Standards, denn es muß auf mehr als 30 unterschiedlichen Plattformen korrekt funktionieren.

schily schrieb:

Vielleicht schaltet libburn ja BurnProof per Default an und vermeidet dadurch den Buffer undderrun?

Sollte sich doch so:

sudo cdrecord driveropts=burnfree -audio ~/Musik/*.wav 

testen lassen, oder?

Hi,

Sachma Joerg, warum macht das neuere cdrecord das hier ?

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: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: no error
CDB:  2A 00 FF FF FF 6A 00 00 0D 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) Fru 0x0
Sense flags: Blk 0 (not valid)
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 6A 00 00 0D 00
resid: 30576
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 6A 00 00 0D 00
cdrecord: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: no error
CDB:  2A 00 FF FF FF 6A 00 00 0D 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 02 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 30576
cmd finished after 0.001s timeout 200s

Der Brenner kommt aus den SAO Vorbereitungen raus und will endlich das erste WRITE10 annehmen. cdrecord sieht .resid > 0 aber keinen Fehler.

Warum wiederholt es dann aber das WRITE10 auf 0xffffff6a ?

Wenn's kein Fehler war, darf man da auch nicht mehr hinschreiben. Kein Wunder, dass der Brenner nicht weiter mitspielen mag und cdrecord ungueltiger Adressierung bezichtigt.

Ich wuerde sagen, dass Dein "resid:" Wachhund etwas zu agressiv reagiert. Passt zur Faktenlage.

Guck doch mal in Deiner Source, ob da vielleicht ein Spiels-nochmal-Sam kommt, wenn .resid > 0.

Joerg Schilling schrub:

Vielleicht schaltet libburn ja BurnProof per Default an

Ja. Tut sie.

Das waere dann mit cdrecord (grabend in 10 jaehrigen Erinnerungen ...) zusaetzlich die Option driveropts=burnfree

sudo cdrecord driveropts=burnfree -audio *.wav

und vermeidet dadurch den Buffer undderrun?

Aber was soll beim ersten WRITE10 auf 0xffffff6a underrunnen ?

cdrecord ist kein einziges Byte Musik beim Brenner losgeworden.

Es sind natürlich auch zufällige Timing-Effekte möglich

Die muessten aber doch ab und zu Misserfolge bei libburn ausloesen. (Solche wegen "Medium Error" muss man dabei natuerlich weglassen. Die koennen immer passieren.)

Wenn libburn keine Fehlermeldungen bei Mode Sense bekommt, heißt das nur daß es weniger kann als cdrecord,

Oder sie schickt was nicht, was der Brenner hasst und was auch nicht fuer einen netten SAO Audio Lauf noetig ist. (Ich hoffe doch, die Musik spielt. EgLe, tut sie ?)

Und ich sag ja nicht, dass man normalerweise nicht beim Brenner mit Befehlen anklopfen darf, auf die man eine Fehlermeldung bekommt. Mir faellt nur auf, dass crdrecord welche bei MODE SELECT bekommt, dass MODE SELECT auch SAO einstellen soll, und dass der Fehlschlag am Schluss aussieht, als wuerde der Brenner kein SAO erwarten.

Wie auch immer, das doppelte WRITE10 da oben ist ein prima Kandidat, der erstmal ausgeschlossen werden muesste, bevor man irgendwo anders sucht.

Libburn behauptet ja unter Linux ohne root Rechte oder vergleichbares auszukommen.

Tut sie beides. Behaupten (tun eigentlich ich und meine User) und Auskommen (tut libburn).

Achja: cdrecord sieht nicht nur auf Linux ioctl Returnwerte,

Auf Solaris, FreeBSD, und NetBSD mache ich das auch anders.

Bei Linux lasse ich mich halt auf die Kernelhacker ein und gehe udev moeglichst aus dem Weg. Letzterer ist mittlerweile recht harmlos, wenn man ihn solange an frisch eingelegten Medien lutschen laesst, bis es ihm langweilig wird. (D.h. Blinkenlichten gehen aus.)

Ich hab jetzt ein Debian 8 mit systemd und aller Annoyanz. Man kann damit leben. Schulterzuck.

30 unterschiedlichen Plattformen

Fuer mehr als 4 hat sich bei mir noch keiner interessiert. (Das heisst, fuer eine mehr schon. Aber die muesste ich kaufen.)

Have a nice day ☺

Thomas

Erstmal ne kurze Antwort: direkt nach Schreiben des Leadin mit -sao klappt ein READ CAPACITY und damit kann eines der bösartigen Linux Systemprogramme genau in diesem Moment zu lesen versuchen und damit den Buffer Underrun auslösen.

Die SAO Unterstützung in cdrecord ist seit 19 Jahren genau so drin und hat auf fehlerfreien Betriebssystemen auch immer funktioniert - Ausnahme der Lite-ON Firmware Bug der defekte Subkanaldaten schreibt, weshalb cdrecord ja auch -raw96r unterstützt.

Ich glaube daher, wir müssen nicht diskutieren ob cdrecord da evt. was falsch macht.

Hi,

Ich glaube daher, wir müssen nicht diskutieren ob cdrecord da evt. was falsch macht.

Zweimal auf die selbe Stelle schreiben ist bei unformatierten CD auf jeden Fall nicht richtig.

Natuerlich braucht das noch Hilfe von einem bescheuerten Kernel, der .resid nicht auf 0 setzt, obwohl die Transaktion funktioniert hat.

Schau halt in der Source nach, ob meine Theorie zutrifft, dass .resid > 0 auch ohne andere Fehlerindikation eine Wiederholung des WRITE10 Kommandos ausloest.

Wenn das so ist, dann wuerde ich an Deiner Stelle meinem User EgLe einen Versuchstarball fertigmachen, damit er testen kann, ob es ohne die Wiederholung funktioniert.

EgLe ist mutig. Das muss man ausnutzen, wenn man was lernen will.

Have a nice day ☺

Thomas

Der Kern sagt ja von den gewünschten 13 Sektoren sei nichts geschrieben worden.

Da aber schon beim Versuch auf Adresse -150 zu schreiben ein Fehler kommt, solte klar sein daß irgendwer vorher einen Buffer underrun ausgelöst hat (also der automounter support in hald, udev oder systemd) und das LW wohl als Resultat Run-Out Sektoren geschrieben hat weshalb -150 schon beim ersten Versuch nicht mehr verwendbar ist.

Im übrigen warte ich noch darauf, daß der OP cdrecord -raw96r bzw. cdrecord driveropts=burnfree testet.

Das erste ist als Workaround für die defekten Systemprogramme als hilfreich bekannt und an vielen Stellen dokumentiert.

Hi,

Der Kern sagt ja von den gewünschten 13 Sektoren sei nichts geschrieben worden.

Ja. Der Kernel luegt. Genauso wie der Brenner, wenn man ihn nach der Next Writable Address fragt. Das ist doch nichts Neues.

Die Frage ist, ob cdrecord dann nochmal auf die selbe Stelle schreiben darf, wenn vom Brenner keine Ablehnung wegen LOGICAL UNIT NOT READY kommt.

Ich bin mir ziemlich sicher, dass libburn dieselben falschen .resid Werte gemeldet bekommt. Sie kuemmert sich bloss nicht darum sondern schreibt froehlich die naechsten 13 Sektoren. Der Drive ist gluecklich, libburn ist gluecklich. Minutenlang.

Im übrigen warte ich noch darauf, daß der OP cdrecord -raw96r bzw. cdrecord driveropts=burnfree testet.

Bist Du sicher, dass Du EgLe das klar genug erklaert hast ?

driveropts=burnfree hat uebrigens K3B schon mal getestet. Siehe Zeile 131 in den K3B Meldungen im allersten Post dieses Threads.

Das erste ist als Workaround für die defekten Systemprogramme als hilfreich bekannt und an vielen Stellen dokumentiert.

Der Unterschied zwischen unseren beiden Theorien wuerde sich zeigen, wenn es wieder zur Wiederholung eines WRITE10 kommt, nachdem beim vorherigen keine Sense Data angefallen sind.

Bei diesen Vorausetzungen wuerde Brennerfolg Dir recht geben, und Misserfolg mir. Allerdings muessten wir dazu wieder einen Lauf mit -V vorschlagen und die Meldungen in einen File umleiten lassen.

Wenn -raw96r nicht zu Wiederholungen fuehrt und das Brennen klappt, dann ist unentschieden. Du muesstest nur noch erklaeren, wie man K3B dazu bringt, das auch so zu machen.

Have a nice day ☺

Thomas

Hallo,

Sorry ich wollte aber keinen Streit unter Entwickler verursachen, da ich echt Respekt

vor Leuten wie euch habe und die Welt froh sein kann das es Personen wie euch gibt 👍

scdbackup schrieb:

Oder sie schickt was nicht, was der Brenner hasst und was auch nicht fuer einen netten SAO Audio Lauf noetig ist. (Ich hoffe doch, die Musik spielt. EgLe, tut sie ?)

Ja, die aufnahmen mit der aus der Kosole mit libburnia und gebrannte von Xfburn,

sowie die 2 gebrannten mittels Brasero funktionieren perfect.

Habe diese auf meinem Linux mit dem genannten Brenner, auf dem Windowsrechner und auf einen JVC DVD-Player geprüft 👍

scdbackup schrieb:

Im übrigen warte ich noch darauf, daß der OP cdrecord -raw96r bzw. cdrecord driveropts=burnfree testet.

So habe mal folgendes getestet mit meinen unerfahren Konsolenbefehlen:

1

sudo cdrecord -raw96r -V -audio *.wav 2>&1 | tee -i /tmp/cdrecord_raw96r_log.txt

Danach dann dies:

1

sudo cdrecord driveropts=burnfree -V -audio *.wav 2>&1 | tee -i /tmp/cdrecord_burnfree_log.txt

Natürlich jeweils mit einer frischen leeren CD, die Logfiles jeweils sind im Anhang.

PS: mir ging es in dem Thread eigentlich auch darum festzustellen ob mein Brenner defekt ist und ob ich den noch umtauschen kann, weil Kontakt habe ich schon aufgenommen mit dem Vertieb...

Wenn es natürlich ein Fehler des Systems ist und ich helfen kann, dies zu bereinigen helfe ich gerne im Rahmen meiner Möglichkeiten 😉

Hi,

Sorry ich wollte aber keinen Streit unter Entwickler verursachen,

Ach, Streit um CD sieht anders aus. ☺

https://media-cdn.ubuntu-de.org/forum/attachments/08/01/7996518-cdrecord_raw96r_log.txt

Meine Theorie hat an Glaubwuerdigkeit gewonnen.

Das Schreiben geht solange gut, bis der Kernel .resid > 0 ohne SCSI Fehler behauptet

Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 40s
CDB:  2A 00 FF FF FF 6A 00 00 0D 00
resid: 31824
cmd finished after 0.019s timeout 40s

und cdrecord das WRITE10 Kommando mit der selben Adresse wiederholt:

Executing 'write_g1' command on Bus 6 Target 0, Lun 0 timeout 40s
CDB:  2A 00 FF FF FF 6A 00 00 0D 00
cdrecord: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: no error
CDB:  2A 00 FF FF FF 6A 00 00 0D 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 02 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 31824
cmd finished after 0.001s timeout 40s

Warum cdrecord dann noch versucht, an einigen anderen Stellen zu schreiben, ist mir nicht ganz klar:

CDB:  2A 00 00 00 00 00 00 00 0D 00
CDB:  2A 00 00 04 55 5A 00 00 0D 00

https://media-cdn.ubuntu-de.org/forum/attachments/08/01/7996518-cdrecord_burnfree_log.txt

Stirbt an genau der selben Stelle mit der selben Geste. Die Theorie des Buffer-Underrun ist auf jeden Fall nicht mehr plausibel.

Wenn es natürlich ein Fehler des Systems ist und ich helfen kann, dies zu bereinigen helfe ich gerne im Rahmen meiner Möglichkeiten

Die Chancen, dass die Kernelentwickler sowas reparieren, sind nicht sehr gut. Zumal Deine Version 3.13.0-63 noch ein bisschen aelter ist als meine. Ausserdem muss auch Deine Hardware noch ein bisschen mitgeholfen haben, damit es schiefgeht.

Du kannst versuchen, Joerg zu ueberreden, Dir ein cdrecord zu machen, das sich von Deinem Linux nicht so in die Irre fuehren laesst. Nur so zur Probe.

Have a nice day ☺

Thomas

Hi,

mir ging es in dem Thread eigentlich auch darum festzustellen ob mein Brenner defekt ist und ob ich den noch umtauschen kann, weil Kontakt habe ich schon aufgenommen mit dem Vertieb...

Dem Brenner koennen wir zur Zeit nur die Allerweltssuende vorwerfen, als Startadresse fuer einen SAO Lauf den Block Nummer 0 und nicht Block -150 zu nennen. Sowas gleichen die Brennprogramme aber schon routinemaessig aus.

Es waere natuerlich interessant zu sehen, ob die seltsamen Antworten des Linux Kernels auch mit einem anderen Brenner auftreten. Dann waere ziemlich sicher der Kernel oder der Computer schuld.

Wenn's mit einem anderen Brenner am selben USB Stecker nicht passiert, dann ist der Brenner schuld. (Nur selbst dann funktioniert er ja mit MS-Windows und mit libburn auf Linux.)

Wohnort: BaWü

Gruss ins Laendle ☺

Thomas

OK, ich habe bisher anscheinend übersehen, daß cdrecord das Problem bekommt nachdem gemeldet wurde das absolut nichts transferiert wurde aber kein sonstiger SCSI Fehler dazu gemeldet wurde.

Das sieht dann womöglich doch nach einen eindeutigen Kernel-Fehler aus.

Da es genügend andere Betriebssysteme gibt, wo man nicht alle SCSI Ergebnisse bekommt, verwendet cdrecord auf der oberen Ebene alle verfügbaren Informationen und speziell wird der nächste Schreibauftrag auf die Adresse geschrieben, die nach den verfügbaren Informationen als nächstes dran wäre.

Um den Kernelbug zu verifizieren, müßte man mal folgendes probieren:

In libscg/scsi-linux-sg.c in der Nähe von Zeile 1500 aus:

1
2

       sp->resid = sg_io.resid;
       return (0); 

ein:

1
2

        sp->resid = 0; 
        return (0); 

machen, neu kompilieren und linken (durch Aufruf von "smake relink" auf oberer Ebene) und dann nochmal testen.

Ist es dann weg, dann ist es ein Kernelbug.

Abhilfe in diesem Fall:

neueren Kern probieren oder wenn das nichts hilft einen Bugreport gegen den Kern aufmachen.

Hallo,

schily schrieb:

Um den Kernelbug zu verifizieren, müßte man mal folgendes probieren:

In libscg/scsi-linux-sg.c in der Nähe von Zeile 1500 aus:

1 2	sp->resid = sg_io.resid; return (0);

ein:

1 2	sp->resid = 0; return (0);

machen, neu kompilieren und linken (durch Aufruf von "smake relink" auf oberer Ebene) und dann nochmal testen.

Ist es dann weg, dann ist es ein Kernelbug.

Abhilfe in diesem Fall:

neueren Kern probieren oder wenn das nichts hilft einen Bugreport gegen den Kern aufmachen.

Also das kann ich so nicht testen, dazu reichen meine Kenntnisse nicht aus. Sorry ☹

Erstmal der Anhang, damit ich drauf verlinken kann.

cdrecord-fubude-1.gz ist ein amd64 Debian 8 Binary, gzip komprimiert. Es stammt von http://sourceforge.net/projects/cdrtools/files/alpha/cdrtools-3.02a05.tar.gz/download. Die beiden Aenderungen an der Source werden im naechsten Beitrag dokumentiert.