https://bugs.kde.org/show_bug.cgi?id=344392
Thomas Schmitt <scdbac...@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scdbac...@gmx.net --- Comment #8 from Thomas Schmitt <scdbac...@gmx.net> --- I doubt that the problem described here is a duplicate of https://bugs.kde.org/show_bug.cgi?id=257602 257602 bemoans the lack of a free Blu-ray video mastering tool which puts out UDF 2.5 or later. The bug ireport here is about the suspicion that K3B insists in particular image formats like ISO 9660 and rejects UDF. I did not find an online repository of K3B upstream. So i looked into Debians source tree and think that the suspicion gets confirmed in function (C++tapeworm)::slotUpdateImage http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=517#L517 First d->foundImageType = IMAGE_UNKNOWN; then it looks for ISO 9660, for "cdrecord clone image" (binary file accompanied by .toc file), for a CDRWIN .cue file, and has a TODO comment for "cdrdao tocfile". If none matches, then the image gets the complaint "Seems not to be a usable image" The motivation for the curiosity seems to be the desire to interpret structured image descriptions like .toc and .cue, which shall not be written onto medium but rather tell what data to put where on the medium. -------------------------------------------------------------------- A brutal hack and proof of concept would be to default IMAGE_UNKNOWN to IMAGE_ISO: d->foundImageType = IMAGE_ISO; d->imageFile = path; instead of K3b::ListViewItem* item = new K3b::ListViewItem( m_infoView, m_infoView->lastItem(), i18n("Seems not to be a usable image") ); and to delete the else-clause before the case of known image type: - else { + { // remember as recent image If this works in the further course of K3B processing, then one could make the hack permanent. I.e. write unknown images as ISOs. It might be, nevertheless, that other K3B parts interpret IMAGE_ISO not only as the order to copy plainly and unaltered but also as promise that indeed an ISO 9660 superblock and directory tree are present in the image. Relying on such a promise would of course yield failure. If such a promise/expectation exists or if one just wants to implement it neatly, then one should split all occurences of IMAGE_ISO into those which just indicate plain image copying and those which really indicate an ISO 9660 filesystem. The list of occurences is finite: https://codesearch.debian.net/search?q=package%3Ak3b+IMAGE_ISO A new enum value in http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=79#L79 could then be IMAGE_RAW, indicating that it's not an ISO but nevertheless shall be copied as if it was one. -- You are receiving this mail because: You are watching all bug changes.