https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #63 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, sorry, i did not yet get to installing an Archlinux with CDEmu. Real life and some other free software obligations ... cdrskin3.log looks like a full success. (It becomes more eye-friendly by: sed -e 's/\r/\n/g' < cdrskin3.log | less ) Does it stem from a cdrskin run underneath K3B ? If not, then please test whether this cdrskin survives a run under K3B. -------------------------------------------------------------------------- Whatever, it looks like i'd need to install something similar to your K3B development environment in order to reproduce the problem with CDEmu. That's quite some hurdle. So for now i have to ask you to make the crash experiments. Interesting would be if you could temporarily hack your K3B so that we get to see: - Messages of (patched) cdrskin-1.4.7 under K3B with options -v -V . - Messages of cdrecord under K3B with options -d -v -V. cdrecord.log.tar.bz2 did not contain any host_status lines that were not "00". But unpatched cdrskin succeeded in the same environment and thus did not experience any other host_status than 0. The resulting message list is indeed gigantic. I scanned for interesting lines by cat cdrecord.log | grep 'host_status:' | grep -v 'host_status: 00' -------------------------------------------------------------------------- cdrskin-burn-archlinux-iso-debugging-output4.txt Hrmpf. CDEmu seems to hate the RESERVE TRACK command. This SCSI command was triggered by libburn's automatic decision for the behavior of option -sao because: The DVD+R was blank, no -multi was desired, the input size was known in advance by option tsize=. On a real DVD+R in a real drive this should well work. For now i retract my objections against a hard coded option -tao. If the user does not explicitely demand SAO (or DAO or Reserve Track), then it is the safer bet with your kind of "optical drive". So in https://cgit.kde.org/k3b.git/commit/?id=a8074105e842babab18d7adcb290dd6eca3304bb you will have to revert the first change: > - d->process << "-tao"/* << "-sao"*/; > +#ifdef K3B_DEBUG > + qDebug() << "DEBUG:" << __PRETTY_FUNCTION__ << "let libburn choose " > + "the write type according to other parameters and the medium state."; > +#endif Does the K3B user get an opportunity to explicitely choose SAO/DAO ? If so, then this should be taken into repsect here. -------------------------------------------------------------------------- Other half of /commit/?id=a8074105e842babab18d7adcb290dd6eca3304bb : > emit infoMessage(i18n("Writer does not support raw writing."), > MessageWarning); > - if (d->cdrskinBinObject->hasFeature("tao")) > - d->process << "-tao"; A warning is not enough. If the program gets to this point then the input data will not be written to the CD medium in the way that is expected by the producer of those input data. Readers will perceive the written medium as CD-ROM (i.e. computer data) with garbage sprinkled over the payload. Maybe the burn run will exceed the CD capacity. The intention of the input producer is rather to influence parts of the CD sectors which are not read by normal readers as payload but rather tell the reading drive what kind of payload the CD sectors bear. Further there are the "sub-channels" which bear a few bytes per sector for various purposes. Raw burning is a CD thing. DVD and BD have only sector format -data. I assume raw is mainly used for cloning of CDs with unusual sector content. -------------------------------------------------------------------------- Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.