ubuntuusers.de

Kriegt der seinen Strom ueber USB ? (Ich hab mal von einem gehoert, der hatte zwei USB Kabel. Eins nur fuer extra Strom.)

scdbackup schrieb:

Kriegt der seinen Strom ueber USB ? (Ich hab mal von einem gehoert, der hatte zwei USB Kabel. Eins nur fuer extra Strom.)

Das wäre aber nicht Standardkonform , soweit ich das weiß. Es gab/gibt aber Kabel mit drei Anschlüssen so das man am Rechner zwei Ports belegt . Und einer wie Üblich an der Platte oder sonstigem. Genauso Geräte die Spannung rückwärts in den Rechner einspeisen. Gabs mal nen Artikel in der CT dazu.

https://media-cdn.ubuntu-de.org/forum/attachments/00/03/8036213-IMG_0222.JPG

Hallo,

ja am Brenner sind 2 Kabel, ein Dünneres für die STromversorgung, ein Dickeres für die Datenübertragung.

Habe mal ein Bild angehängt vom Verkauf...

Hi,

das milde Gruseln, das Eure Fotos bei mir ausloesen, erinnert mich wieder daran, warum ich mir dicke Brenner kaufe und sie in dicke USB-Boxen mit eigenen Netzteilen stecke.

Das ist zwar vom Strom her vermutlich etwas unguenstiger, weil die Netzteile warm werden und im Standby durchaus mal 2 oder 3 Watt ziehen koennen. Es gibt bessere Netzteile zu kaufen. Mir sind schon zwei abgeraucht. Beim ersten habe ich das Glueck gehabt, dass ich noch ein lebendes mit gleichem box-seitigem Stecker hatte. Da konnte ich die Pins durchmessen und feststellen, wo die 12 V anliegen. Schere und Luesterklemme machen dann die Steckertransplantation komplett.

Nun habe ich Zettel, auf denen die Pinbelegung aufgeschrieben ist.

Die neuen Netzteile werden deutlich weniger warm als die Originale, die mit den USB Boxen kamen. Kosten aber etwa 20 Euro das Stueck und die Luesterklemme macht einen haesslichen Knoedel im Kabel.

Ich denke ueber ein zentrales Netzteil fuer alle drei USB Boxen nach. Da saehe das Kabel dann noch interessanter aus als Eure.

Have a nice day ☺

Thomas

So, da so schnell keine Tests kommen werden, habe ich erstmal eine normale Release der Schily Tools mit den cdrtools und der neuen Option scgopts=ignore-resid veröffentlicht.

Eine passende cdrtools Release kommt auch bald.

Hallo,

so kann dann wieder weiter testen, habe meinen Brenner wieder im einsatz. Da er unter Windows einwandfrei funktioniert (keine Garantie zum Umtausch).

Habe mir nun wegen den Kernelbugs und meiner alten Kernelversion ein komplett frisches system aufgesetzt und die Test können weiter gehen 😊

So beginne nun in diesem Posting mit folgendem Sytsem und erstmal USB2, im nächsten Post kommt dann der gleiche Test mit USB3...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

OS Information:
  OS:  "Netrunner" "17" Kubuntu 15.10 Wily Werewolf
  System:  Linux 4.2.0-25-generic x86_64
  KDE-Plasma:  5.5.3
  QT-Version:  5.5.1

CPU Information:
  Processor (CPU):   Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
  Speed:  3 729,11 MHz
  Cores:  8
  
Memory Information:
  Total memory (RAM):  7,7 GiB
  Free memory:  3,5 GiB (+ 2,8 GiB Caches)
  Free swap:  2,8 GiB

USB3-Brenner:
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]

1. USB2 Versuch (erfolgreich) mittels:

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

2. USB2 Versuch ( nicht erfolgreich) mittels:

sudo wodim -V dev=/dev/sr0 -audio *.wav 2>&1 | tee -i /tmp/wodim_usb2_log.txt

3. USB2 Versuch (erfolgreich) mittels:

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

4. USB2 Versuch (erfolgreich) mittels:

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

Hallo,

hier nun die Testergebnisse mit USB3.

wodmin habe ich nicht mehr getstet, wenn es auf USB2 schon nicht geht wird es bei USB3 wohl auch nicht gehen 😊

1. USB3 Versuch (erfolgreich) mittels:

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

2. USB3 Versuch (erfolgreich) mittels:

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

3. USB3 Versuch (erfolgreich) mittels:

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

Das nächste Problem wäre dann ja wohl noch dem K3b diese binary unter zu schieben das er es auch sauber benutzt und somit auch per Gui das ganze funktioniert. Im Launchpad PPA ist ja leider auch für cdrecord und dem Ubuntu 15.10 noch nichts drinn, und die anderen Binary sind ja auch schon 64 Wochen alt wenn ich das richtig gesehen habe...

Hi,

das wodim Log zeigt den bekannten Fehlschlage, weil .resid nicht 0 ist und wodim dann versucht, den WRITE Befehl zu wiederholen.

burnfree und raw96r waren, wenn ich mich recht erinnere, Versuchsballons als die Sache mit dem .resid noch nicht erkannt war.

Joerg haette gerne, dass Du sein neues cdrecord mit Option

scgopts=ignore-resid

ausprobierst. Ich kann Dir zur Not wieder ein cdrecord Binary auf Debian 8 herstellen, wenn man mir die URL des Tarballs und - falls von cdrtools abweichend - eine Bauanleitung nennt.

Mich interessiert nur noch, ob der Betrieb des Brenners an USB2 (mit allen beiden Strippen) verhindert, dass Brennlaeufe wegen host_status 7 abbrechen. Wenn Du Dir mit genuegend erfolgreichen Laeufen Gewissheit verschafft hast, kannst Du ja mal in USB3 einstoepseln und schauen, ob es dann ab und zu mal schiefgeht.

Versuchslaeufe mit Option -V sind erstmal nicht mehr noetig. Ohne diese Option werden die Logs deutlich kleiner.

Have a nice day ☺

Thomas

Hallo Thomas,

oh ich she wir haben uns überschniten, die test am USB3 sind ja auch schon über deinem Postung gelandet 😊

selbstverständlich würde ich die neue Version von cdrecord testen, wenn ich eine binary bekomme.

Natürlich würde ich mich auch freuen wenn ich durch meine Test euch etwas mehr helfen könnte und Ihr aus diesen auch eure Tools verbessern könnt, in der Hoffnung das diese dann auch irgenwann mal per PPA oder so für Leute wie mich zu haben sind.

Ist ja eigentlich schon etwas früstierend wenn man wie ich nun ein neues Linuxsystem aufsetzt und man immer noch nicht mit den mitgebrachten Boradmittels brennen kann.

Aber zumindest habt Ihr meinen größten Respekt für eure Arbeit und Zeit die ihr investiert. Und auch das ihr dem nörmalen "kleinem" Volk auch noch Hilfe zukommen lasst 👍 😀

PS:

Zu den USB-Anscchlüssen habe USB3 und USB2 direkt nebeneinander liegen, so das ich im ersten Test die Stromversogung über USB3 machte und die Daten über USB2 liefen.

Im zweiten Test USB3 war es natürlich anderst herum Strom kam von USB2 Daten flossen über USB3 😉

Hi,

Das nächste Problem wäre dann ja wohl noch dem K3b diese binary unter zu schieben

Soviel ich weiss kann man bei K3B den Pfad zum "cdrecord" einstellen. Du solltest aber fubude-3 nehmen, weil das Dich und K3B nicht mit diesen Meldungen hier zuquasselt:

cdrecord-fubude: sg_io.resid = 30576

https://media-cdn.ubuntu-de.org/forum/attachments/00/01/8001663-cdrecord-fubude-3.gz

Du kannst natuerlich auch die Ubuntu Versionen von "cdrecord" und "wodim" suchen lassen

which cdrecord wodim

und diese Files (zB. beide gefunden in /usr/bin/) durch fubude-3 ersetzen

mv /usr/bin/cdrecord /usr/bin/cdrecord-ubuntu
mv /usr/bin/wodim /usr/bin/wodim-ubuntu
cp ...Pfad.../cdrecord-fubude-3 /usr/bin/cdrecord
cp ...Pfad.../cdrecord-fubude-3 /usr/bin/wodim

die test am USB3 sind ja auch schon über deinem Postung gelandet

Wir brauchen eine breitere statistische Grundlage.

Gesucht wird das charakteristische Muster eines Effekts, der bei den frueheren Versuchen grob einmal pro drei Versuche auftrat. Da sind sechs Erfolge in Reihe nur ein Zeichen, dass der Effekt ziemlich fluechtig ist.

Strom kam von USB2 Daten flossen über USB3

Also ich haette gerne den Kontrast zwischen reinem USB 2 und Datenkabel an USB 3 getestet. Wenn das USB 3 Schluckauf hat, koennte das sehr wohl zu Stromausfall im Brenner fuehren. Da geht natuerlich auch dessen USB Kontroller aus und das koennte dann im Kernel am USB 2 Anschluss eine Fehlermeldung ausloesen.

Ist ja eigentlich schon etwas früstierend wenn man wie ich nun ein neues Linuxsystem aufsetzt und man immer noch nicht mit den mitgebrachten Boradmittels brennen kann.

Was wir wohl nie rausfinden werden ist, warum Dein Kernel darauf besteht, bei jedem WRITE zu melden, dass er die Daten nicht beim Brenner habe abliefern koennen. Was ja offensichtlich nicht stimmt.

Das verhindert leider, dass K3B mit seinem voreingestellten Brennprogramm Erfolg hat. Xfburn und Brasero (mit libburn plugin) funktionieren ja ... bis auf vermutlich den host_status 7 Fehler.

Die Tatsache, dass der Brenner mit zwei USB Kabeln am Computer haengt sollte dem Kernel eigentlich garnicht bewusst sein. Ich vermute, er sieht zwei verschiedene Geraete.

selbstverständlich würde ich die neue Version von cdrecord testen, wenn ich eine binary bekomme.

Joerg ? URL ? Besondere Anleitung noetig ?

Have a nice day ☺

Thomas

Ein unmodifiziertes k3b sucht cdrecord in /opt/schily/bin und zieht das (wenn vorhanden) auch z.B. bei DVDs gegenüber growisofs vor.

Ich befürchte allerdings, das Debian das mal wieder so modifiziert hat, daß eine Selbsthilfe gegen die wodim Probleme nicht so einfach möglich ist.

Daß Wodim Probleme macht, sollte eigentlich klar sein, denn daran wurde seit 10 Jahren nichts mehr getan und nachdem dieser Fork im Mai 2004 auftauchte, wurde er nicht gegen das Original aktualisiert und im SCSI Transport wurden aus mangelndem Sachverstand diverse Fehler eingebaut.

Wenn man bedenkt, daß cdrecord (der veröffentlichte Quellcode) am 4. Februar 20 Jahre alt wird, sollte auch klar sein, daß man mit wodim halt nur 40% des heutigen Originals erwarten kann.

Interessant für unser aktuelles Problem wäre übrigens, ob man bei k3b (ähnlich, wie dies z.B. bei xcdroast möglich ist) auch manuell zusätzliche Optionen hinterlegen kann, wie z.B. scgopts=ignore-resid. Sollte das nämlich nicht helfen, denn müßtest Du ein Shell Skript bauen, das "cdrecord" heißt und intern:

1

exec cdrecord.bin scgopts=ignore-resid "$@"

aufruft.

Hallo Joerg,

danke für den Hinweis mit dem eigene Verzeichnis 👍

Habe das man so ins /opt/schily/bin kopiert, klappt wunderbar wie es nach den Screenshost aussieht.

Auch das mit den Parameter habe ich da eingetragen, werde dann morgen das ganze testen, habe heute leider keine Zeit.

Muss/soll ich irgednwie noch spezielle logfiles erstellen?

Hallo Thomas,

natürlich werde ich das auch npchmals mit reinem USB2 und reinem USB3 testen und dann hier berichten.

hier willste ja dann keine Test mehr mit der Option "-V" , oder doch 😉

Hi,

ja, keine Option -V in K3B oder mit weiteren Kommandozeilenlaeufen.

Die neue Option

scgopts=ignore-resid

solltest Du erst eintragen, wenn Du das neue cdrecord von Joerg hast.

cdrecord-fubude-3 beklagt sich bei mir

cdrecord: Bad Option: scgopts=ignore-resid.

und verweigert die Arbeit.

Have a nice day ☺

Thomas

scdbackup schrieb:

Die neue Option

scgopts=ignore-resid

solltest Du erst eintragen, wenn Du das neue cdrecord von Joerg hast.

Ja du hast recht, geht wirklich nicht mit der lesten Version von Dir Kompiliert. Aber Sie läuft nun auch im K3b erfolgreich dazu nochmals "besten Dank" 👍

Habe jetzt mal noch 2-3 testläufe gemacht mit K3b, alles mal auf "auto" stehen gelassen also auch die Brenngeschwindigkeit usw. logs sehen dann in dieser Art aus (USB3):

  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
179
180
181
182

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.3
KDE Version: 4.14.15
QT Version:  4.8.6
Kernel:      4.2.0-27-generic

Used versions
-----------------------
cdrecord: 3.2a05-fubude-3

cdrecord
-----------------------
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: 54
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
pregap1: -1
Track 01: audio   32 MB (03:15.62) no preemp swab copy
Track 02: audio   37 MB (03:40.10) no preemp swab copy
Total size:       69 MB (06:55.73) = 31180 sectors
Lout start:       70 MB (06:57/55) = 31180 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: 328669
Starting to write CD/DVD/BD at speed 24 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:   23.001s (00:00:23.001)
Writing pregap for track 1 at -150
Starting new track at sector: 0
Track 01:    0 of   32 MB written.
Track 01:    1 of   32 MB written (fifo 100%)   8,1x.
Track 01:    2 of   32 MB written (fifo 100%) [buf  99%]   8,3x.
Track 01:    3 of   32 MB written (fifo 100%) [buf  99%]   8,5x.
Track 01:    4 of   32 MB written (fifo 100%) [buf 100%]   8,3x.
Track 01:    5 of   32 MB written (fifo 100%) [buf 100%]   8,5x.
Track 01:    6 of   32 MB written (fifo 100%) [buf  99%]   8,2x.
Track 01:    7 of   32 MB written (fifo 100%) [buf  99%]   8,5x.
Track 01:    8 of   32 MB written (fifo 100%) [buf 100%]   8,3x.
Track 01:    9 of   32 MB written (fifo 100%) [buf 100%]   8,5x.
Track 01:   10 of   32 MB written (fifo 100%) [buf  99%]   8,2x.
Track 01:   11 of   32 MB written (fifo 100%) [buf  99%]   8,5x.
Track 01:   12 of   32 MB written (fifo 100%) [buf 100%]   8,2x.
Track 01:   13 of   32 MB written (fifo 100%) [buf 100%]   8,5x.
Track 01:   14 of   32 MB written (fifo 100%) [buf  99%]   8,2x.
Track 01:   15 of   32 MB written (fifo 100%) [buf  99%]   8,5x.
Track 01:   16 of   32 MB written (fifo 100%) [buf 100%]   8,2x.
Track 01:   17 of   32 MB written (fifo 100%) [buf 100%]   8,4x.
Track 01:   18 of   32 MB written (fifo 100%) [buf  99%]   8,2x.
Track 01:   19 of   32 MB written (fifo 100%) [buf  99%]   8,4x.
Track 01:   20 of   32 MB written (fifo 100%) [buf 100%]   8,2x.
Track 01:   21 of   32 MB written (fifo 100%) [buf 100%]   8,4x.
Track 01:   22 of   32 MB written (fifo 100%) [buf  99%]   8,1x.
Track 01:   23 of   32 MB written (fifo 100%) [buf  99%]   8,4x.
Track 01:   24 of   32 MB written (fifo 100%) [buf 100%]   8,2x.
Track 01:   25 of   32 MB written (fifo 100%) [buf 100%]   8,4x.
Track 01:   26 of   32 MB written (fifo 100%) [buf  99%]   8,1x.
Track 01:   27 of   32 MB written (fifo 100%) [buf  99%]   8,4x.
Track 01:   28 of   32 MB written (fifo 100%) [buf 100%]   8,1x.
Track 01:   29 of   32 MB written (fifo 100%) [buf 100%]   8,4x.
Track 01:   30 of   32 MB written (fifo 100%) [buf  99%]   8,1x.
Track 01:   31 of   32 MB written (fifo 100%) [buf  99%]   8,4x.
Track 01:   32 of   32 MB written (fifo 100%) [buf 100%]   8,1x.
Track 01: Total bytes read/written: 34508544/34508544 (14672 sectors).
Starting new track at sector: 14672
Track 02:    0 of   37 MB written.
Track 02:    1 of   37 MB written (fifo 100%)   8,1x.
Track 02:    2 of   37 MB written (fifo 100%) [buf  99%]   8,3x.
Track 02:    3 of   37 MB written (fifo 100%) [buf  99%]   8,5x.
Track 02:    4 of   37 MB written (fifo 100%) [buf 100%]   8,3x.
Track 02:    5 of   37 MB written (fifo 100%) [buf 100%]   8,5x.
Track 02:    6 of   37 MB written (fifo 100%) [buf  99%]   8,2x.
Track 02:    7 of   37 MB written (fifo 100%) [buf  99%]   8,5x.
Track 02:    8 of   37 MB written (fifo 100%) [buf 100%]   8,3x.
Track 02:    9 of   37 MB written (fifo 100%) [buf 100%]   8,5x.
Track 02:   10 of   37 MB written (fifo 100%) [buf  99%]   1,9x.
Track 02:   11 of   37 MB written (fifo 100%) [buf  99%]  12,7x.
Track 02:   12 of   37 MB written (fifo 100%) [buf 100%]  12,3x.
Track 02:   13 of   37 MB written (fifo 100%) [buf 100%]  12,7x.
Track 02:   14 of   37 MB written (fifo 100%) [buf  99%]  12,3x.
Track 02:   15 of   37 MB written (fifo 100%) [buf  99%]  12,7x.
Track 02:   16 of   37 MB written (fifo 100%) [buf 100%]  12,3x.
Track 02:   17 of   37 MB written (fifo 100%) [buf 100%]  12,7x.
Track 02:   18 of   37 MB written (fifo 100%) [buf  99%]  12,3x.
Track 02:   19 of   37 MB written (fifo 100%) [buf  99%]  12,7x.
Track 02:   20 of   37 MB written (fifo 100%) [buf 100%]  12,3x.
Track 02:   21 of   37 MB written (fifo 100%) [buf 100%]  12,6x.
Track 02:   22 of   37 MB written (fifo 100%) [buf  99%]  12,2x.
Track 02:   23 of   37 MB written (fifo 100%) [buf  99%]  12,6x.
Track 02:   24 of   37 MB written (fifo 100%) [buf 100%]  12,3x.
Track 02:   25 of   37 MB written (fifo 100%) [buf 100%]  12,6x.
Track 02:   26 of   37 MB written (fifo 100%) [buf  99%]  12,2x.
Track 02:   27 of   37 MB written (fifo 100%) [buf  99%]  12,6x.
Track 02:   28 of   37 MB written (fifo 100%) [buf 100%]  12,2x.
Track 02:   29 of   37 MB written (fifo 100%) [buf 100%]  12,5x.
Track 02:   30 of   37 MB written (fifo 100%) [buf  99%]  12,2x.
Track 02:   31 of   37 MB written (fifo 100%) [buf  99%]  12,5x.
Track 02:   32 of   37 MB written (fifo 100%) [buf 100%]  12,2x.
Track 02:   33 of   37 MB written (fifo 100%) [buf 100%]  12,5x.
Track 02:   34 of   37 MB written (fifo 100%) [buf  99%]  12,1x.
Track 02:   35 of   37 MB written (fifo 100%) [buf  99%]  12,5x.
Track 02:   36 of   37 MB written (fifo 100%) [buf 100%]  12,1x.
Track 02:   37 of   37 MB written (fifo 100%) [buf 100%]  12,5x.
Track 02: Total bytes read/written: 38826816/38826816 (16508 sectors).
Writing  time:   70.731s (00:01:10.731)
Average write speed   8,7x.
Min drive buffer fill was 99%
Fixating...
Fixating time:    8.692s (00:00:08.692)
cdrecord: fifo had 1156 puts and 1156 gets.
cdrecord: fifo was 0 times empty and 1091 times full, min fill was 98%.

cdrecord command:
-----------------------
/opt/schily/bin/cdrecord -v gracetime=2 dev=/dev/sr0 speed=24 -sao driveropts=burnfree textfile=/tmp/qt_temp.CO2612 -overburn -useinfo -audio /tmp/kde-egle/k3b_audio_0_01.inf /tmp/kde-egle/k3b_audio_0_02.inf

- Wieviele Testläufe wilst du haben?

- und von jedem einzeln die Logausgabe?

Hi,

- Wieviele Testläufe wilst du haben?

Soviele wie sich bei Dir sinnvollerweise ergeben. Mach Dir eine Strichliste fuer USB 2 und - wenn es langweilig wird mit dem Erfolg - auch eine fuer USB 3.

Wenn Du ein Dutzend Erfolgsstriche beisammen hast, kannst Du mal einen Zwischenbericht geben. Wenn's einen interessanten Unfall gibt, laesst Du uns natuerlich sofort teilhaben.

- und von jedem einzeln die Logausgabe?

Die Logs interessieren nur bei Fehlschlaegen. Genaugenommen interessiert dann erstmal nur, ob's der host_status 7 war, oder noch was anderes. (Mit einem Medium Error muss man immer mal rechnen.) Ich muss mir das dann genauer ansehen.

Die Erfolge interessieren nur als Striche auf der Liste, um das Verhaeltnis von Erfolg zu Misserfolg berechnen zu koennen.

Wenn jetzt langweiligerweise garkeine Fehlschlaege mehr passieren, faellt der Verdacht auf die Stecker der Kabel. Da klebte nicht zufaellig eine tote Fruchtfliege drin ? Siehe Originalaufnahme des ersten dokumentierten insektoiden Computerfehlers von 1947, "Motte im Relay": https://en.wikipedia.org/wiki/File:H96566k.jpg

Have a nice day ☺

Thomas