[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

Thomas Schmitt via KDE Bugzilla bugzilla_noreply at kde.org
Tue Sep 6 11:28:20 UTC 2016


https://bugs.kde.org/show_bug.cgi?id=344392

Thomas Schmitt <scdbackup at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scdbackup at gmx.net

--- Comment #8 from Thomas Schmitt <scdbackup at 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 the assignee for the bug.


More information about the k3b mailing list