https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #43 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, about the newest commit https://cgit.kde.org/k3b.git/commit/?id=c17d307523a08c1e6042381bdbdfe1971fffc84a > + bin.addFeature("plain-atapi"); > + bin.addFeature("hacked-atapi"); Did you find out what these features mean ? (Reading libk3b/core/k3bglobals.h i get the suspicion they mean support for addresses "/dev/hdX" and "ATAPI:X,Y,Z" respectively. This would be supported by cdrskin. But i am not totally sure.) > + bin.addFeature("burnfree"); > + bin.addFeature("burnproof"); I would decide for one of them. One never knows what other code piece could be confused if two normally mutually exclusive features are present. > + if (burnDevice()->supportsWritingMode(K3b::Device::WRITINGMODE_RAW_R96R) || > + burnDevice()->supportsWritingMode(K3b::Device::WRITINGMODE_RAW_R16) || > + burnDevice()->supportsWritingMode(K3b::Device::WRITINGMODE_RAW_R96P)) { > + d->process << "-data"; You may not do this. The input data for those raw CD modes contain bytes which do not belong to the payload but rather are CD sector metadata. Those metadata formats which have only a few ornaments around data payload get defaulted to -data by cdrskin. But the -raw* family expresses a different wish of the user (normally one that is illegal in countries with strict copyright enforcement). You will have to refuse such wishes. Best would be not to offer these write modes at all when cdrskin is to be used. > + if (burnDevice()->description().contains("Virt")) > + d->process << "--allow_emulated_drives"; This was a misunderstanding between us. --allow_emulated_drives only lifts the ban on "stdio:/path" addresses. As long as you use a "/dev/srN" address which leads to an optical drive, libburn will use its MMC driver to operate it as optical drive, rather than as POSIX file object. > + if (d->burnedMediaType & Device::MEDIA_DVD_PLUS_RW) > + d->process << "blank=deformat_sequential_quickest"; This is the wrong media type (DVD+RW). The special handling of "blank=fast" applies to to DVD-RW, which has two media types in K3B: MEDIA_DVD_RW_OVWR and MEDIA_DVD_RW_SEQ. The type _OVWR indicates a formatted medium which needs no blanking unless the user wants to deformat it. In that case "deformat_sequential_quickest" and "deformat_sequential" brings it to type MEDIA_DVD_RW_SEQ. But this is not necessarily desired when a user orders blanking for the sole purpose of making the medium writable from scratch. This wish is fulfilled by growisofs, cdrecord, cdrskin, and xorrecord without blanking because one can write the medium in random access mode. growisofs with option -M and program xorriso handle such media as appendable if they contain an ISO 9660 filesystem. So if you apply "deformat_sequential*" to MEDIA_DVD_RW_OVWR this would need special permission by the user. The type MEDIA_DVD_RW_SEQ behaves much like CD-RW, except the undesirable consequences of fast blanking. So i would exchange in above statement MEDIA_DVD_PLUS_RW by MEDIA_DVD_RW_SEQ and leave MEDIA_DVD_RW_OVWR out of the game for now. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.