https://bugs.kde.org/show_bug.cgi?id=444920
Bug ID: 444920 Summary: k3b calculates size incorrectly when deciding when size of media was exceeded Product: k3b Version: unspecified Platform: Mageia RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Burning/Hardware Assignee: k...@kde.org Reporter: arrom...@gmx.com CC: mich...@jabster.pl, tr...@kde.org Target Milestone: --- 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 (i...@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. -- You are receiving this mail because: You are watching all bug changes.