ubuntuusers.de

tomtomtom schrieb:

Xfburn nutzt nicht wodim sondern libburnia.

Danke, gut zu wissen. Ich war einfach vom Standard ausgegangen. Damit wäre ein Test mit xfburn sehr interessant ...

Hi,

die erste Fehlermeldung mit den alten Rohlingen sieht aus wie schlecht gewordene CD:

Sense Key: 0x3 Medium Error, Segment 0

Die Meldung mit den neuen Rohlingen ist ziemlich sicher ein Problem der Elektronik (Computer, Kabel, Brennerelektronik)

/usr/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error status: 0x0 (GOOD STATUS) cmd finished after 201.377s timeout 200s

Der Brenner meldet keinen Fehler, aber Linux wurde langweilig.

Nochn Versuch, nochn neuer Fehler:

CDB: 2A 00 FF FF FF 6A 00 00 1B 00 ... Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0

Da koennte aus Versehen eine bereits geschriebene CD ins Laufwerk geraten sein. Die Zieladresse 0xFFFFFF6A = -150 sieht zwar leicht gruselig aus, ist aber im Schreibmodus SAO die erste, die man mit Daten befuellen muss.

Habe probiert am USB 2.0 und USB 3.0 keinerlei Veränderung...

Schade. USB 3 ist ein beliebter Grund fuer die zweite Sorte von Fehlern. Manche Linux Kernels stellen den USB Timeout falsch ein und dann kommt es bei langlaufenden SCSI Befehlen zu seltsamen Fehlermeldungen. ZB: Sense Key 0xB, Stromausfallsmeldung vom Brenner, unspezifische I/O errors.

Im zweiten Versuch ist allerdings der Timeout von Linux aktiv geworden. Der Brenner gab waehrend 200 Sekunden keine Antwort auf das erste Schreibkommando.

Und wenn es an einem USB 2 Stecker auch spinnt, ist USB 3 diesmal nicht schuld.

Ob's mit libburn besser wird, ist eher zweifelhaft. Mit CDs kommt wodim normalerweise gut klar.

Treiberprobleme

An Treibern sind nur das generische SCSI Layer "SG_IO" und die Treiber fuer die Buskontroller (hier USB) beteiligt. Die sorgen nur dafuer, dass SCSI Kommandos zum Brenner gelangen und die Antwort des Brenners zum Brennprogramm. Alles was spezifisch fuers Brennen ist, machen die Brennprogramme (wodim, growisofs, libburn) selbst.

Meine beste Theorie ist, dass der Brenner kein CD SAO mehr kann. Der Windows Test koennte mit TAO gemacht worden sein. Bei TAO startet das Schreiben nicht bei Block -150 sondern bei 0.

sudo cdrecord -audio ~/Musik_Pfad/*.wav

Man koennte bei diesem wodim Lauf mal die Option -tao vor -audio setzen.

Wenn man in Xfburn den Knopf unten rechts (engl. "Proceed to Burn") klickt, bekommt man ein Dialogfenster, in dem die vierte Einstellung (engl. "Write mode" ) mit "Auto" angeboten wird. Da kann man "TAO" auswaehlen.

Have a nice day ☺

Thomas

Hallo,

also mit XFburn klappte es völlig Problemlos die Audio-CD zu brennen 8x fach gebrannt. ☺

Danach habe ich mal es mit cdrecord aus der konsole herraus probiert:

 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

egle@i7-core-4770:~/Musik/DESTINY /k3bCdCopy0$ sudo cdrecord -audio *.wav              
[sudo] password for egle: 
cdrecord: No write mode specified.
cdrecord: Assuming -sao mode.
cdrecord: If your drive does not accept -sao, try -tao.
cdrecord: Future versions of cdrecord may have different drive dependent defaults.
Cdrecord-ProDVD-ProBD-Clone 3.00 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2010 J�rg Schilling
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
No target specified, trying to find one...
Using dev=6,0,0.
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.
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
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
resid: 60
Starting to write CD/DVD/BD at speed 24 in real SAO mode for single session.
Last chance to quit, starting real write    0 seconds. Operation starts.
Turning BURN-Free off
resid: 60
resid: 60
cdrecord: WARNING: Drive returns wrong startsec (0) using -150
cdrecord: Input/output error. 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
write track pad data: error after 0 bytes
BFree: 44 K BSize: 1152 K
cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB:  2A 00 00 00 00 00 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
write track data: error after 0 bytes
cdrecord: The current problem looks like a buffer underrun.
cdrecord: Try to use 'driveropts=burnfree'.
cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up.
egle@i7-core-4770:~/Musik/DESTINY /k3bCdCopy0$ 

da ging es dann wieder nicht ☹

Hi,

ich finde es zwar garnicht traurig, dass meine libburn bessere Ergebnisse bringt als cdrecord. Plausibel ist das aber nicht ohne weiteres.

Wir kochen alle mit dem selben Wasser (= SCSI Abteilungen SPC und MMC). Es gibt zwar Unterschiede zwischen den SCSI Gesten von cdrecord/wodim und libburn. Die sollten aber bei gesunden Brennern und mit leeren CDs nicht ueber Erfolg oder Misserfolg entscheiden.

Ich weiss jetzt nicht genau, welchen Writetype Xfburn bei libburn bestellt, wenn das Xfburn-Brennmenue auf "Auto" steht. (Ich wuerde SAO vermuten ... aber sicher bin ich nicht.)

$ sudo cdrecord -audio *.wav ... Starting to write CD/DVD/BD at speed 24 in real SAO mode for single session.

da ging es dann wieder nicht.

Das war wieder Writetype SAO. Der mit dem CUE Sheet.

Probier mal

1

sudo cdrecord -tao -audio *.wav

Dann sehe ich da noch seltsame Meldungen von cdrecord

resid: 60

Was will uns der Joerg damit sagen ... ?

Der Name "resid" stammt vermutlich von sg_io_hdr_t Element .resid http://www.faqs.org/docs/Linux-HOWTO/SCSI-Generic-HOWTO.html#AEN356

Das wuerde bedeuten, dass bei einigen SCSI-Befehlen 60 Bytes von der Nutzlast nicht uebertragen wurden. Sehr verdaechtig.

Man muesste cdrecord mit Option -V laufen lassen, damit es die SCSI Befehle vorzeigt, die es an den Brenner schickt.

1

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

Das wird sehr geschwaetzig, deswegen werden hier stdout und stderr durch "tee" geleitet, damit es eine Kopie davon im File

/tmp/cdrecord_log

speichert. Diesen File muesstest Du mir zeigen, damit ich sagen kann, welche SCSI Befehle denn nicht komplett ausgefuehrt wurden.

Have a nice day ☺

Thomas

Hallo,

so habe mal deinen Wunsch entsprochen, und hier die Ausgaben von:

1

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

Als Logfile..

Hi,

es sieht so aus, als wuerde Dein Brenner den Schreibmodus SAO verweigern und cdrecord das nicht rechtzeitig bemerken. Dadurch wird der Brenner von cdrecord beim Schreiben falsch angesteuert und die Sache geht schief.

So ein Brennerverhalten ist nicht normal. Vermutlich gibt Dein Brenner langsam den Loeffel ab.

Es kann sein, dass libburn da schlauer ist und auf TAO schaltet weil Xfburn keine eigene Wahl getroffen hat. Normalerweise wurde libburn auch SAO nehmen. Ich muss mal analysieren, was bei so ungewoehnlichem Brennerverhalten genau passiert.

Eine sehr geschwaetzige Botschaft von libburn bekaeme man mit diesem Kommando:

1

cdrskin -V -vvv dev=/dev/sr0 -audio *.wav 2>&1 | tee -i /tmp/cdrskin_log

(cdrskin ist der cdrecord-Komandozeilenwrapper von libburn.)

Falls cdrskin beim Schreiben Erfolg hat, wird das ziemlich lang, weil man fuer je 32 KB ein Schreibkommando gemeldet bekommt.

Aber interessant waere es fuer mich schon. ☺)

cdrecord_log.txt

Netterweise fragt cdrecord die aktuellen Schreibparameter kurz vor dem Schreiben nochmal ab und zeigt sie:

Executing 'mode sense g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB:  5A 00 05 00 00 00 00 00 3C 00
cmd finished after 0.000s timeout 200s
Mode Sense Data 00 3A 11 00 00 00 00 00 05 32 01 04 08 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Ja ... das erklaert so manches. Der "Write Type" ist 1 = "Track At Once" (TAO), obwohl cdrecord ziemlich sicher 2 = "Session At Once" einstellen will.

Irgendwie nimmt ihm der Brenner die darauf folgende Einstellung nicht ab. Er meldet aber auch keinen Fehler.

Executing 'mode select g1' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB:  55 10 00 00 00 00 00 00 3C 00
resid: 60
cmd finished after 0.000s timeout 200s

60 Bytes der Botschaft sind laut Auskunft des Kernels liegengeblieben und vom Brenner nicht abgenommen worden.

Das SAO-typische Kommando SEND CUE SHEET kann seine Nutzlast auch nicht zustellen:

Executing 'send_cue_sheet' command on Bus 6 Target 0, Lun 0 timeout 200s
CDB:  5D 00 00 00 00 00 00 01 10 00
resid: 272
cmd finished after 0.002s timeout 200s

Wieder ohne Fehlermeldung vom Brenner.

cdrecord: WARNING: Drive returns wrong startsec (0) using -150

Die Ankuendigung des Brenners, bei Sektor 0 starten zu wollen, wird von cdrecord ueberstimmt. Sie wuerde sehr gut zu TAO passen. Bei SAO waere die Startadresse -150.

Und fuer dieses Ueberstimmen gibt's beim ersten Schreibkommando die Quittung:

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: Input/output error. 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.002s timeout 200s
...
cdrecord: Input/output error. 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

Es hat wohl eine Weile gedauert, bis sich der Brenner zur Ablehnung durchringen konnte.

Ich glaube cdrecord grabscht kurz an Deinen Festplatten rum

Inquiry Data   : ....[...ATA     SAMSUNG MZ5PA064AXM0.......................`. .`................................
Inquiry Data   : ....[...ATA     SAMSUNG HD154UI 1AG0.......................`. .`................................
Inquiry Data   : ...2[...MATSHITABD-MLT UJ230AS  1.2011060900        ............................................

(Naja, das Kommand INQUIRY sollten sie schon aushalten. Aber noetig ist so ein Uebergriff nicht. Zuviel Superusertum.)

Verkauft wird der UJ230AS wohl nicht mehr. Sieht im Web aus wie ein Laptopbrenner (BD Leser, DVD/CD Schreiber ?). Zumindest weigert er sich die Schublade einzuziehen und zu verriegeln.

Have a nice day ☺

Thomas

Hallo Thomas,

scdbackup schrieb:

Eine sehr geschwaetzige Botschaft von libburn bekaeme man mit diesem Kommando:

1	cdrskin -V -vvv dev=/dev/sr0 -audio *.wav 2>&1 | tee -i /tmp/cdrskin_log

(cdrskin ist der cdrecord-Komandozeilenwrapper von libburn.)

Falls cdrskin beim Schreiben Erfolg hat, wird das ziemlich lang, weil man fuer je 32 KB ein Schreibkommando gemeldet bekommt.

Aber interessant waere es fuer mich schon. ☺)

So habe mal die nächste CD als Wave auf den Rechner gelegt und wie du es wolltest mittels dem cdrskin per kommandozeile gebrannt, hat soweit geklappt und im Anhang ist das gewünschte logfile.

Der Brenner wird noch über Amazon verkauft, dieser Bezeichnet sich als: - QUMOX USB 3.0 Blu-Ray BD Brenner Slim USB Notebook Laufwerk Extern BluRay/DVD/CD Brennen NEU

Die Frage für mich nun ob ich den zurückgeben oder tauschen kann wenn er nicht richtig arbeitet?

Als Linuxuser wird man ja bei solchen Dingen immer erst schief angeschaut, wenn die dann sehen das er unter Windows funktioniert...

Naja könnte ja auch zum DVD Brennen K3b benutzen und für Audio-CD dann XFburn, bin mal wieder hin und her gerissen.

Wenn ich aber zur verbesserung oder Fehlersuche weiter behilflich sein kann mache ich das gern, nur mein Englisch ist sehr Bescheiden und mit englischsprachigen Support (bei CDrecord usw.) kann ich leider nicht dienen..

Gruß Egon

Hi,

Der Brenner wird noch über Amazon verkauft, Die Frage für mich nun ob ich den zurückgeben oder tauschen kann wenn er nicht richtig arbeitet?

Wenn noch Garantie drauf ist, muesstest Du den Support noch ueberzeugen, dass es kein Linux-spezifisches Problem ist. (Es gibt eigentlich keine solchen, ausser dem USB 3 Timeout, der mittlerweile wohl auch repariert ist. Es ist halt eine beliebte Ausrede im IT Support, dass man nur Win und Mac unterstuetze.)

Aber im Moment kann ich Dir mit libburn keine Argumente liefern, warum er kaputt sein soll. Er spinnt offenbar nur, wenn ihn cdrecord steuert. (Eine Erklaerung habe ich dafuer aber noch nicht.)

Naja könnte ja auch zum DVD Brennen K3b benutzen und für Audio-CD dann XFburn, bin mal wieder hin und her gerissen.

Du koenntest versuchen, K3B das Programm cdrskin als "cdrecord" unterzuschieben. Soviel ich weiss, gibt's da ein Menue, in dem man die absoluten Fileadressen der Backendprogramme einstellen kann.

Die absoluten Fileadresse von cdrskin muesste man so erfahren:

1

which cdrskin

Das muesste dann sowas wie "/usr/bin/cdrskin" ausgeben.

K3B konnte sich leider nie dazu durchringen, cdrskin oder libburn offiziell als Backendprogramme anzuerkennen. (Sie sind schlau genug, growisofs fuer DVD zu nehmen. Aber bei CD kann sie nichts von cdrecord wegbringen.)

englischsprachigen Support (bei CDrecord usw.) kann ich leider nicht dienen..

Der Autor von cdrecord ist Deutscher. http://cdrtools.sourceforge.net/private/

Er ist ein bisschen beruechtigt fuer unfreundliche Antworten. (Drum hat Ubuntu wodim und nicht cdrecord in seinen Paketen.)

Man wird auf jeden Fall vor Kontaktaufnahme ein paar technische Fakten klaeren muessen. ZB. warum es bei libburn so gut klappt.

Naja könnte ja auch zum DVD Brennen K3b benutzen und für Audio-CD dann XFburn

Was fehlt Dir denn bei Xfburn an DVD Features ?

Zu den SCSI Transaktionen in 7994448-cdrskin_log.txt:

Hrmpf. Die Theorie mit SAO ist hiermit gestorben. cdrskin hat SAO bestellt und beginnt bei Adresse -150 zu schreiben, wie es sich fuer diesen Modus gehoert.

Es dauert recht lange, bis das erste Schreibkommando vom Brenner angenommen wird: von Sekunde 1,911369 bis Sekunde 25,694030 des Brennlaufs. Aber dann wird etwa alle 20 Millisekunden ein WRITE Kommando mit jeweils 30576 Bytes ausgefuehrt. (13 Audio Sektoren zu je 2352 Bytes.) Das gibt 1.5 MB/s = 10 x CD Speed.

Der Brenner luegt wirklich im Bezug auf seine SAO Startadresse. Er meldet 0 in den Bytes 12 bis 15 der Antwort von:

READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00
From drive: 20b
00 22 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
      760 us     [ 1908036 ]

nimmt von libburn dann aber doch WRITE fuer Adresse -150 an.

libburn fragt leider die effektiven Schreibparameter nicht mehr vor dem Schreiben ab. Aber in Byte 6 der Antwort von READ TRACK INFORMATION gibt es ein Bit, das Auskunft darueber gibt, ob "Packet/Incremental" bestellt ist. Das muesste bei CD TAO auf 1 gesetzt sein, ist aber 0. Es sieht also wirklich alles wie SAO aus.

Auch die Antwort, die cdrecord bekam:

track info: 00 22 01 01 00 00 4F 01 00 00 00 00 00 00 00 00 00 05 7D A7 00 00 00 00 00 05 7D A7

hat das "Packet/Inc" Bit auf 0. Es war also wohl doch SAO eingestellt.

Zum Thema "resid" sagt libburn leider nix. Wenn der Brenner oder der Kernel keinen Fehler meldet, wird angenommen, dass die Nutzlast auch abgeliefert wurde.

Ich werde heute nochmal die Brennvorbereitungen beider Programme vergleichen, um rauszufinden, wo libburn die richtige Abzweigung genommen hat und cdrecord in den Sumpf fuhr.

Have a nice day ☺

Thomas

Hallo,

vielen herzlichen Dank für eure Hilfe 👍

Habe nun auch mal das Brennprogramm "Brasero" ausprobiert und muss sagen dies gefällt mir auch recht gut, nicht nur weil es funktioniert 😊

Sondern weil es ja auch gleich im Programm mit eine Cover-Erstellungstool integriert ist. also doch fast perfekt für Audio-CD's..

Werde wegen dem cd-record mal Joerg Schilling anschreiben, evtl. hat er ja Interesse an der Fehlersuche bzw. verbesserung seines cdrecords?

Stelle den Thread mal auf gelöst, auch wenn K3b selbst noch nicht funktioniert 😉

PS: Mit dem Support vom Brenner habe ich auch schon Kontakt aufgenommen,mal sehen was dabei raus kommt?

Hi,

da waere es interessant zu sehen, ob der Brasero Logfile Meldungen ueber "BraseroWodim" oder ueber "BraseroLibburn" enthaelt.

Ersteres waere (schon wieder) erstaunlich. Letzteres wuerde zumindest oberflaechlich erklaeren, warum es klappt.

Was cdrecord angeht, habe ich mal die man-Page gelesen: "-VV will show data buffer content in addition." Wenn damit die Nutzlast gemeint ist, braeuchte ich nicht mehr zu raetseln, welche Schreibeinstellungen cdrecord an den Brenner schickt.

Kann ich Dich zu noch einem Versuchslauf ueberreden ?

1

sudo cdrecord -VV -audio *.wav 2>&1 | tee -i ...Zielverzeichnis.../cdrecord_log_vv

Ich schlage diesmal nicht vor, den Ergebnisfile in /tmp zu erzeugen. Das koennte ganz im RAM (bzw. Swap) wohnen. Stattdessen brauchst Du ein Verzeichnis in einem echten Filesystem auf einer Platte mit einigermassen Platz.

Im unwahrscheinlichen Fall, dass das Brennen damit klappt, kann es naemlich sein, dass Dir cdrecord in seinen Meldungen den gesamten CD Inhalt vorliest. Als Hexnummern. Das waeren dann etwas mehr als 3 CDs voll. 3 GB frei im Zielverzeichnis fuer den Logfile waeren gut, damit die Platte nicht ueberlaufen kann. Man kann cdrecord auch mit den Tasten Strg und C abbrechen. Das gaebe natuerlich eine halb zerbrannte nutzlose CD.

Von so einem Riesenlogfile wuerde mich vermutlich nur das erste Megabyte interessieren. Falls es dazu kommt, werde ich Vorschlaege machen, wie man dieses Anfangsstueck abzwacken kann.

Have a nice day ☺

Thomas

Also erstmal ist es keine gute Idee 6 Jahre alte Software zu verwenden.

cdrecord-3.00 ist uralt und seit dem hat sich vieles getan.

In der Zwischenzeit hat z.B. Linux endlich auch ein halbwegs verwendbares feingranulares Rechtesystem bekommen und cdrecord hat in Folge auch Unterstützung dafür eingebaut indem der schon lange für Solaris verfügbare Code nun etwas verallgemeinert wurde.

Als Nebeneffekt kann cdrecord seit dem auch besser warnen wenn bestimmte Rechte fehlen und erklären was dann erwartungsgemäß nicht funktionieren wird.

Die Fehlermeldung (ich beziehe mich dabei auf die ersten beiden Meldungen in denen ich dev=/dev/sr0 und "GOOD STATUS" gelesen habe) selbst weist auf einen Kerneldefekt hin, denn ein ATAPI Laufwerk kennt keinen einzigen SCSI Fehler, bei dem nicht das SCSI Status Bit "CHECK_CONDITION" gesetzt ist. Dies ist übrigens ein Fehler, der sich seit 20 Jahren immer wieder im Linux Kern einschleicht, weil der Kern aus unerklärlichen Gründen den SCSI Status intern um eins nach Rechts shiftet und damit intern keine standardkonformen Bits mehr hat. Wenn wieder mal ein Anfänger am Kern bastelt, dann wird gelegentlich der notwendige Linksshift vor der Rückgabe des Wertes ins Userland beseitigt.

Dieses Problem könnte durch eine fehlerhafte Nutzung (siehe Warnung von cdrecord zum dev= Parameter) verursacht worden sein.

Linux hat mehr als einen Treiber für CD-ROM Laufwerke und nicht alle konkurrierenden Treiber funktionieren korrekt. Darum wird ja auch davon abgeraten, die /dev/* Syntax für dev= zu verwenden, denn mit dieser Syntax zwingt man die libscg in vielen Fällen einen nicht funktionierenden Treiber zu verwenden obwohl ein funktionierender Treiber verfügbar ist.

Also

1) Neue Version von cdrtools verwenden - aktuell ist 3.02a05

2) dev=/dev/sr0 erzeugt Probleme! Daher (bei nur einem CD-ROM LW dev= ganz weglassen oder wenigstens der Doku folgen und die offizielle CAM Standard basierte SCSI Adressierung verwenden). Mit CAM Standard dev= Parametern (oder im Automatikmodus wo das LW gesucht wird) sucht sich libscg den besten der verfügbaren Treiber aus und vermeidet so Probleme durch die Verwendung von als problematisch bekannten Treibern.

Bleibt das Problem, dann liegt ein Kernel Defekt vor, der beseitigt werden muß.

3) Manchmal werden diese Art Kenelfehler übrigens durch hald oder seine Nachfolger ausgelöst, denn diese Software greift auf das Laufwerk in einer Weise zu, die während des Brennens verboten ist. Die Auswirkungen dieser Schadsoftzware (hald, udev, systemd) kann man bei CDs (bei DVDs und BluRays funktioniert das leider nicht) durch die Verwendung der Option -raw96r verringern, weil dann selbst der Brenner nicht mehr weis was er tut und es der bekannten Schadsoftware damit erschwert wird illegale Lesezugriffe während des Brennens abzusetzen. Durch die genannte Schadsoftware können nahezu unerklärbare Meldungen provoziert werden. Der Fehler in dieser SW ist übrigens durch das Ignorieren des Statusübergansgraphen der Brenner ausgelöst. Die Schadsoftware nimmt fäschlicherweise an, daß ein Übergang von NOT READY → READY bedeutet, daß danach vom LW gelesen werden darf. Wärend des Brennens sind von konkurrierender Software aber nach SCSI Standard nur die SCSI Kommandos "Inquiry", "TEST UNIT READY" und "REQUEST SENSE" zulässig. Alle anderen Kommandos dürfen in dieser Zeit nur vom Brennprogramm abgesetzt werden.

Die eine Meldung mit "illegal address for write" deutet auf einen Buffer underrun hin, der durch die oben beschriebenen Probleme in der Schadsoftware (hald, udev oder systemd) verursacht werden kann, denn das mindeste was ein illegaler Lesezugriff bewirkt ist ein durch Seek und Read verursachter starker Zeitverzug.

Von wodim kann ich nur abraten, denn es handelt sich dabei um einen im Mai 2004 von Debian erzeugten Fork, in dem im Jahre 2004 diverse SCSI Bugs eingebaut wurden und aus dem der funktionierende Original DVD Treiber durch eine Bastellösung ersetzt wurde. In Wodim gab es nie ernsthafte Versuche die ca. 100 im Debian Bugtacking dokumentierten Probleme zu beseitigen, seit Mai 2007 gab es nur noch Schreibfehlerkorrekturen. Du hast ja mit einer 6 Jahre alter cdrecord Version gearbeitet, mit wodim bekämst Du 11 Jahre alte SW die nur um SCSI Bugs erweitert wurde.

Andere CD/... Brennsoftware ist nicht mit den Features von cdrecord ausgestattet und wird typischerweise seit ca. 5 Jahren nicht mehr gewartet (z.B. cdrdao und DVD+RW-Tools).

Hallo,

vielen Dank für deine schnelle Antwort 👍

Ja mein System ist nicht das neuste, da ich ja eine LTS Version nutze und will/wollte warten bis zur nächsten LTS Version die hoffentlich im Mai erscheint.

Habe mal bei den PPA gesucht und und dies gefunden:

https://launchpad.net/~brandonsnider/+archive/ubuntu/cdrtools

er bietet für Ubuntu als "neuste Version" cdrecord 3.01a21, with the help of Jorg Schilling ... an.

Habe mir dies mal installiert und damit gleich mal getestet..

1
2
3
4

cdrecord -version
Cdrecord-ProDVD-ProBD-Clone 3.01a28 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling

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

Funktioniert leider auch nicht, log ist im Anhnag.

Tja dann werde ich wohl damit leben müssen, aber solange die anderen funktionieren kann ich doch mit leben und werde dann das ganze nochmals testen wenn ich im Mai dann hoffeltich die neue Kubuntu LTS version bekomme..

Du hast auch hier mit dem Log deutlich gemacht, daß die vermutliche Ursache die Schadsoftware von Linux (hald, udev oder systemd) ist, denn der Abbruch kam (wie in meiner vorigen Antwort erklärt) nach einem NOT READY → READY Übergang.

Es ist also wie schon vorher vermutet ein Problem das durch defekte Linux System Software ausgelöst wird und für das es ja mit -raw96r einen Workaround gibt.

Du mußt also keine schlechtere andere Software verwenden. Wie vielleicht bekannt sein dürfte sind die Audio Eigenschaften von cdrecord und cdda2wav unübertroffen. Da hat sich übrigens im letzten Jahr noch einiges bei cdda2wav getan.

- Deutliche Verbesserung beim paranoia Lesemodus

- Support für direkte Audiowiedergabe mit Pulsaudio neu

Hi Joerg,

Deine Theorien erklaeren nicht, warum es mit libburn ohne Probleme klappt. In https://media-cdn.ubuntu-de.org/forum/attachments/03/01/7994448-cdrskin_log.txt kann man sehen, welche SCSI Kommandos geschickt werden und welche Beschwerden der Brenner dazu meldet.

Das sind gerade mal beim ersten WRITE10, 20+ Sekunden lang:

+++ key=2  asc=04h  ascq=08h = LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS

Nach SYNCHRONIZE CACHE bei TEST UNIT READY fuer etwa 1 Sekunde

+++ key=2  asc=04h  ascq=07h = LOGICAL UNIT NOT READY, OPERATION IN PROGRESS

Und ganz am Anfang bei START/STOP UNIT mit Load/Eject Bit:

+++ key=5  asc=24h  ascq=00h = INVALID FIELD IN CDB

Das, weil es offenbar ein Brenner ohne Schubladenmotor ist.

Schoener kann es unter diesen Umstaenden kaum laufen. Nur weiss ich auch nicht, in welche Pfuetze ich aus Versehen nicht stapfe bei diesem Brenner.

libburn bekommt keine SCSI Fehler von ihren MODE SELECT Befehlen. cdrecord bekommt ein paar. Vielleicht mag der Brenner nicht, was Du ihm da (probeweise ?) schicken laesst.

libburn zeigt den .resid Wert zwar nicht an. Aber das Ergebnis deutet darauf hin, dass alles sauber uebertragen wurde.

SCSI Status Bit "CHECK_CONDITION"

Bei Linux erwarte ich das Vorhandensein von SCSI Sense Data wenn nach ioctl(SG_IO): sg_io_hdr_t.sb_len_wr > 0

Da koennen die Kernelhacker Flags shiften soviel sie wollen.

Have a nice day ☺

Thomas

Hallo,

schily schrieb:

Es ist also wie schon vorher vermutet ein Problem das durch defekte Linux System Software ausgelöst wird und für das es ja mit -raw96r einen Workaround gibt.

vielen dank das du dich hier im Thread bemeldest hast 👍

Dann muss ich mal schauen ob ich den Workaround finde mit meinem schlechtem Englisch.

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