ubuntuusers.de

Hallo allerseits,

vorneweg, ich bin in den Tiefen der Debian-Paketverwaltung nicht komplett Sattelfest. Sollte ich also falsche Angaben machen, bitte ich um Berichtigung. Ich bin generell offen für Vorschläge, wie ich was besser machen könnte. Ich weiß auch, daß ich mir die cdrtools einfach nebenher kompilieren könnte, aber ich will das über die Paketverwaltung regeln. 😉

Wie man in diesem Thread http://forum.ubuntuusers.de/topic/paketverwaltung-wie-ein-paket-entfernen-ohne-/ sieht, hatte ich vor, die Original cdrtools (cdrecord, mkisofs, cdda2wav) über die Paketverwaltung neben cdrkit (wodim, genisoimage, icedax), was mit Ubuntu ausgeliefert wird, zu instalieren. Die cdrtools "leihe" ich mir dabei von grml aus → http://deb.grml.org/pool/main/s/schilyutils/.

Das ganze, weil zu wodim und Konsorten zig Abhängigkeiten bestehen, ich aber vom Fork nicht gerade viel halte. Also möchte ich alle Möglichkeitn offen halten, ohne das es zu gröberen Problemen mit der Paketverwaltung kommt.

Normalerweise ist die paralelle instalation via Paketmanagement nicht so einfach möglich, da die debs von wodim, genisoimage und icedax Links von /usr/bin/cdrecord, /usr/bin/mkisofs und /usr/bin/cdda2wav auf ihre Binarys legen, und u.a. deshalb verhindern, daß die cdrtools-debs ihre Binarys dort plazieren können.

Um das zu umschiffen, hab ich mir mit sudo apt-get source cdrkit erstmal das Source-Paket geladen. Dann in den Files, die das Bauen eines Debs steuern, wenn man mit dpkg-buildpackage -rfakeroot baut, ein paar Dinge verändert.

• die Versionsnummer raufgesetzt von 1.1.9 auf 1.2.1, damit das modifizierte cdrkit nicht gleich bei einem Update überschrieben wird.

• die obengenannten Links verändert. Die Pakete legen jetzt z.B. /usr/bin/cdrecord.wodim an und nicht mehr /usr/bin/cdrecord

• die Replaces: und Provides: "frisiert", so daß keine Konflikte mehr gemeldet werden.

Dann hab ich mit dpkg-buildpackage -rfakeroot die Pakete gebaut.

Diese neuen cdrkit-debs hab ich mir mit den cdrtools-deb in ein Verzeichnis gelegt, ein kleines Script geschrieben, daß zuerst die modifizierten cdrkit-debs und dann die cdrtools-deb instaliert. Läuft soweit durch und scheint auch --bisher-- zu funktionieren. apt-get check liefert keine Probleme.

Die Pakete funktionieren auf Jaunty und auf Karmik in einer VM ☺

Momentaner Zustand:

• beim aufruf von cdrecord, mkisofs und cdda2wav im Terminal melden sich die cdrecord-Binarys

• bei wodim, genisoimage, icedax, cdda2mp3, cdda2ogg werden die cdrkit-Binarys genommen

Das bedeutet also, nur Programme, die explicit wodim, genisoimage oder icedax aufrufen, benutzten das cdrkit, alle anderen die cdrtools. So war es beabsichtigt und scheint zu klappen.

Mein Problem jetzt:
ich hab das alles nur in einer Virtuellen Instalation gemacht und getestet, da ich momentan keine Hardware für eine Ubuntu-Testinstalation zur verfügung hab. Das heist, ich hab damit noch nichts echtes gebrannt!

Das werd ich aber die Tage nachholen und wenn interesse besteht, kann ich natürlich auch die Pakete zur verfügung stellen. Gepackt mit allen debs und dem Script ist es ein *.tar.bz2 mit über 2 MB 😉

Update 1

ich hab jetzt mit einem Ubuntu Jaunty 9.04 in einer Virtualbox mit k3b auf dem CD-Brenner des Host-Systems eine Daten-CD fehlerfrei gebrannt. In k3b musste ich erstmal die Suchpfade für cdrecord und mkisofs eingeben. Macht man das nicht, wird weiterhin wodim und genisoimage benutzt.

Ich vermute mal das Zeugs funktioniert, deshalb hänge ich die Dateien für Mutige oder Neugierige mal an.

Wer keine Angst um sein System hat (oder ein aktuelles Backup und gerne testet), kanns ja mal probieren.

• einfach alle Dateien in einen Ordner Speichern, die Namen dürfen nicht verändert werden

• in diesen Ordner wechseln und das Script install_cdrtools mit sudo ausführen

• evtl. in den Brennprogrammen die Pfade anpassen

• oder via Terminal brennen

Über Testberichte oder Anmerkungen oder Ähnliches freu ich mich ☺

Disclaymer: Das Testen geschieht auf eigenen Gefahr. Testen sollten bitte nur erfahrene Benutzer, die sich zu helfen wissen. Ich übernehme auch keine Verantwortung für explodierende Festplatten, Feuerwerke im PC-Gehäuse oder davonlaufende Tastaturen, die sich durch das Instalieren dieser Pakete einstellen könnten. 😉

Update 2

kleines Problem beim Script behoben, die schilylibs müssen vor den anderen cdrtools instaliert werden.

Update 3

Hab die angehangenen Dateien wieder gelöscht und versuche mich an einer einfacheren Lösung, geb demnächst bescheid, wie es weitergeht und ob ich das so hinbekomme, wie ich mir das vorstelle:

Nämlich, die cdrtools sollen die cdrkit vollständig ersetzen. Inklusive Links dann von wodim nach cdrecord. Also das ganze genau entgegengesetzt zum default-Zustand ☺

Update 4

So, nu isses soweit:

ich hab neue Pakete gebaut und ein neues Script geschrieben. Die Pakete wurden so gebaut, daß (zumindest auf meinem System) keine Konflikte in der Paketverwaltung auftreten. Es ist für 32-Bit-Ubuntu.

Die cdrtools ersetzten also cdrkit komplett.

Es werden Links von wodim auf cdrecord, von icedax auf cdda2wav und von genisoimage auf mkisofs gesetzt, so daß auch Brennprogramme, die ausdrücklich wodim aufrufen, trotzdem cdrecord verwenden.

Das Script installiert die cdrtools von J.Schiling und kann diese Instalation auch wieder rückgänging machen und den Urzustand wieder herstellen.

Das Paket entpacken:

tar -xvzf cdrtools_for_ubuntu-2.01.01.1a57.tar.gz

es ist eventuell nötig, den Besitzer des Ordners und der enthaltenen Dateien anzupassen (s. chown):

sudo chown -R deinbenutzername:deinebenutzergruppe cdrtools_for_ubuntu      # bei mir wären das z.B. antiqua:antiqua

in das neue Verzeichnis wechseln:

cd cdrtools_for_ubuntu

das Script ausführbar machen:

chmod +x ./install_cdrtools

das Script benötigt root-Rechte, also bitte mit sudo aufrufen:

die help des Scriptes aufrufen:

sudo ./install_cdrtools help

zum installieren der cdrtools:

sudo ./install_cdrtools install

zum deinstallieren der cdrtools und um das Ubuntu-cdrkit wieder zu installieren:

sudo ./install_cdrtools purge

Die Pakete wurden auf einem Ubuntu Jaunty (9.04) 32-Bit gebaut und getestet. Mit k3b braucht man jetzt keine zusätzlichen Einstellungen mehr vornehmen. Brasero tuts hier auch ohne zu meckern.

Das ganze müsste auch mit Karmik (9.10) und sogar auf der Lucid-alpha (10.04) funktionieren. Das hab ich allerdings noch nicht getestet.

Ich würde mich über Verbesserungsvorschläge oder generell über Feedback freuen.

Schön wäre auch eine Version für Ubuntu 64-Bit.

Damit könnte ich dann meinen Brenner von LG zum Laufen bringen...

Edit: Hängt vielleicht auch von GRML ab... Und entschuldige, wenn man hier nicht rein posten sollte.

Rockfirm Bear schrieb:

Schön wäre auch eine Version für Ubuntu 64-Bit.

ja, das wäre in der Tat schön. Ich hab aber leider kein 64-bittiges Ubuntu zur Hand. Eventuell komm ich da demnächst mal dazu...

Damit könnte ich dann meinen Brenner von LG zum Laufen bringen...

Edit: Hängt vielleicht auch von GRML ab...

ich hab mir von grml nur die Sourcen besorgt und daran nichts geändert. Was ich angepasst habe, sind die Configs für den Bau der Debs. Die müssten sich aber vermutlich problemlos auch auf 64-Bit bauen lassen. Und wie schon gesagt, evtl. komm ich demnächst dazu.

Und entschuldige, wenn man hier nicht rein posten sollte.

Warum solltest du hier nicht posten sollen können dürfen? Ist ja sogar von mir gewollt, ich freu mich über feedback ☺

Update 4½ - amd64

ich hab mal Debs für 64-Bit gemacht. Sie wurden in einem Karmik 9.10 gebaut, müssten aber auch in den 64-Bit Jaunty 9.04 und der 64-Bit Lucid-Alpha 10.04 funktionieren.

Das Script ist auch wieder im Paket dabei.

Antiqua schrieb:

Update 4

So, nu isses soweit:

Klasse ! Vielen Dank, dass sich mal einer des Problems annimmt ! Ich hatte mir mittlerweile mit ein paar Scripts auf der Kommandozeile beholfen.

Die Pakete wurden auf einem Ubuntu Jaunty (9.04) 32-Bit gebaut und getestet. Mit k3b braucht man jetzt keine zusätzlichen Einstellungen mehr vornehmen. Brasero tuts hier auch ohne zu meckern.

Dass das mit Brasero funktioniert ist auch sehr schön.

Das ganze müsste auch mit Karmik (9.10) und sogar auf der Lucid-alpha (10.04) funktionieren. Das hab ich allerdings noch nicht getestet.

Da habe ich meine Bedenken. Denn unter 9.10 haben sie (wer auch immer) k3b so verändert, dass immer wodim genommen wird. Ein Austausch durch ein selbst kompiliertes cdrecord hat bei mir nicht geklappt (selber probiert - nicht Dein Paket). K3b meldet dann immer "cdrecord wurde nicht gefunden". Ich kenne den Mechanismus nicht, vielleicht prüfen sie über einen Hash oder suchen bestimmte Strings.

Ich würde mich über Verbesserungsvorschläge oder generell über Feedback freuen.

Ein Problem könnte sich mit den geänderten Parametern ergeben. Laut Schily haben sich verschiedene Kommandozeilen Parameter geändert und sind zwischen cdrecord und wodim nicht gleich. Das betrifft wohl vornehmlich die UTF-8 Unterstützung.

Den Link habe ich jetzt leider nicht parat.

Ich werde Dein Paket auf alle Fälle mal unter 9.10 testen.

krazy61 schrieb:

Antiqua schrieb:

Mit k3b braucht man jetzt keine zusätzlichen Einstellungen mehr vornehmen. Brasero tuts hier auch ohne zu meckern.

Dass das mit Brasero funktioniert ist auch sehr schön.

Das ganze müsste auch mit Karmik (9.10) und sogar auf der Lucid-alpha (10.04) funktionieren. Das hab ich allerdings noch nicht getestet.

Da habe ich meine Bedenken. Denn unter 9.10 haben sie (wer auch immer) k3b so verändert, dass immer wodim genommen wird. Ein Austausch durch ein selbst kompiliertes cdrecord hat bei mir nicht geklappt (selber probiert - nicht Dein Paket). K3b meldet dann immer "cdrecord wurde nicht gefunden". Ich kenne den Mechanismus nicht, vielleicht prüfen sie über einen Hash oder suchen bestimmte Strings.

Den Brennprogrammen bleibt keine Wahl, die müssen cdrecord nehmen. ☺

Selbst wenn sie wodim oder genisoimage aufrufen, landen sie bei cdrecord und mkisofs. Ich bin nach "Wie du mir, so ich dir" vorgegangen. Ist zwar ethisch auch nicht absolut korrekt, aber nur so gings.

Wenn du meine Pakete instalierst, werden Links von wodim → cdrecord und genisoimage → mkisofs gesetzt. genisoimage und icedax (cdda2wav-Fork) werden sogar deinstaliert. K3B nimmt nach instalation automatisch die richtigen Pakete und erkennt auch, daß da jetzt ein echtes cdrecord und ein echtes mkisofs vorhanden ist, ganz ohne irgendwelche Einstellungen (zumindest auf meinen Testsystemem).

Ich würde mich über Verbesserungsvorschläge oder generell über Feedback freuen.

Ein Problem könnte sich mit den geänderten Parametern ergeben. Laut Schily haben sich verschiedene Kommandozeilen Parameter geändert und sind zwischen cdrecord und wodim nicht gleich. Das betrifft wohl vornehmlich die UTF-8 Unterstützung.

Ja, davon hab ich auch schon irgendwo was gelesen. Ich hab aber etwas älteren Sourcecode genommen (Nämlich den, den grml benutzt aus deren git ausgecheckt. Der ist für Debian gepatcht und lässt sich zu einem Debian-Paket übersetzten). Die neueste original-Source von Schily bekomm ich nicht korrekt zu Debs gebaut. Mika von grml schreibt da was von einem Patch, den er von einer früheren Version extrahiert habe und auf diesen von mir benutzten Source gepatcht hat.

Ich kann bisher bei mir allerdings keine Probleme mit dem 32-Bit Paketen unter Jaunty feststellen. Hab aber auch noch nicht alles und jeden von hinten und vorne und zurück gebrannt... 😉

Ich werde Dein Paket auf alle Fälle mal unter 9.10 testen.

Ja, mach das bitte mal und bitte, bitte Feedback, ob es Probleme gibt/gab oder was auch immer. Probier bitte auch das mitgelieferte install/deinstall-Script (ich hab auf dem Jaunty schon mindestens 5 x damit instaliert und deinstaliert ohne Probleme).

Antiqua schrieb:

Das ganze müsste auch mit Karmik (9.10) ... funktionieren. Das hab ich allerdings noch nicht getestet.

Hier die Ausgaben des Skripts unter 9.10. Allerdings muss ich dazu sagen, dass es sich um eine selbstgezimmerte Openbox-Minimalinstallation handelt - also kein Standard. Das einzige vorhandene Brennprogramm war xfburn. Vorher habe ich absichtlich wodim + genisoimage installiert.

Wähle vormals abgewähltes Paket libscg1.
(Lese Datenbank ... 83948 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke libscg1 (aus .../libscg1_2.01.01-1~a58-pre2ubuntu1_i386.deb) ...
Richte libscg1 ein (9:2.01.01-1~a58-pre2ubuntu1) ...

Verarbeite Trigger für libc-bin ...
ldconfig deferred processing now taking place
Wähle vormals abgewähltes Paket cdda2wav.
(Lese Datenbank ... 84061 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke cdda2wav (aus .../cdda2wav_2.01.01-1~a58-pre2ubuntu1_i386.deb) ...
Richte cdda2wav ein (9:2.01.01-1~a58-pre2ubuntu1) ...
Setting /usr/bin/cdda2wav to suid root permissions.
See /usr/share/doc/cdrecord/README.Debian of package cdrecord for details.

Verarbeite Trigger für man-db ...
Wähle vormals abgewähltes Paket cdrecord.
(Lese Datenbank ... 84076 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke cdrecord (aus .../cdrecord_2.01.01-1~a58-pre2ubuntu1_i386.deb) ...
Ersetze die Dateien im alten Paket wodim ...
Richte cdrecord ein (9:2.01.01-1~a58-pre2ubuntu1) ...
Setting /usr/bin/cdrecord to suid root permissions.
See /usr/share/doc/cdrecord/README.Debian for details.
Setting /usr/bin/readcd to suid root permissions.
See /usr/share/doc/cdrecord/README.Debian for details.

Verarbeite Trigger für man-db ...
Wähle vormals abgewähltes Paket mkisofs.
dpkg: Ziehe Entfernen von genisoimage zugunsten von mkisofs in Betracht ...
dpkg: Ja, werde genisoimage zugunsten von mkisofs entfernen.
(Lese Datenbank ... 84089 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke mkisofs (aus .../mkisofs_2.01.01-1~a58-pre2ubuntu1_i386.deb) ...
Richte mkisofs ein (9:2.01.01-1~a58-pre2ubuntu1) ...
Verarbeite Trigger für man-db ...
Wähle vormals abgewähltes Paket cdrtools-doc.
(Lese Datenbank ... 84083 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke cdrtools-doc (aus .../cdrtools-doc_2.01.01-1~a58-pre2ubuntu1_all.deb) ...
Richte cdrtools-doc ein (9:2.01.01-1~a58-pre2ubuntu1) ...

Mein erster Versuch, Brasero und cdrecord mit Hilfe des cdrecord:-PPAs zu verheiraten, schlug fehl: brasero bestand auf wodim. Nun nicht mehr ☺

Allerdings muss ich noch die Funktionalitaet von brasero ueberpruefen - die Installation ist nur die halbe Miete...

aasche schrieb:

Hier die Ausgaben des Skripts unter 9.10. Allerdings muss ich dazu sagen, dass es sich um eine selbstgezimmerte Openbox-Minimalinstallation handelt - also kein Standard. Das einzige vorhandene Brennprogramm war xfburn. Vorher habe ich absichtlich wodim + genisoimage installiert.

die Ausgabe ist genau so, wie sie sein soll. Das cdrkit wird (fast) vollständig entfernt, zugunsten der cdrtools ☺

Mein erster Versuch, Brasero und cdrecord mit Hilfe des cdrecord:-PPAs zu verheiraten, schlug fehl: brasero bestand auf wodim. Nun nicht mehr ☺

Allerdings muss ich noch die Funktionalitaet von brasero ueberpruefen - die Installation ist nur die halbe Miete...

weil es mit dem PPA nich geklappt hat, hab ich ja das ganze überhaupt angefangen 😉
und brasero ruft, wenn ich mich nicht irre ( 😇 hähähä..), intern direkt wodim auf. Meine Pakete legen u.a. deswegen ja einen, bzw. mehrere Links. /usr/bin/wodim zeigt auf cdrecord, /usr/bin/genisoimage zeigt auf mkisofs, usw. Wenn also irgendwas wodim aufruft, brennt trotzdem cdrecord. Das geht solange gut, wie die Aufrufparameter für wodim auch von cdrecord verarbeitet werden können. Bei mir ging bisher alles gut. Ich brenne allerdings auch hauptsächlich mit k3b und das erkennt sofort, daß da jetzt die cdrtools am Werke sind und ruft die auch passend auf, nicht mit hartcodiertem wodim (wer programiert so einen Schachsinn eigentlich? Ach ja, ist ja Gnome-Zeugs... oder ist der Ubuntu-Maintainer schuld? 😉).

Bin auf weitere Infos, bzw. feedback gespannt ☺

Antiqua schrieb:

Bin auf weitere Infos, bzw. feedback gespannt ☺

Die praktischen Ergebnisse sind durchwachsen. Zum einen scheint cdrecord die bessere Hardware-Erkennung zu haben: ein von wodim nicht erkannter CD-Brenner taucht jetzt bei cdrecord -checkdrive auf. Beim Einsatz eines (anderen) DVD-Brenners habe ich ein merkwuerdiges Problem: eine mit Brasero erstellte Daten CD-RW wird im Brennlaufwerk (!) nicht mehr gelesen, funktioniert aber tadellos in anderen Rechnern... Diese Probleme scheinen von der Hardware (LG GSA-H22N) abzuhaengen - oder von der Art und Weise, wie cdrecord brennt - oder von Brasero?

Nachtrag: ich vermute ein Hardware-Problem, da staendig Lesefehler gemeldet werden...

aasche schrieb:

Die praktischen Ergebnisse sind durchwachsen. Zum einen scheint cdrecord die bessere Hardware-Erkennung zu haben: ein von wodim nicht erkannter CD-Brenner taucht jetzt bei cdrecord -checkdrive auf.

ja, obwohl die von mir verwendete Version auch nicht die allerneueste ist, erkennt es deutlich mehr Hardware als wodim

Beim Einsatz eines (anderen) DVD-Brenners habe ich ein merkwuerdiges Problem: eine mit Brasero erstellte Daten CD-RW wird im Brennlaufwerk (!) nicht mehr gelesen, funktioniert aber tadellos in anderen Rechnern... Diese Probleme scheinen von der Hardware (LG GSA-H22N) abzuhaengen - oder von der Art und Weise, wie cdrecord brennt - oder von Brasero?

Nachtrag: ich vermute ein Hardware-Problem, da staendig Lesefehler gemeldet werden...

Hardwareproblem oder auch Rohlingproblem. Ich hab festgestellt, daß vor allem bei RW-Coastern bei weitem nicht jedes Laufwerk mit jedem Rohling kann. Ganz abgesehen von der sehr weiten Qualitätsspanne von RW-Medien.

versuch mal direkt im Terminal mit diesem Laufwerk auf die CD-RW zu brennen:

mkisofs -o neue_cd.iso -l -r -J -R ordner_mit_files
cdrecord dev=4,0,0 blank=all -driveropts=burnproof -v speed=4 neue_cd.iso   # evtl. noch -force dazu, oder blank=.. weglassen.
                                                                            # blank=all dauert lange!!! evtl. blank=fast benutzen
                                                                            # dev=4,0,0 ist natürlich das evtl. defekte LW 
                                                                            # PS: wegen akutem Mangel an CD-RW nicht getestet!

wenn dann keine Probleme auftreten, ist Brasero schuld, weil es irgenwelche wodim-Optionen aufruft, die cdrecord nicht kennt

PS: die man-Page von cdrecord und mkisofs sind mMn sehr gut

Hallo, Ich habe die 64 bit Version installiert, das Brennen klappt jedoch immer noch nicht. Hier die Ausgabe von K3b

Devices
-----------------------
HL-DT-ST DVDRAM GH22NS50 TN02 (/dev/sr0, CD-R, CD-RW, CD-Rom, DVD-Rom, DVD-R, DVD-RW, DVD-R doppelschichtig, DVD+R, DVD+RW, DVD+R doppelschichtig) [DVD-Rom, DVD-R Sequentiell, Zweischichtige DVD-R Sequentiell, Zweischicht-DVD-R Sprung, DVD-Ram, DVD-RW Eingeschränktes Überbrennen, DVD-RW Sequentiell, DVD+RW, DVD+R, Zweischichtige DVD+R, CD-Rom, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Eingeschränktes Überschreiben, Sprung zwischen DVD-Schichten] [%7]

K3b::IsoImager
-----------------------
mkisofs print size result: 664 (1359872 bytes)

System
-----------------------
K3b Version: 1.68.0
KDE Version: 4.3.2 (KDE 4.3.2)
QT Version:  4.5.2
Kernel:      2.6.31-20-generic

Used versions
-----------------------
mkisofs: 2.1.1a57
cdrecord: 2.1.1a57

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
SCSI buffer size: 64512
/usr/bin/cdrecord: Warning: The DMA speed test has been skipped.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a57 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2009 J�rg Schilling
TOC Type: 3 = CD-ROM XA mode 2
Using libscg version 'schily-0.9'.
Driveropts: 'burnfree'
atapi: 1
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   : 
Vendor_info    : 'HL-DT-ST'
Identifikation : 'DVDRAM GH22NS50 '
Revision       : 'TN02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: CD-R
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-R/DL sequential recording 
Profile: DVD-R/DL layer jump recording 
Profile: DVD-RW sequential recording 
Profile: DVD-RW restricted overwrite 
Profile: DVD+RW 
Profile: DVD+R 
Profile: DVD+R/DL 
Profile: DVD-ROM 
Profile: CD-R (current)
Profile: CD-RW 
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 SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP
Drive buf size : 1053696 = 1029 KB
Drive pbuf size: 1966080 = 1920 KB
FIFO size      : 4194304 = 4096 KB
Track 01: data     1 MB        
Total size:        1 MB (00:08.88) = 666 sectors
Lout start:        1 MB (00:10/66) = 666 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:  -12369 (97:17/06)
  ATIP start of lead out: 359849 (79:59/74)
Disk type:    Short strategy type (Phthalocyanine or similar)
Manuf. index: 69
Manufacturer: Moser Baer India Limited
Manufacturer is guessed because of the orange forum embargo.
The orange forum likes to get money for recent information.
The information for this media may not be correct.
    Capacity  Blklen/Sparesz.  Format-type  Type
           0             2048         0x00  No Media Present or Unknown Capacity
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 359183
Starting to write CD/DVD/BD at speed 48 in dummy TAO mode for multi session.
Last chance to quit, starting dummy 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
Starting new track at sector: 0
Track 01:    0 of    1 MB written.
Track 01:    1 of    1 MB written (fifo 100%) [buf  95%]   1.6x.
/usr/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB:  2A 00 00 00 02 0F 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 2A 30 02 80 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) 
cmd finished after 0.006s timeout 40s
/usr/bin/cdrecord: The current problem looks like a buffer underrun.
/usr/bin/cdrecord: It looks like 'driveropts=burnfree' does not work for this drive.
/usr/bin/cdrecord: Please report.
/usr/bin/cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up.
write track data: error after 1079296 bytes
Writing  time:   10.587s
Average write speed   0.8x.
Min drive buffer fill was 95%
Fixating...
WARNING: Some drives don't like fixation in dummy mode.
Fixating time:   20.688s
/usr/bin/cdrecord: fifo had 22 puts and 18 gets.
/usr/bin/cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%.

cdrecord command:
-----------------------
/usr/bin/cdrecord -v gracetime=2 dev=/dev/sr0 speed=48 -tao -dummy driveropts=burnfree -multi -xa -tsize=664s -

mkisofs
-----------------------
664
/usr/bin/mkisofs: Warning: Cannot add inode hints with -no-cache-inodes.
=== last message repeated 2 times. ===
Setting input-charset to 'UTF-8' from locale.
 77.26% done, estimate finish Wed Mar 17 13:45:42 2010
Total translation table size: 0
Total rockridge attributes bytes: 459
Total directory bytes: 2400
Path table size(bytes): 22
Max brk space used 0
664 extents written (1 MB)

mkisofs calculate size command:
-----------------------
/usr/bin/mkisofs -gui -graft-points -print-size -quiet -volid maya -volset  -appid K3B THE CD KREATOR (C) 1998-2007 SEBASTIAN TRUEG -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-pascal/k3bUS2985.tmp -rational-rock -hide-list /tmp/kde-pascal/k3bVu2985.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-pascal/k3bUR2985.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-pascal/k3bXx2985.tmp

mkisofs command:
-----------------------
/usr/bin/mkisofs -gui -graft-points -volid maya -volset  -appid K3B THE CD KREATOR (C) 1998-2007 SEBASTIAN TRUEG -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-pascal/k3bvg2985.tmp -rational-rock -hide-list /tmp/kde-pascal/k3bXg2985.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-pascal/k3bmp2985.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-pascal/k3bxx2985.tmp

wäre nett wenn mir jemand weiter helfen könnte!

montyniceguy schrieb:

Hallo, Ich habe die 64 bit Version installiert, das Brennen klappt jedoch immer noch nicht. Hier die Ausgabe von K3b

Vendor_info    : 'HL-DT-ST'
Identifikation : 'DVDRAM GH22NS50 '
Revision       : 'TN02'

wäre nett wenn mir jemand weiter helfen könnte!

Du scheinst mit deinem LG-Brenner das gleiche Problem zu haben wie in http://forum.ubuntuusers.de/topic/buffer-underrun-k3b-und-brasero-verbrennen-cd/ beschreiben. Der Fehler liegt wohl nicht am Brennprogramm, egal ob cdrecord oder wodim, sondern wo anders.

In diesem Post von tomcat69 http://forum.ubuntuusers.de/topic/buffer-underrun-k3b-und-brasero-verbrennen-cd/#post-2389238 steht eine (für ihn) funktionierende Lösung.

Erstmal danke Antiqua, für deine schnelle Antwort. Den genannten Thread hatte ich jedoch schon mehrmals gelesen, der IDE-Modus brachte bei mir jedoch keinerlei Veränderung. Heißt wohl erstmal abwarten, und zum Brennen auf Windoof zurückgreifen =(