Bug 444920

Summary:	k3b calculates size incorrectly when deciding when size of media was exceeded
Product:	[Applications] k3b	Reporter:	Ken Arromdee <arromdee>
Component:	Burning/Hardware	Assignee:	k3b developers <k3b>
Status:	REPORTED ---
Severity:	normal	CC:	bugseforuns, juef17, michalm, trueg
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Mageia RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	After first burning attempt Before second attempt

Description Ken Arromdee 2021-11-04 05:38:53 UTC

SUMMARY

STEPS TO REPRODUCE
1. Try to burn a BD-R containing files that seem to almost fill a BD-R

OBSERVED RESULT
The bottom bar will report "Available: ___ of 23.3 GB". The burn will fail with "mkisofs crashed" and the log shows "no space left on device". The bar will then show that the capacity is exceeded, even though it didn't think the capacity was exceeded when you started to burn. In this case it claims that I have Available: 165.6 MB, but after the burn fails, it says capacity is exceeded by 90.4 MB.

EXPECTED RESULT
The amount available when I start should be accurate, so that if I exceeded capacity by 90.4 MB, it says that instead of falsely claiming there is space available.

SOFTWARE/OS VERSIONS
Linux: Linux version 5.10.52-desktop-1.mga8 (iurt@ec2x1.mageia.org) (gcc (Mageia 10.3.0-1.mga8) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Tue Jul 20 17:00:24 UTC 2021
KDE Plasma Version: None (running just fvwm3)
k3b version is 20.12.0 which is not listed above.

ADDITIONAL INFORMATION
I have had this problem over many versions of k3b. It is not new. I don't think it is limited to BDs . If you do have enough space for the burn, the amount available will still go down when you burn it, just not by enough to cause an error.

The difference between the available space at the start and at the end is exactly 256M. On computers, the number 256 looks suspicious. Also, the difference seems too small to be a 1000/1024 mixup.

The log file shows that the mkisofs result has a size of 24852099072. Cursoring to the bottom bar shows that the files total to 24851695616 which is not the same number but close. A BD-R is supposed to have 25025315816 bytes which is indeed about 165M (using powers of 2) over. cdrwtool shows track size 12219392 which multiplied by 2048 gives the expected 25025315816.

The extra space may be used up by overhead, but if so, I have no idea where the overhead comes from, and k3b really should not tell you there is available space when there is not because of overhead. I have Multisession: No and don't know about other possible sources of overhead.

Comment 1 Patrick Silva 2021-11-04 12:11:52 UTC

Can you also reproduce by creating an ISO image?

Comment 2 Ken Arromdee 2021-11-04 13:32:17 UTC

(In reply to Patrick Silva from comment #1)
> Can you also reproduce by creating an ISO image?

I created an ISO image in k3b using "Only create image".  The image is size 24852099072, which is expected given the above.  I then used Tools/Burn Image, with "Start multisession CD" unchecked.  Burning an image doesn't give a bar at the bottom telling you whether you have exceeded capacity.  Same problem however.  It's out of space.

Comment 3 Patrick Silva 2021-11-04 13:57:40 UTC

(In reply to Ken Arromdee from comment #2)
> (In reply to Patrick Silva from comment #1)
> > Can you also reproduce by creating an ISO image?
> 
> I created an ISO image in k3b using "Only create image".  The image is size
> 24852099072, which is expected given the above.  I then used Tools/Burn
> Image, with "Start multisession CD" unchecked.  Burning an image doesn't
> give a bar at the bottom telling you whether you have exceeded capacity. 
> Same problem however.  It's out of space.

I use K3b 21.08.2 on Arch Linux and I'm unable to reproduce by creating  a BD-R ISO image.
I created a data project, added data until free space available was ~70 MiB, K3b successfuly created the ISO image.
Possibly there is a bug with your K3b/mkisofs packages. 

The bar on bottom does not tell you whether you have exceeded disc capacity due to unreadable text. See bug 444942.

Comment 4 Ken Arromdee 2021-11-04 15:35:52 UTC

The text is readable for me; the bar is thicker relative to the text so the text is on the bar.

Comment 5 Ken Arromdee 2021-11-04 15:39:24 UTC

(In reply to Ken Arromdee from comment #4)
> The text is readable for me; the bar is thicker relative to the text so the
> text is on the bar.

To clarify: Burning files produces a bar at the bottom with readable text.  Directly burning an ISO didn't show a bar at all (with or without text) because directly burning an ISO doesn't use that part of the GUI.

Comment 6 juef17 2021-11-06 20:44:39 UTC

Created attachment 143297 [details]
After first burning attempt

This is the status bar after the first burning attempt.

Comment 7 juef17 2021-11-06 20:47:55 UTC

Created attachment 143298 [details]
Before second attempt

Sorry, I'm totally new to this bug reporting system.

So I have encountered what I believe is the same bug. I attempted burning a BD-R XL with about 100 MiB of reported free space for the project. At about 98.5%, the process failed, saying there was no space left on device See attachment 1 [details].png.

Then, I removed about 1.5 GiB from the project and inserted a new blank BD-R XL. The attachment 2 [details].png shows what k3b reported then.

Sorry if this is not clear, as I am not very familiar with k3b and English isn't my first language. I will be glad to provide more details if needed.

Comment 8 Ken Arromdee 2021-11-08 16:58:32 UTC

I think you uploaded the wrong files.

Comment 9 juef17 2021-11-08 18:43:44 UTC

Forgive me, I did upload the right files but I referenced them the wrong way in my previous comment. See attachment 143297 [details] and attachment 143298 [details]. Hopefully this works this time.

Comment 10 Ken Arromdee 2021-11-11 17:20:44 UTC

I found the cause of this, sort of.  growisofs reserves 256M spare area for defect management (see http://fy.chalmers.se/~appro/linux/DVD+RW/Blu-ray/ ).  You can avoid this by adding the parameter -use-the-force-luke=spare:none.

If I add this parameter, the size doesn't suddenly decrease by 256M, and everything works.

So the problem is a mismatch between k3b calling growisofs using default behavior that creates 256M spare, but calculating the available size in a way that doesn't take the 256M spare into account.

That page doesn't mention BD-R XL, but I would be unsurprised if juef17 had this same problem for his BD-R XL.