Hi I'm trying to burn a blu-ray iso file created on windows 7 using nero burning rom software, but K3b shows this message: "Type of image file is not recognizable. Do you want to burn it anyway?" I can mount and read the same ISO file using cdemu client. Arch Linux, K3b 17.11.90
*** This bug has been marked as a duplicate of bug 344392 ***
Hi Leslie I think my report is not a duplicare of bug 344392. 344392 was fixed more than 1 year ago and the error messages described in 344392 and here are different. Maybe Thomas can comment something.
Thomas has already reviewed src/misc/k3bimagewritingdialog.cpp, which produced the message as you reported, and he introduced a new image type RAW https://github.com/KDE/k3b/commits/master/src/misc/k3bimagewritingdialog.cpp
Well, I can't burn bd25 iso on my computer using K3b...
Hi, this is not really the field where i am expert. C++ dyslexia and such ... K3B issues the warning message if it encounters an image which it classifies as IMAGE_UNKNOWN. In the course of bug 344392, the changesets https://cgit.kde.org/k3b.git/commit/?id=54173816164c825f077e8288b628e550b51ddccb https://cgit.kde.org/k3b.git/commit/?id=585067b15d1d3b0d875e092c775f1925e2ba270f https://cgit.kde.org/k3b.git/commit/?id=3d21bdca2a9ec4ef2d6226991118ba0e3f09a45a introduced a new classification IMAGE_RAW which is set when the warning appears and the user confirms that burning shall go on. In my git clone of K3B and on https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n873 i see: if (d->foundImageType == IMAGE_UNKNOWN) { if (KMessageBox::questionYesNo(this, i18n("Type of image file is not recognizable. Do you want to burn it anyway?"), i18n("Unknown image type")) == KMessageBox::Yes) { d->foundImageType = IMAGE_RAW; d->imageFile = path; } } The decisive line is the one that mentions IMAGE_RAW. Do you have it in your local K3B source ? The consequence of this setting should be in https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n707 as case IMAGE_RAW: case IMAGE_ISO: { ... K3b::Iso9660ImageWritingJob* job_ = new K3b::Iso9660ImageWritingJob( &dlg ); Do you see this double "case" statement in your local source ? ------------------------------------------------------------------------- If the local code is up to date, then we need more information. - How does the program react after you confirm that the image shall be burned indeed ? Any further messages ? - Does d->foundImageType = IMAGE_RAW; get executed after the warning dialog ? (A debug message would bring clarity.) - Does program execution get to https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n658 If so, what is the value of d->currentImageType() ? (A debug message before switch( d->currentImageType() ) { could bring clarity.) ------------------------------------------------------------------------- Have a nice day :) Thomas
Hi, another interesting point is why your image is not recognized as IMAGE_ISO by K3B. What do you get from command "file" ? file /path/to/image/file The following code reasoning and your mentioning of Nero brings me to the suspicion that you have a .NRG image. https://en.wikipedia.org/wiki/NRG_%28file_format%29 If not K3B can unpack it automagically, then you first need to retrieve the image payload from the .NRG. This payload would then be an ISO 9660 or UDF filesystem image. There is a tool named "nrg2iso". On a Debian derivate it should be available as binary package. Like: https://packages.debian.org/stretch/nrg2iso -------------------------------------------------------------------------- No for my doubt that we have any kind of ISO 9660 filesystem image here: The recognition of ISO 9660 filesystems is done in https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n786 by K3b::Iso9660 isoF( path ); if( isoF.open() ) { ... d->foundImageType = IMAGE_ISO; The .open() function is implemented in https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3biso9660.cpp#n589 Reasons for returning "false" would be if( !m_filename.isEmpty() ) ... else if( d->fd > 0 ) ... else if( d->cdDevice ) { ... else return false; or d->isOpen = d->backend->open(); if( !d->isOpen ) return false; or desc = ReadISO9660( &K3b::Iso9660::read_callback, d->startSector, this ); if (!desc) { qDebug() << "K3b::Iso9660::openArchive no volume descriptors"; close(); return false; The first occasion would be that not suitable pointer to the image file is given: Neither name, nor file descriptor number, nor a CD device. The second occasion is that opening as ISO 9660 fails. bool K3b::Iso9660FileBackend::open() in https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3biso9660backend.cpp#n129 looks like a C++ bloat of POSIX function open(2). So it would fail only if there is no file or no permission to read it. The third occasion is during inspection of the ISO 9660 filesystem Volume Descriptors. The 2048-byte blocks are read beginning at d->startSector until the end marking Volume Descriptor (ISO_VD_END) is read. Those sectors which were identified as ISO 9660 superblock (ISO_VD_PRIMARY), El Torito Boot Record (ISO_VD_BOOT), or Joliet superblock (ISO_VD_SUPPLEMENTARY) have been put into a list. If no such sectors were found, then the return value is NULL and triggers the message "K3b::Iso9660::openArchive no volume descriptors". UDF filesystems are supposed to have a ISO 9660 superblock for backward compatibility. So an UDF image would yield a non-empty list and thus be perveived by the caller of ReadISO9660 as IMAGE_ISO. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #6) > What do you get from command "file" ? > > file /path/to/image/file Hi Thomas result of "file file.iso" command is "file.iso: data"
(In reply to Thomas Schmitt from comment #6) > the suspicion that you have a .NRG image. it's not the case. My image is an ISO file.
this inormation appears in terminal when I select the iso file K3b::Iso9660::openArchive no volume descriptors (K3b::CloneTocReader) could not open file "/mnt/WIN7/Users/Strangiato/Desktop/file.iso.toc" (K3b::CueFileParser) could not open file "/mnt/WIN7/Users/Strangiato/Desktop/file.iso.cue" Error loading text-to-speech plug-in "speechd" My ISO file system is UDF.
Hi, regardless of the question why K3B does not recognize the image file as ISO 9660 there stays the question whether and why it then really refuses to write. So please answer the question what happened after you got the warning "Type of image file is not recognizable. Do you want to burn it anyway?" Did you answer "Yes" ? If you only have BD-R media, then better wait with a new attempt until we solved the file format riddle. If you have a BD-RE, then please repeat your burn attempt and record as many info as possible until it really refuses (or starts to burn). ---------------------------------------------------------------------- Now for the ISO riddle: > My image is an ISO file. > My ISO file system is UDF. To all accounts it is not. Program "file" should say "... ISO 9660 CD-ROM filesystem ..." or "... UDF filesystem ..." if an ISO 9660 superblock was present. (As said, UDFs have a ISO superblock which might only lead to one file saying: "This is UDF and not ISO 9660. Mount as UDF to see more files.") > K3b::Iso9660::openArchive no volume descriptors That's ReadISO9660() confirming what program "file" says. Another test would be to try to mount the image file on GNU/Linux. I bet the reply is much like: "mount: wrong fs type, bad option, bad superblock ..." From initial message > I can mount and read the same ISO file using cdemu client. This does not exclude .NRG: https://wiki.archlinux.org/index.php/CDemu states "It enables you to use other disk image formats that contain more than just the standard ISO-9660 filesystem, for instance .bin/.cue, .nrg, or .ccd images. " According to wikipedia, a .NRG file is recognizable by its final 12 bytes. Try this: end=$(ls -l file.iso | awk '{print $5}') start=$(expr $end - 12) echo $start This should tell a large number in the range of 25 billion. Then read 12 bytes from that position of the file: dd bs=1 skip=$start count=12 if=file.iso | od -c If you then read "... N E R O ..." or "N E R 5 ...", then it is an .NRG file (which probably contains your ISO/UDF). > (K3b::CloneTocReader) could not open file "/mnt/WIN7/Users/Strangiato/Desktop/file.iso.toc" > (K3b::CueFileParser) could not open file "/mnt/WIN7/Users/Strangiato/Desktop/file.iso.cue" Might be that K3B looks for other input formats which it understands. .CUE and .TOC are description files for CD layouts. They are usually accompanied by one or more data files with payload. Well, we already know that this is not the case here. Have a nice day :) Thomas
I have no BD-RE available. K3b shows "Type of image file is not recognizable. Do you want to burn it anyway?" immediately after I select the ISO file in "burn image" window. I don't need to start the burning process. I answered "Yes" and no new information appeared in terminal. Command "dd bs=1 skip=$start count=12 if=file.iso | od -c" says dd: invalid number: “” 0000000 I ran this command to mount my ISO sudo mount -o loop file.iso /mnt/imagemiso ISO was successfully mounted and I can read its files. sudo mount -t udf -o loop file.iso /mnt/imagemiso says "fail to configure loop device to file.iso"
Sorry, "sudo mount -t udf -o loop file.iso /mnt/imagemiso" previously failed because kernel update. The command worked after I restart my computer.
Hi, the main riddle now is why the image is not copied to medium after the warning has been accepted and overridden by the user. @Leslie: I propose you create some dummy image file and make test with CDemu whether K3B accepts it for burning. The dummy could be e.g. a compressed tar archive. Maybe you can read and verify it from CDemu after the burn run looks successful. ------------------------------------------------------------------------- > "sudo mount -t udf -o loop file.iso /mnt/imagemiso" [...] worked after > I restart my computer. If the ones say that it is not an ISO 9660 but mount can mount it as UDF, then there remains only one explanation: It is an UDF without ISO 9660 superblock. Quite exotic and not deserving the name file.iso but rather file.udf. (I only have UDFs from mkisofs and Microsoft Inc. DVDs. They all have ISO 9660 superblocks.) What do you get from mount -o loop -t iso9660 file.iso /mnt/imagemiso ? If this refuses then we really have such an UDF. Userland programmers are surprised: I am trying to decipher the magic number definition of "file" for ISO and UDF at e.g. https://sources.debian.org/src/file/1:5.32-1/magic/Magdir/filesystems/?hl=1952#L1937 It looks like the UDF/ISO 9660 distinction by "NSR0" is done only after a "CDROM Filesystem" was detected by the signature of an ISO 9660 superblock. (The latter starts the former by >0 use cdrom See man 5 magic, pseudo-types "use" and "name".) K3B, too, seems to regard UDF as an extension to ISO 9660. > dd: invalid number: “” Something did not work with my proposal to determine the byte number 12 bytes before file end. Maybe you could compute it by hand and insert it into the command line dd bs=1 skip=$start count=12 if=file.iso | od -c Well, since mount -t udf works, my NRG theory loses its probability. Have a nice day :) Thomas
Hi, @Dr. Chapatin: Did you verify that your K3B source does have these lines in in src/misc/k3bimagewritingdialog.cpp ? if (d->foundImageType == IMAGE_UNKNOWN) { if (KMessageBox::questionYesNo(this, i18n("Type of image file is not recognizable. Do you want to burn it anyway?"), i18n("Unknown image type")) == KMessageBox::Yes) { d->foundImageType = IMAGE_RAW; d->imageFile = path; } } The current git state is in https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n873 Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #13) > What do you get from > mount -o loop -t iso9660 file.iso /mnt/imagemiso > ? > If this refuses then we really have such an UDF. I get this mount: /mnt/imagemiso: wrong fs type, bad option, bad superblock on /dev/loop8, missing codepage or helper program, or other error.
(In reply to Thomas Schmitt from comment #14) > Hi, > > @Dr. Chapatin: > Did you verify that your K3B source does have these lines in > in > src/misc/k3bimagewritingdialog.cpp > ? Sorry, can you tell me how I can do it? I use Arch Linux.
Hi, > Arch Linux, K3b 17.11.90 Google brings me to the page of "k3b 1:17.11.90-1" https://www.archlinux.org/packages/kde-unstable/x86_64/k3b/ and after some URL manipulation i get to https://git.archlinux.org/svntogit/packages.git/tree/k3b/kde-unstable/PKGBUILDIt has pkgname=k3b pkgver=17.11.90 source=("https://download.kde.org/unstable/applications/$pkgver/src/$pkgname-$pkgver.tar.xz"{,.sig}) So the source is in https://download.kde.org/unstable/applications/17.11.90/src/k3b-17.11.90.tar.xz Assuming that the tag v17.11.90 marks the state of that release in git, i'd say the fix is already applied at https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp?h=v17.11.90#n873 For now i am clueless why it does not burn the BD-R. The warning is justified but it should not block burning. Have a nice day :) Thomas
mkisofs crashed... Burned media ----------------------- DVD+R Devices ----------------------- CDEmu Virt. CD/DVD-ROM 1.10 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD+R) [DVD-ROM, DVD+R, CD-ROM, CD-R] [SAO, TAO, RAW, SAO/R96R, RAW/R16, RAW/R96R] [%7] K3b::IsoImager ----------------------- mkisofs print size result: 113852 (233168896 bytes) System ----------------------- K3b Version: 18.3.70 KDE Version: 5.38.0 Qt Version: 5.7.1 Kernel: 4.13.16-100.fc25.x86_64 Used versions ----------------------- mkisofs: 1.1.11 growisofs: 7.1 growisofs ----------------------- Executing 'builtin_dd if=/dev/fd/0 of=/dev/sr0 obs=32k seek=0' growisofs command: ----------------------- /usr/bin/growisofs -Z /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:113852 -speed=18 -use-the-force-luke=bufsize:32m mkisofs ----------------------- 113852 I: -input-charset not specified, using utf-8 (detected in locale settings) 0.45% done, estimate finish Thu Dec 14 09:59:32 2017 0.88% done, estimate finish Thu Dec 14 09:59:32 2017 1.32% done, estimate finish Thu Dec 14 09:59:32 2017 1.77% done, estimate finish Thu Dec 14 09:59:32 2017 2.21% done, estimate finish Thu Dec 14 09:59:32 2017 2.64% done, estimate finish Thu Dec 14 09:59:32 2017 3.08% done, estimate finish Thu Dec 14 09:59:32 2017 3.53% done, estimate finish Thu Dec 14 09:59:32 2017 3.96% done, estimate finish Thu Dec 14 09:59:32 2017 4.40% done, estimate finish Thu Dec 14 09:59:32 2017 4.83% done, estimate finish Thu Dec 14 09:59:32 2017 5.28% done, estimate finish Thu Dec 14 09:59:32 2017 5.72% done, estimate finish Thu Dec 14 09:59:32 2017 6.15% done, estimate finish Thu Dec 14 09:59:32 2017 6.59% done, estimate finish Thu Dec 14 09:59:32 2017 7.04% done, estimate finish Thu Dec 14 09:59:32 2017 7.48% done, estimate finish Thu Dec 14 09:59:32 2017 7.91% done, estimate finish Thu Dec 14 09:59:32 2017 8.35% done, estimate finish Thu Dec 14 09:59:32 2017 8.80% done, estimate finish Thu Dec 14 09:59:32 2017 9.23% done, estimate finish Thu Dec 14 09:59:32 2017 9.67% done, estimate finish Thu Dec 14 09:59:32 2017 10.10% done, estimate finish Thu Dec 14 09:59:32 2017 10.55% done, estimate finish Thu Dec 14 09:59:32 2017 10.99% done, estimate finish Thu Dec 14 09:59:32 2017 11.42% done, estimate finish Thu Dec 14 09:59:40 2017 11.86% done, estimate finish Thu Dec 14 09:59:40 2017 12.31% done, estimate finish Thu Dec 14 09:59:40 2017 12.75% done, estimate finish Thu Dec 14 09:59:39 2017 13.18% done, estimate finish Thu Dec 14 09:59:39 2017 13.62% done, estimate finish Thu Dec 14 09:59:39 2017 14.07% done, estimate finish Thu Dec 14 09:59:39 2017 mkisofs calculate size command: ----------------------- /usr/bin/genisoimage -gui -graft-points -print-size -quiet -volid k3b -volset -appid K3B THE CD KREATOR (C) 1998-2017 SEBASTIAN TRUEG, MICHAL MALEK AND LESLIE ZHAI -publisher -preparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/k3b.Et3463 -rational-rock -hide-list /tmp/k3b.bw3463 -joliet -joliet-long -hide-joliet-list /tmp/k3b.hZ3463 -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/k3b.XF3463 mkisofs command: ----------------------- /usr/bin/genisoimage -gui -graft-points -volid k3b -volset -appid K3B THE CD KREATOR (C) 1998-2017 SEBASTIAN TRUEG, MICHAL MALEK AND LESLIE ZHAI -publisher -preparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/k3b.VU3463 -rational-rock -hide-list /tmp/k3b.Tc3463 -joliet -joliet-long -hide-joliet-list /tmp/k3b.mj3463 -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/k3b.OU3463 $ tar -cjf k3b.tar.bz2 k3b $ mv k3b.tar.bz2 k3b.iso
Hi, but mkisofs has no stake in image burning. It _makes_ images. Are you sure you have chosen the right job in K3B ? (Normally i'd ask to run the mkisofs command in a shell and to watch for an abort message, or to try xorrisofs as replacement of mkisofs.) Have a nice day :) Thomas
Hi Leslie Any progress with this problem?
(In reply to Dr. Chapatin from comment #20) > Hi Leslie > Any progress with this problem? Sorry, I can't reproduce the issue easily https://bugs.kde.org/show_bug.cgi?id=387765#c18
You need use "burn image..." option from "tools" menu.
(In reply to Dr. Chapatin from comment #22) > You need use "burn image..." option from "tools" menu. Not easy means blu-ray ISO is not available! > @Leslie: > I propose you create some dummy image file and make test with CDemu > whether K3B accepts it for burning. The dummy could be e.g. a compressed > tar archive. Maybe you can read and verify it from CDemu after the > burn run looks successful. And I used dummy ISO as Thomas suggested, but I can't reproduce the issue, and I even experienced mkisofs' segfault... Oops https://bugs.kde.org/show_bug.cgi?id=387765#c18 I know the steps :) but still thanks for your response!
Hi Leslie I just noticed that the problem affects any ISO image created with nero using udf file system. I created a small ISO file to help you. Download it from here http://www.mediafire.com/file/26outwdcybhtzyp/udf%20image%20created%20with%20nero.iso
Hi, the given URL seems not to work without Javascript. But i found in its lengthy HTML this URL http://download864.mediafire.com/7l3plzb6fzqg/26outwdcybhtzyp/udf+image+created+with+nero.iso When fetched with wget it delivers a file of 9,764,864 bytes. In 2048-bytes block 16, where an ISO 9660 filesystem image would have its Primary Volume Descriptor with magic number {0x01, 'C', 'D', '0', '0', '1'} it has {0x00, 'B', 'E', 'A', '0', '1'}. This is an ECMA-167 Volume Structure Descriptor. "BEA01" means UDF. According to ECMA-167 it is ok to have it there. Linux mounts the image and then reports it as ... type udf ... It will be interesting to learn how K3B manages to circumvent our changeset about unrecognized image formats. (See my first comment in this thread: https://bugs.kde.org/show_bug.cgi?id=387765#c5 ) Have a nice day :) Thomas
(In reply to Dr. Chapatin from comment #24) > Hi Leslie > I just noticed that the problem affects any ISO image created with nero > using udf file system. > I created a small ISO file to help you. > Download it from here > http://www.mediafire.com/file/26outwdcybhtzyp/ > udf%20image%20created%20with%20nero.iso Sorry, the URL is not available... the same story is Google unavailable in my country...
Hi, i have put a copy of the image at http://scdbackup.webframe.org/udf+image+created+with+nero.iso Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #27) > Hi, > > i have put a copy of the image at > http://scdbackup.webframe.org/udf+image+created+with+nero.iso > > > Have a nice day :) > > Thomas @Thomas Thank you so much :) $ md5sum udf+image+created+with+nero.iso 38e92048b0cbc1a366a67acbf78d7f2a udf+image+created+with+nero.iso And I can Burn Image successfully: Burned media ----------------------- DVD+R Devices ----------------------- CDEmu Virt. CD/DVD-ROM 1.10 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD+R) [DVD-ROM, DVD+R, CD-ROM, CD-R] [SAO, TAO, RAW, SAO/R96R, RAW/R16, RAW/R96R] [%7] System ----------------------- K3b Version: 18.3.70 KDE Version: 5.38.0 Qt Version: 5.7.1 Kernel: 4.13.16-100.fc25.x86_64 Used versions ----------------------- growisofs: 7.1 growisofs ----------------------- Executing 'builtin_dd if=/dev/fd/0 of=/dev/sr0 obs=32k seek=0' growisofs command: ----------------------- /usr/bin/growisofs -Z /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:4768 -use-the-force-luke=dao:4768 -dvd-compat -speed=18 -use-the-force-luke=bufsize:32m
Hi, the MD5 checksum matches the one i get here. Somehow the K3B version of Dr. Chapatin is not the same as the one of Leslie. The only idea i have is that Leslie instructs Dr. Chapatin how to download current K3B source and how to build it on his quite modern Archlinux. If it is urgent to get the UDF images onto media, i would advise to try command line tools: growisofs -dvd-compat -Z /dev/sr0=image.iso or xorriso -as cdrecord -v -eject dev=/dev/sr0 image.iso (Arch has xorriso as part of package "libisoburn".) Have a nice day :) Thomas
Hi, just in case somebody wonders: I deleted the uploaded copy of udf+image+created+with+nero.iso . So the link is now supposed to be dead. Have a nice day :) Thomas
I use K3b 18.03.70 installed from AUR (k3b-git package) on my laptop and I can reproduce the problem.
(In reply to Dr. Chapatin from comment #31) > I use K3b 18.03.70 installed from AUR (k3b-git package) on my laptop and I > can reproduce the problem. It is better to provide screenshot step by step, and please attach the debug log, thanks!
I just burned the ISO from my link in a CD-RW. Despite the warning "Type of image file is not recognizable. Do you want to burn it anyway?", if I answer "yes" burning process happens without any problem and I can read the disc and copy its content. But the warning is not correct and it should be eliminated.
Hi, > I just burned the ISO from my link in a CD-RW. So now our changes reached your desktop. Next try whether it works with blu-ray sized images too. > But the warning is not correct and it should be eliminated. The image is not a recognizable ISO 9660 filesystem. The Linux kernel recognizes it, but it recognizes and mounts a lot of filesystems. One could question the reason behind having a confirmation dialog. Back in september 2016 there was a flat refusal on anything that's not ISO 9660, .toc, or .cue/.bin. Maybe K3B should just accept what the user submits. Have a nice day :) Thomas
Why "invalid"? This is a usability issue at least. Softwares does should show messages that can be cause confusion.
Hi, > Why "invalid"? Because it is not an ISO 9660 filesystem, regardless of its suffix ".iso". Insofar the message of K3B is correct. If i was annoyed by the dialog window about unreconized image type, then i'd file a bug with severity "wishlist" saying something like "Please remove the confirmation dialog about unrecognizable image file type" and give the dialog text as pointer to the code: "Type of image file is not recognizable. Do you want to burn it anyway?" I would also point to the changeset https://cgit.kde.org/k3b.git/commit/?id=585067b15d1d3b0d875e092c775f1925e2ba270f which introduced that dialog in order to give a hint about its reason to be. As motivation for my wish i would state that only a small set of types is recognized. Not recognizable are UDF, block-level encrypted ISO 9660, archive files, ... and possibly more legitimate types for burning to optical media. Have a nice day :) Thomas
Created attachment 110020 [details] screenshot Fixing myself: Softwares should not show messages that can cause confusion. The message shown by K3B can induce users to think that the file is corrupted/damaged when in fact it's not. Thank you Thomas, maybe I will open a new report. I noticed that when the ISO file is not recognizable, "Burn image" window shows no info about the file despite burning process is successful (screenshot). I just burned a blu-ray ISO created with Nero on windows 7. Burning proccess was successful again.
Hi, > I noticed that when the ISO file is not recognizable, "Burn image" window > shows no info about the file despite burning process is successful > (screenshot). Ahum. My olde Debian K3B shows with real ISO 9660 a "Filesize", some info from the ISO 9660 Primary Volume Descriptor, and an MD5 sum. Maybe "Filesize" stems from the PVD, too. The messages probably come from function createIso9660InfoItems() https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp?id=0a7848344c470e70a845fa87463317f9c889f5fc#n168 There are more such functions: createCdrecordCloneItems(), createCueBinItems(), createAudioCueItems(). They are all called in slotUpdateImage(), where the confirmation dialog for unknown images is called, too. The message "Md5 sum:" stemms from function calculateMd5Sum(). It is called from slotUpdateImage() for ISO 9660 and some other recognized types. So K3B would need a new function createRawImageItems() which reports similar as e.g. createCdrecordCloneItems(): Detected: Image of unrecognized type Filesize: ... Image file: ... This new function and calculateMd5Sum() would then be called after the line d->foundImageType = IMAGE_RAW; which gets performed when the confirmation dialog has not aborted. Leslie, what do you think about such an augmentation ? Have a nice day :) Thomas