K3B fails with error "Could not determine size of of resulting image file"

English Multimedia
1

About half of the time I attempt to burn a K3B data project to DVD, K3B fails with the error “Could not determine size of of resulting image file”.

I have not been able to discover why, and I am very frustrated. >:(

Please help.

My system runs openSUSE 13.1 for x86_64 using the latest K3B from the Packman repository. I also had the same problem using K3B from the KDE Extras repository.

K3B debugging output:


Devices
-----------------------
HL-DT-ST DVDRAM GH24NS50 XP01 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] %7]

K3b::IsoImager
-----------------------
mkisofs print size result: 0 (0 bytes)

System
-----------------------
K3b Version: 2.0.80
KDE Version: 4.14.1
Qt Version:  4.8.5
Kernel:      3.11.10-21-desktop

Used versions
-----------------------
mkisofs: 3.1a24

mkisofs
-----------------------
mkisofs: Warning: Cannot add inode hints with -no-cache-inodes.

mkisofs calculate size command:
-----------------------
/usr/bin/mkisofs -gui -graft-points -print-size -quiet -volid Big Buck Bunny -volset  -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-tux/k3bP24965.tmp -rational-rock -hide-list /tmp/kde-tux/k3bH24965.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-tux/k3by24965.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-tux/k3bm24965.tmp
2

On 2014-10-11 03:16, Max314 wrote:
>
> About half of the time I attempt to burn a K3B data project to DVD, K3B
> fails with the error “Could not determine size of of resulting image
> file”.

> mkisofs print size result: 0 (0 bytes)

That is your problem.

> mkisofs: Warning: Cannot add inode hints with -no-cache-inodes.

And that is the cause.


>   mkisofs calculate size command:
>   -----------------------
>   /usr/bin/mkisofs -gui -graft-points -print-size -quiet -volid Big Buck Bunny -volset  -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-tux/k3bP24965.tmp -rational-rock -hide-list /tmp/kde-tux/k3bH24965.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-tux/k3by24965.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-tux/k3bm24965.tmp

And THAT is the command that you have to trace.


-no-cache-inodes
Enable  or  disable caching inode and device numbers
to find hard links to files.  If genisoimage finds a
hard  link  (a  file  with multiple names), the file
will also be hard-linked on the CD, so the file con-
tents  only  appear once.  This helps to save space.
-cache-inodes is default on Unix-like operating sys-
tems,  but -no-cache-inodes is default on some other
systems such as Cygwin, because it is  not  safe  to
assume  that  inode numbers are unique on those sys-
tems.  (Some versions of Cygwin  create  fake  inode
numbers  using  a  weak hashing algorithm, which may
produce duplicates.)  If two  files  have  the  same
inode  number  but  are  not  hard links to the same
file, genisoimage -cache-inodes will not behave cor-
rectly.  -no-cache-inodes is safe in all situations,
but in that  case  genisoimage  cannot  detect  hard
links,  so the resulting CD image may be larger than
necessary.

I don’t know what “hints” is in this context, but… are you running
under Cygwin? :-o ?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

3

No, I am not running Cygwin. I don’t do Windoze - I have enough problems already. Everything of mine runs on genuine openSUSE Linux for x86_64, straight on top of real hardware and not on a virtual machine.

4

I don’t claim to understand the information above, so I don’t know if the following is helpful or not.

OK, so I get that “-no-cache-inodes” should be disabled. There is an option checbox in K3B under Burn >> Filesystem >> Custom: “Do not cache inodes”, so I unchecked it. I attempted to burn a DVD. Still, K3B fails with the same error “Could not determine size of of resulting image file”. Still no joy, and I still have no idea what is casuing the problem. :frowning:

Debugging output:


Devices
-----------------------
HL-DT-ST DVDRAM GH24NS50 XP01 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] %7]

K3b::IsoImager
-----------------------
mkisofs print size result: 0 (0 bytes)

System
-----------------------
K3b Version: 2.0.80
KDE Version: 4.14.1
Qt Version:  4.8.5
Kernel:      3.11.10-21-desktop

Used versions
-----------------------
mkisofs: 3.1a24

mkisofs calculate size command:
-----------------------
/usr/bin/mkisofs -gui -graft-points -print-size -quiet -volid Big Buck Bunny -volset  -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-tux/k3bw27206.tmp -rational-rock -hide-list /tmp/kde-tux/k3by27206.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-tux/k3bN27206.tmp -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-tux/k3bp27206.tmp
5

On 2014-10-11 05:26, Max314 wrote:

> I don’t claim to understand the information above, so I don’t know if
> the following is helpful or not.
>
> OK, so I get that “-no-cache-inodes” should be disabled.

Yes, I think the same.

> There is an
> option checbox in K3B under Burn >> Filesystem >> Custom: “Do not cache
> inodes”, so I unchecked it. I attempted to burn a DVD. Still, K3B
> fails with the same error “Could not determine size of of resulting
> image file”. Still no joy, and I still have no idea what is casuing the
> problem. :frowning:
>
> Debugging output:
>



> Code:
> --------------------
>
>   Devices
>   -----------------------
>   HL-DT-ST DVDRAM GH24NS50 XP01 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] %7]
>
>   K3b::IsoImager
>   -----------------------
>   mkisofs print size result: 0 (0 bytes)

That is the basic problem…


>
>   System
>   -----------------------
>   K3b Version: 2.0.80
>   KDE Version: 4.14.1
>   Qt Version:  4.8.5
>   Kernel:      3.11.10-21-desktop
>
>   Used versions
>   -----------------------
>   mkisofs: 3.1a24
>
>   mkisofs calculate size command:
>   -----------------------
>   /usr/bin/mkisofs -gui -graft-points -print-size -quiet -volid Gabe Suarez -volset  -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-tux/k3bw27206.tmp -rational-rock -hide-list /tmp/kde-tux/k3by27206.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-tux/k3bN27206.tmp -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-tux/k3bp27206.tmp

But this time we don’t get a message from mkisofs saying why it failed.
And now that I look again at your previous post, I see that the
no-cache-inodes thing was a warning, not an error. So maybe that was not
the problem after all.

I wonder if you can capture a copy of the temporary files created by k3b
above:


/tmp/kde-tux/k3bw27206.tmp
/tmp/kde-tux/k3by27206.tmp
/tmp/kde-tux/k3bN27206.tmp
/tmp/kde-tux/k3bp27206.tmp

Of course, the filenames are random, change on each run, and they are
deleted quickly, so I don’t know how to achieve that, unless they are
deleted /after/ closing the error window, or if the run takes some time
allowing you perhaps to copy the entire /tmp/kde-tux/k3bw27206.tmp
directory somewhere else. Should not be too big. Or, if using btrfs,
make a snapshot of it.

If you manage to do that, then we can try to run that command on a
terminal and find out why it fails. Hopefully.

I wonder why the strings in the mkisofs call are not quoted :-?
There are spaces.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

6

I set up a split-screen where I could simoltaneously monitor K3b and /tmp/kde-tux/. I made many attempts to burn a DVD.

I learned 3 things:

  1. K3b created *.tmp files when burning the disc is successful
    , and deletes those files after burning finishes. 1. K3b does not
    create *.tmp files when burning a disc fails due to “Could not determine size of of resulting mage file” - unless they are created and destroyed so fast that I can not see that process happening as I monitor /tmp/kde-tux/. 1. I can reliably burn a disc if I do it immediately after a power-on or system reset of my computer, after which I can usually burn between 1 or 2 more before K3b fails.

As a test, I changed the “Default Temporary Directory” in K3b >> Settings >> Configure K3b >> Misc to /home/tux/K3b_Temp and attempted to burn a disc, which then failed with “Could not determine size of of resulting image file”. When I looked at the debugging output, I was surprised to discover mkisofs still attempted to use /tmp/kde-tux/. instead of /home/tux/K3b_Temp. There was plenty of space (25 GiB) in /home/tux/K3b_Temp to make a temporary file for a DVD burn, so lack of space could not have been the cause of using the “wrong” temporary directory.

Does any of this information help at all?

I think the cause of the problem is a bug in K3b.

Thank you Carlos for your continues assistance.

7

On 2014-10-12 11:26, Max314 wrote:

> I set up a split-screen where I could simoltaneously monitor K3b and
> /tmp/kde-tux/. I made many attempts to burn a DVD.
>
> I learned 3 things:
>
> - K3b created *.tmp files when burning the disc is -successful-, and
> deletes those files after burning finishes.
> - K3b does -not- create *.tmp files when burning a disc fails due to
> “Could not determine size of of resulting mage file” - unless they are
> created and destroyed so fast that I can not see that process
> happening as I monitor /tmp/kde-tux/.

It could be that fast, yes.

Idea.

Replace /usr/bin/mkisofs with a script of your own that finally calls
the real code in, say, /usr/bin/mkisofs.real, at the end.

In the middle, you capture the command line, locate the tmp files, and
make a copy somewhere.

If you need help for writing such a script, I suggest asking in the
programming-scripting subforum. I don’t know, this instant, how to get
the filenames, unless by position in the command line. That would be
quick…

Otherwise, you’d have to run a copy temp dir loop, copying everything in
sight, fast, to timestamped directories.

> - I can reliably burn a disc if I do it immediately after a power-on
> or system reset of my computer, after which I can usually burn between
> 1 or 2 more before K3b fails.

Curious…

I’m thinking that perhaps the “-gui” option silences verbose debugging
output so that you do not see the problem.

> As a test, I changed the “Default Temporary Directory” in K3b >>
> Settings >> Configure K3b >> Misc to /home/tux/K3b_Temp and attempted to
> burn a disc, which then failed with “Could not determine size of of
> resulting image file”. When I looked at the debugging output, I was
> surprised to discover mkisofs -still- attempted to use /tmp/kde-tux/.
> instead of /home/tux/K3b_Temp. There was -plenty- of space (25 GiB) in
> /home/tux/K3b_Temp to make a temporary file for a DVD burn, so lack of
> space could not have been the cause of using the “wrong” temporary
> directory.

Possibly the configured temp space is used to store the BIG intermediate
image, while temporary files, possibly created with “mktemp”, go to the
default, system, location. Looks like a bug. Those files should be small.

> Does any of this information help at all?

I can only give you ideas for investigation, I can not check it myself
unless the same problem happens to me :wink:

> I think the cause of the problem is a bug in K3b.

Maybe. We don’t know yet…

> Thank you Carlos for your continues assistance.

Welcome :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

8

I have an admittedly ignorant theory about the cause of the problem.

First, a little background on mkisofs commands:


-cache-inodes
Cache inode and device numbers to find hard links to files. If mkisofs finds a hard link (a file with multiple names), then the file will only appear once on the CD. This helps to save space on the CD. The option -cache-inodes is default on UNIX like operating systems. Be careful when using this option on a filesystem without unique inode numbers as it may result in files containing the wrong content on CD. 

If inodes are not cached, mkisofs will revert to the old Rrip Version-1.10 (see -rrip110) and mkisofs will not be able to create correct inode numbers for zero sized files.

On my system, /tmp is a tmpfs memory-backed filesystem, not a hard-drive-backed path. Is it possible that tmpfs creates file inode numbers in such a way that over time it causes a problem with mkisofs?

Or, more simply, is it possible that using tmpfs for /tmp is causing the problem?

9

Yes.

Maybe “/tmp” is too small. It defaults to half of memory. You can try using the “size=” option to increase that.

Solaris used to set the default size to memory+swap (actually, currently free memory + currently free swap). The linux default tmpfs size is too small in my opinion.

It’s been a while since I last use K3b (I mostly use USB in place of DVD or CD these days). But my memory is that K3b wants to put huge files in “/tmp”.

10

The size of /tmp is 7.8 GiB; way more than plenty of space.

I intended to stop using DVD’s entirely - so much that my latest build has no DVD drive nor room for one - until recently, when I decided to give a friend about 60 GiB of files.

Thank you for your assistance nrickert. :slight_smile:

11

On 2014-10-12 18:06, nrickert wrote:
>
> Max314;2669081 Wrote:
>> Or, more simply, is it possible that using tmpfs for /tmp is causing the
>> problem?
>
> Yes.
>
> Maybe “/tmp” is too small. It defaults to half of memory. You can try
> using the “size=” option to increase that.

Using a tmpfs for creating iso images is not wise, IMO. It should be
used for small and shortlived files, so that the are created fast and
they disappear as soon as not needed. Big files should go to disk instead.

(One feature I would like would be a tmpfs as big as needed,
but with a defined limit beyond which it would automatically
overflow to disk).

However, he said that (he) «changed the “Default Temporary Directory” in
K3b >> Settings >> Configure K3b >> Misc to /home/tux/K3b_Temp and
attempted to burn a disc, which then failed with “Could not determine
size of of resulting image file”. When I looked at the debugging
output, I was surprised to discover mkisofs -still- attempted to use
/tmp/kde-tux/. instead of /home/tux/K3b_Temp.»

> It’s been a while since I last use K3b (I mostly use USB in place of DVD
> or CD these days). But my memory is that K3b wants to put huge files in
> “/tmp”.

Yes, the image has to be created somewhere.
It is possible to create and burn the image on the fly, but it is risky.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

12

I have been carefully watching when K3b burns a disc, and as far as I can tell K3b is burning the disc without writing an ISO file to the disk or /tmp. While the disc is burning, I am watching:
/tmp/kde-tux/
/home/tux/tmp (the location I set for writing ISO and temp files)
/home/tux/.kde4/share/apps/k3b/
/home/tux/.kde4/share/apps/k3b/temp

Never at any time during or after burning a disc does an ISO file appear. So, it appears K3b is indeed burning the disc “on the fly” (in real-time, as the ISO image is being created, presumably in memory).

13

On 2014-10-16 06:06, Max314 wrote:
>
> robin_listas;2669181 Wrote:
>> On 2014-10-12 18:06, nrickert wrote:
>> Yes, the image has to be created somewhere.
>> It is possible to create and burn the image on the fly, but it is risky.
>>
> I have been carefully watching when K3b burns a disc, and as far as I
> can tell K3b is burning the disc -without- writing an ISO file to the
> disk or /tmp. While the disc is burning, I am watching:
> /tmp/kde-tux/
> /home/tux/tmp (the location I set for writing ISO and temp files)
> /home/tux/.kde4/share/apps/k3b/
> /home/tux/.kde4/share/apps/k3b/temp
>
> Never at any time during or after burning a disc does an ISO file
> appear. So, it appears K3b is indeed burning the disc “on the fly” (in
> real-time, as the ISO image is being created, presumably in memory).

With a pipe, yes. It works, then.

Actually, it is not k3b who does it; k3b job is just to call
other external tools to do it with the appropriate parameters.
Ie, a wraparound or frontend to third party CLI tools.

I don’t like this “on the fly” burning, though. A delay or some sort of
problem, the pipe empties, and burning stops. Some drives can recover,
some not. Older units could not, and you got another tea cup with a hole
in the middle.

So you are able to burn, no further error with “Could not determine size
of of resulting image file”? A possibility if this happens would be to
tell k3b to actually create the image file instead of burning it. You
can then burn it on a second step.

When you click on “burn” there is a tick for “create image” and another
for “only create image”. The first one disables the “on the fly” burn
you noticed; also, IIRC, the image file remains, it is not deleted
automatically.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

14

It has not been a problem for me. When it works, it writes properly every time.

I can burn about 2 or 3 discs in a row, then K3b fails with “Could not determine size of of resulting image file”. After that, if I reboot my computer, I can again burn 2 or 3 discs in a row, then K3b fails with “Could not determine size of of resulting image file”. After that… (repeat, goto 10)

I tested that idea, and K3b fails with the same error “Could not determine size of of resulting image file”. :frowning:

15

On 2014-10-17 06:06, Max314 wrote:

> robin_listas;2669732 Wrote:
>>
>> So you are able to burn, no further error with “Could not determine size
>> of of resulting image file”?
>>
> I can burn about 2 or 3 discs in a row, then K3b fails with “Could not
> determine size of of resulting image file”. After that, if I reboot my
> computer, I can again burn 2 or 3 discs in a row, then K3b fails with
> “Could not determine size of of resulting image file”. After that…
> (repeat, goto 10)

I was going to say that perhaps it does not like a particular file in
the list of files it has to copy, for some reason we don’t know.
However, if it works again after boot, that should not be the case…
unless the files appear and disapear.

> robin_listas;2669732 Wrote:
>>
>> A possibility if this happens would be to tell k3b to actually create
>> the image file instead of burning it. You can then burn it on a second
>> step.
>>
> I tested that idea, and K3b fails with the same error “Could not
> determine size of of resulting image file”. :frowning:

Ains…

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

16

Please provide logs for more information on console:

$ kdebugdialog --on k3b  # --off to deactivate
$ k3b &>~/k3b.log

We should get information about:

kDebug() << "(K3b::IsoImager) Parsing mkisofs -print-size failed: " << m_collectedMkisofsPrintSizeStdout;
emit infoMessage( i18n("Could not determine size of resulting image file."), MessageError );

from https://projects.kde.org/projects/extragear/multimedia/k3b/repository/revisions/master/entry/libk3b/projects/datacd/k3bisoimager.cpp#L371