K3b sees valid BD50 images as corrupted and doesn't want to start processing them. Reproducible: Always Steps to Reproduce: 1. Tools -> Burn Image... 2. Open file dialog and set path to a BD50 (Blu-ray double layer) ISO image Actual Results: Status box reads: 'Seems not to be a usable image'. Start button is grayed out. Expected Results: Let me start burning perfectly valid ISO image? I gave most of the relevant data in KDE forum. https://forum.kde.org/viewtopic.php?f=153&t=125016 Long story short - neither K3b 2.0.2, 2.0.3, nor 2.0.80 from Packman repo can't recognize perfectly fine BD50 ISO images as valid. Nero for Linux v4.0.0 burns them without problems and so does ImgBurn under WinXP (I didn't tried it yet under Wine). I can burn data compilation (tried only with BD25) so I suspect it is a bug i K3b's 'Burn Image' dialog/tool. This bug resembles the Bug 190775 https://bugs.kde.org/show_bug.cgi?id=190775 but that bug is supposedly fixed long time ago.
I suspect that 'Burn Image' tool expects ISO9660 image and does not recognize/support IEC 13346 (UDF) ones.
I just found out that UDFtools don't support UDF 2.5, nor UDF 2.6. I assume that K3b is also having problem handling ISO images containing UDF 2.5. I wonder, do we actually need support for UDF 2.5 file system if we have an ISO image containing one? Couldn't growisofs or K3b just "dd" data from a BD50 ISO image to a BD burner? This starts to look like a feature request. :| Also, K3b's error report should be more informative when it comes to failing to handle UDF 2.5, especially when it claims "support for Blu-Ray disks".
After inquiring about this at Cdrtools user support and CD-record (cdwrite) mailing lists, I'm confident that this is a bug in K3b. Linux has several tools which can burn ANY image to ANY media - no questions asked. It is K3b's fault that its "Burn Image" module considers perfectly normal BD50 ISO image "unusable" and doesn't invoke appropriate command in order to complete operation that can otherwise be done in command line.
I have the same problem. Also, this happens with any UDF image, not only BD50. Infact I'm trying with two dvd images. ISO9660 images work as expected. This is on K3b 2.0.2
*** This bug has been marked as a duplicate of bug 257602 ***
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.
Thomas is right, this is not a duplicate of bug 257602 and yes, K3B complains about particular image format/size which doesn't have anything to do with a file system that image contains. K3B nor Linux doesn't need to have support for particular file system in order to wright an image that contains it.
I had a look at the spots where Debian's source search finds IMAGE_ISO. Whether IMAGE_RAW is really needed seems to depend only on the tolerance towards the size test in http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=463#L463 If isoFs() or isoFs.open() throw an exception then it might be necessary to skip this test. In this case it would be necessary to introduce IMAGE_RAW or let IMAGE_UNKNOWN take over the role of IMAGE_RAW. It seem, though, that IMAGE_UNKNOWN also serves as "Image Unsuitable". So one better introduces a new value. -------------------------------------------------------------------------- http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=887#L887 would be ok for IMAGE_RAW, too. I.e. if( currentImageType() == IMAGE_ISO || currentImageType() == IMAGE_RAW) { http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=244#L244 http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=249#L249 would need mapping and reverse mapping for IMAGE_RAW. Actually the existing text "Plain data image" would rather match IMAGE_RAW than IMAGE_ISO. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1087#L1087 would need a display text for IMAGE_RAW. Like "opaque". http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1048#L1048 would then need a case "opaque" and make use of the reverse mapping defined by L249. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=845#L845 would have to allow growisofs for IMAGE_RAW as for IMAGE_ISO. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=858#L858 one would have to add IMAGE_RAW to the "||" list. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=867#L867 Same as L858. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=874#L874 Same as L858. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=548#L548 must stay as is, because it determines whether the file is really an ISO 9660 filesystem image. It will thus determine the difference between IMAGE_ISO and IMAGE_RAW. http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=81#L81 would define the new enum value IMAGE_RAW.
Git commit 54173816164c825f077e8288b628e550b51ddccb by Leslie Zhai. Committed on 07/09/2016 at 02:44. Pushed by lesliezhai into branch 'image-raw'. Introduce a new image type RAW. M +11 -2 src/misc/k3bimagewritingdialog.cpp http://commits.kde.org/k3b/54173816164c825f077e8288b628e550b51ddccb
Hi Thomas, > I did not find an online repository of K3B upstream. UPSTREAM repos is https://quickgit.kde.org/?p=k3b.git and mirror is https://github.com/KDE/k3b > A new enum value in could then be IMAGE_RAW, indicating that it's not an ISO but nevertheless shall be copied as if it was one I am reading carefully about your implementation about IMAGE_RAW. and please rebase your patch for image-raw branch https://github.com/KDE/k3b/tree/image-raw thanks a lot ;-) Regards, Leslie Zhai
Git commit f33af3b96454e302b722285e532aba7d11ad478e by Leslie Zhai. Committed on 07/09/2016 at 03:54. Pushed by lesliezhai into branch 'image-raw'. Treat unusable image as raw. M +1 -1 CMakeLists.txt M +16 -7 src/misc/k3bimagewritingdialog.cpp http://commits.kde.org/k3b/f33af3b96454e302b722285e532aba7d11ad478e
Hi, Leslie Zhai: > I am reading carefully about your implementation about IMAGE_RAW. and please > rebase your patch for image-raw branch Well, i did not implement anything but only inspected the situation and made a rough plan what would need a change. I am running neither KDE nor Gnome on my workstation. Building K3B from source would start a big endeavor on its own. But i will from now on study that branch (maybe still using Debian code search, because searching "IMAGE_ISO" in https://quickgit.kde.org/ yields no match). Let's see whether i find something to nitpick: ------------------------------------------------------------------------- Line 473 of k3bimagewritingdialog.cpp: d->comboImageType->addItem(i18n("Optical disc media")); I would rather call it "ISO 9660 filesystem image". I is not an optical medium but rather shall get onto optical medium. Albeit ISO 9660 (and its predecessor High Sierra) was announced as the filesystem for CD-ROM media, ISO 9660 has long escaped that cage. It is as read-only filesystem very well suited for backup and archiving. In its role as bootable filesystem it has conquered USB sticks and memory cards. ------------------------------------------------------------------------- Line 707: case IMAGE_RAW: case IMAGE_ISO: { K3b::Iso9660 isoFs( d->imageFile ); if( isoFs.open() ) { .... } I proposed to introduce IMAGE_RAW in order to be able to skip this test for size. So there should be an if around it: case IMAGE_RAW: case IMAGE_ISO: { if ( d->currentImageType() == IMAGE_ISO ) { K3b::Iso9660 isoFs( d->imageFile ); if( isoFs.open() ) { .... } } Has it been tested already that K3b::Iso9660ImageWritingJob* job_ = new K3b::Iso9660ImageWritingJob( &dlg ); works with non ISO 9660 images ? ------------------------------------------------------------------------- Line 871: if (KMessageBox::questionYesNo(this, i18n("Seems not to be a usable image, do you want to treat it as RAW?"), i18n("Unkown image type")) == KMessageBox::Yes) { The text is somewhat misleading, especially since "raw" has an old meaning in the context of CD burning. I would rather state "Type of image file is not recognizable. Do you want to burn it anyway ?" ------------------------------------------------------------------------- Line 938: You removed the case d->currentImageType() == IMAGE_UNKNOWN . I am not sure whether IMAGE_UNKNOWN can reach this code. Nevertheless we would need a source code review to assert that it cannot. So i'd cowardly keep IMAGE_UNKNOWN in the "||" list. ------------------------------------------------------------------------- Have a nice day :) Thomas
Git commit 585067b15d1d3b0d875e092c775f1925e2ba270f by Leslie Zhai. Committed on 08/09/2016 at 01:09. Pushed by lesliezhai into branch 'image-raw'. Prepare for code review. M +16 -12 src/misc/k3bimagewritingdialog.cpp http://commits.kde.org/k3b/585067b15d1d3b0d875e092c775f1925e2ba270f
Hi Thomas, Please review it https://git.reviewboard.kde.org/r/128860/ > because searching "IMAGE_ISO" in https://quickgit.kde.org/ yields no match Perhaps the mirror GitHub provided such feature as Debian's website? Hi Marcus, Could you test image-raw branch for k3b https://github.com/KDE/k3b/tree/image-raw I do *NOT* have BD50 (Blu-ray double layer) ISO image, or can you provide some URL for testing, thanks a lot! Regards, Leslie Zhai
Hi, Leslie Zhai wrote: > Please review it https://git.reviewboard.kde.org/r/128860/ I see a box "Testing Done" but no place to state that i did a code review but did not test. Shall i write: "Code reviewed but not tested" ? > I do *NOT* have BD50 (Blu-ray double layer) ISO image, The problem is neither about the size nor about the medium. So you could create any non-ISO image file: dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img and use the CD emulator as target device. Nitpicks: ------------------------------------------------------------------- The comment // set a wanted media type (DVD/BD -> only ISO) riddled me already when i looked at the code for the first time. I believe it wants to say that if the image is not IMAGE_ISO, IMAGE_RAW, or IMAGE_UNKNOWN, then it is a structured CD image description which cannot be interpreted for DVD or BD media. So the wanted medium type is MEDIA_WRITABLE_CD in this case, and any medium type for ISO, RAW, and UNKNOWN. Maybe one should change it to // set a wanted media type // some image types can be put on any medium, some only on CD ------------------------------------------------------------------- I still have scruples about the type name "raw" in lines 1152 else if (imageType == "raw") and 1200: imageType = "raw"; In man cdrecord (or man wodim) there are lots of references to "raw" in the sense that CD sector metadata are provided by the input data of the burn program. A CD sector has 98 * (24 + 8 + 1) = 3234 bytes. CD-Audio uses 98 * 24 = 2352 for payload. The rest is C1,C2 checksums and 98 subchannel bytes. CD-ROM uses 2048 for payload. The rest is filled with more meta-info about the CD sector. Normally we send only the 2048 bytes to the drive which then computes the meta data. In "raw" write mode cdrecord sends some or all of the meta-data too. But this is not what we mean with "raw" image. So the user should get to see a different word when IMAGE_RAW is being processed. (One could argue that IMAGE_RAW should be IMAGE_PLAIN and the text should be "plain". If i had thought of the raw-raw nomenclature collision i had proposed a different macro name. But "IMAGE_RAW" will only be seen by programmers, whom i suppose to easily find out that IMAGE_RAW is not an image for cdrecord -raw. ) ------------------------------------------------------------------- Elsewise the changeset looks good to me. Testing will tell whether it suffices to solve the problem. Have a nice day :) Thomas
Hi Thomas, > Shall i write: "Code reviewed but not tested" ? You are welcome ;-) Please click 'Review' to review the patch: https://pbs.twimg.com/media/Cr0S7SqUAAQ5Evo.jpg You can click 'Expand All' to be familiar with KDE's review process https://git.reviewboard.kde.org/r/128444/ > dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img I will test it! > Nitpicks I am carefully read it, and perhaps you can use KDE's reviewboard to review and comment line by line, please also see https://git.reviewboard.kde.org/r/128444/ Regards, Leslie Zhai
Hi Thomas, CDEmu might has strict image test! when I try to cdemu load 0 ~/my_100mb_test.img, it thrown such error: ERROR: Failed to load image: net.sf.cdemu.CDEmuDaemon.errorMirage.ParserError: No parser can handle the image file! Regards, Leslie Zhai
Git commit 3d21bdca2a9ec4ef2d6226991118ba0e3f09a45a by Leslie Zhai. Committed on 08/09/2016 at 08:29. Pushed by lesliezhai into branch 'image-raw'. Fix as Thomas suggested. M +7 -6 src/misc/k3bimagewritingdialog.cpp http://commits.kde.org/k3b/3d21bdca2a9ec4ef2d6226991118ba0e3f09a45a
Hi Thomas, Updated https://git.reviewboard.kde.org/r/128860/ and it is better to use Reviewboard for reviewing the patch ;-) Regards, Leslie Zhai
Hi, Leslie Zhai wrote: > Please click 'Review' to review the patch: > You can click 'Expand All' to be familiar with KDE's review process Probably i do not see any text fields to fill because i am not logged in and my bugs.kde.org account does not work. Registering now as non-robot ... After login i see a tab "Review" which brings me to a page with checkbox "Ship it" and editable text box "Edit header". I begin to read the online documentation. If you have instructions for me how to operate it, i would be glad to follow them. > CDEmu might has strict image test! when I try to cdemu load 0 > ~/my_100mb_test.img, it thrown such error: my_100mb_test.img shall not emulate the medium. It shall be copied onto the emulated medium. I assume CDEmu has means to create a simulated CD or DVD. (Did not find a user manual yet.) This emulated drive and medium would then be the CD drive for the K3B test. In K3B you select my_100mb_test.img as image file to be burned. Have a nice day :) Thomas
Hi, i reviewed the whole patch as "Looks good to me". Since i see no problematic details i think i can skip for now learning how to comment on single lines. (Tell me if i shall add more info to the review.) You need to get a DVD drive. Last year i bought an LG GH24NSC0 for 12.95 EUR. Blu-ray burners still cost around 80 EUR. My newest is ASUS BW-16D1HT and works well. Next you'd need a few DVD-RW media, because they are re-usable and can assume both main roles of optical media: sequential and overwritable. Switch by dvd+rw-format: no extra option for making overwritable, option -blank for making sequential, option -blank=full to make it ready for sequential multi-session. (-blank[=full] has to be repeated before each sequential re-use. Overwritable media can be re-used without formatting them again. Formatting and -blank=full last as long as a full capaity write run.) DVD+RW are more reliable than DVD-RW, but they cannot be written in sequential state. DVD-RW can be used like DVD-R and quite like DVD+R or unformatted BD-R. Have a nice day :) Thomas
Hi Thomas, > my_100mb_test.img shall not emulate the medium. It shall be copied onto the emulated medium. I am stupid ;P I wrongly loaded the virt.img A.K.A my_100mb_test.img, and right now the correct testcase PASS https://pbs.twimg.com/media/Cr39ZYEVYAUylmE.jpg > Tell me if i shall add more info to the review. The official Reviewboard doc is very helpful https://www.reviewboard.org/docs/manual/2.5/users/reviews/reviewing-diffs/ and you can play with the demo to be familiar with it http://demo.reviewboard.org/r/ > You need to get a DVD drive I will try to update my 'Test enviroment' ;-) http://www.leetcode.cn/2016/08/k3b.html Regards, Leslie Zhai
Hi, i wanted to paste to following text into the "Edit header" field of https://git.reviewboard.kde.org/r/128860/. But neither the paste function of the window manager nor the paste menu item of Firefox puts the X selection into the browser field. Further i always have to disable Javascript when using Debian code search and enable it before git.reviewboard.kde.org is willing to communicate with me. I am getting too old for this modern stuff, i fear. ---------------------------------------------------------------- Review text: ---------------------------------------------------------------- The green "Success" text in the screenshot is a reason to cheer. While digging in the code i found in libk3b / jobs / k3biso9660imagewritingjob.cpp line 340: if( m_simulate ) return i18n("Simulating ISO 9660 Image"); else return ( i18n("Burning ISO 9660 Image"); Did you see pacifier texts or a headline stating "ISO 9660" ? Not really understanding how variable "d" enters the context of the functions and to what type it points, i have no clue whether one can inquire d->foundImageType or whether currentImageType() is in reach to avoid the text "ISO 9660" in case of not IMAGE_ISO. ---------------------------------------------------------------- End of review text. ---------------------------------------------------------------- Have a nice day :) Thomas
Hi Leslie Zhai, Thomas Schmitt, I have been reading this post. "K3b" is the most loved CD/DVD/Blu-Ray application for Linux Mint users, including me. If there are updates and or upgrades to this wonderful application, how can Linux Mint users install it on 32-bit and 64-bit systems on Linux Mint versions 17.x based on Ubuntu 14.04 or Linux Mint version 18 based on Ubuntu 16.04? Are there any easy to install and use Linux ".deb" files, or a PPA perhaps, that we can use to install these upgrades? Or, do we have to compile it, and if so, could you please detail those instructions? Also, since you are actively updating "K3b", I have another feature and or request. Can you do this, or should I create another "KDE bug - feature" request for the modification and or update to the "checksum" aspect of burning and or verifying ".iso" images to include a more current "sha256" checksum value, and maybe an option (auto or not) for comparing that to an existing "sha256sum.txt" file that is in the same folder (directory). Thank you, Phil D. KDE User: phdsrq@gmail.com Linux Mint forum user: phd21 phd21mint@gmail.com
Hi, Phil wrote: > Are there any easy to install and use Linux ".deb" files Well, as soon as it becomes a released feature of K3B, one may ask pkg-kde-extras@lists.alioth.debian.org for packaging, or file a Debian bug against package "k3b" requesting it. Debian's package info is at https://tracker.debian.org/pkg/k3b . Maybe https://launchpad.net/~kubuntu-members as mentioned on https://launchpad.net/ubuntu/+source/k3b would be willing to make a shortcut. > hould I create another "KDE bug - feature" [...] > verifying ".iso" images to include a more current "sha256" checksum I guess the rules here require that we discuss this in a different bug report thread. For transport and storage security, MD5 suffices. The probability of a false match is far less than the earth being hit by a 10 km asteroid within the next microsecond. If you don't fear that, then there is no need to fear accidential MD5 match. Have a nice day :) Thomas
Hi Thomas, Sorry for late reply, my child fever badly ;-( > Further i always have to disable Javascript Yes! javascript developers rock the world now as they argued: sort of nodejs ;-) > Did you see pacifier texts or a headline stating "ISO 9660" I post here https://forum.isoft-linux.org/viewtopic.php?f=3&t=47 > Not really understanding how variable "d" enters the context of the functions and to what type it points D-Pointer https://wiki.qt.io/D-Pointer and I will double check the text "ISO 9660" Hi Phil, > Or, do we have to compile it, and if so, could you please detail those instructions? Please have a look at http://www.leetcode.cn/2016/08/k3b.html about Dependence and Build > or should I create another "KDE bug - feature" request for the modification Yes! please follow the KDE process style, bug report first ;-) Regards, Leslie Zhai
Hi, Leslie Zhai wrote: > D-Pointer https://wiki.qt.io/D-Pointer Looks like somebody had to work around some consequences of the decision to use C++. (Oh if only Bjarne Stroustrup had a real life back in the 1980s !) > headline stating "ISO 9660" > https://forum.isoft-linux.org/viewtopic.php?f=3&t=47 Yep. The "Writing Data Project (virt)" window says "ISO 9660 Filesystem". But that is not the text i see in k3biso9660imagewritingjob.cpp "Simulating ISO 9660 Image" and ""Burning ISO 9660 Image". Question is where this comes from and how to provide the information about ImageWritingDialog.foundImageType at that place. Phil wrote: > should I create another "KDE bug - feature" request If i shall join that discussion. i'd need a pointer to the thread by email: scdbackup@gmx.net (Google finds me places where people say "xorriso", "libburn", or "growisofs". But "K3B" yields just too many hits per day.) Have a nice day :) Thomas
Hi Thomas, > the decision to use C++ (Oh if only Bjarne Stroustrup had a real life back in the 1980s !) Yes! and even there are a lot of c++0x or c++14 style in KDE projects, for example, KWin: https://github.com/KDE/kwin/blob/master/workspace.cpp#L369 > But that is not the text i see in k3biso9660imagewritingjob.cpp Yes! there are only copy/format project use JobProgressDialog (with jobDescription), but ImageWritingDialog is inherited by InteractionDialog, so you can not see the "Simulating ISO 9660 Image" or ""Burning ISO 9660 Image" jobDescription. > But "K3B" yields just too many hits per day KDE bug system, mailing list, reviewboard, and phabricator automatically send a lot of emails... so I use gmail ;P Regards, Leslie Zhai
> but ImageWritingDialog is inherited by InteractionDialog inherited from, sorry typo...
(In reply to Thomas Schmitt from comment #29) > Hi, > > Leslie Zhai wrote: > > D-Pointer https://wiki.qt.io/D-Pointer > > Looks like somebody had to work around some consequences of the > decision to use C++. (Oh if only Bjarne Stroustrup had a real life > back in the 1980s !) > > > > headline stating "ISO 9660" > > https://forum.isoft-linux.org/viewtopic.php?f=3&t=47 > > Yep. The "Writing Data Project (virt)" window says "ISO 9660 Filesystem". > But that is not the text i see in k3biso9660imagewritingjob.cpp > "Simulating ISO 9660 Image" and ""Burning ISO 9660 Image". > > Question is where this comes from and how to provide the information > about ImageWritingDialog.foundImageType at that place. > > > Phil wrote: > > should I create another "KDE bug - feature" request > > If i shall join that discussion. i'd need a pointer to the thread > by email: scdbackup@gmx.net > (Google finds me places where people say "xorriso", "libburn", or > "growisofs". But "K3B" yields just too many hits per day.) > > > Have a nice day :) > > Thomas Dear Thomas Schmitt, Thank you for your replies. If I read your comments properly, you seemed to want to join in on this K3b feature request, so here is the link to that KDE Bug feature request: I also forwarded an email to your email address. Bug 360184 - k3b should offer option to select either md5 sum or sha256 when loading dvd iso https://bugs.kde.org/show_bug.cgi?id=360184 You have a nice day as well :-) . Best Regards, Phil
*** Bug 387765 has been marked as a duplicate of this bug. ***