https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #2 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > ask Thomas for help :) Shouldn't that have been "asking Thomas for help" ? Your statement sounds like you urge Henryk to ask me. But you Cc'ed me to this bug. So i under stand that you ask me. (I guess a native speaker of english ROFLs all the day when seeing us foreigners stumbling through the language.) ---------------------------------------------------------------- This change is an improvement over the wrong values which are hardcoded currently. The real size given the fact that growisofs always formats BD-R and that all burn programs have to format BD-RE, a hardcoded size seems wrong on the first hand. The BD payload size varies with formatting. One can ask the drive when a still formattable medium is inserted. Here with a blank single layer BD-R: [code] $ dvd+rw-mediainfo /dev/sr4 ... READ FORMAT CAPACITIES: unformatted: 12219392*2048=25025314816 00h(3000): 11826176*2048=24220008448 32h(0): 11826176*2048=24220008448 32h(0): 5796864*2048=11871977472 32h(0): 12088320*2048=24756879360 ... [/code] or [code] $ cdrskin dev=/dev/sr4 --list_formats -toc ... Format status: unformatted, up to 23866.0 MiB Format idx 0 : 00h , 11826176s , 23098.0 MiB Format idx 1 : 32h , 11826176s , 23098.0 MiB Format idx 2 : 32h , 5796864s , 11322.0 MiB Format idx 3 : 32h , 12088320s , 23610.0 MiB ... Media blocks : 0 readable , 12219392 writable , 12219392 overall ... [/code] These sizes from 11 GB to 25 GB are only a rough overview what is possible. One may format to about any payload size. So one should examine where the values MediaSizeBluRay25Gb and MediaSizeBluRay50Gb are used, whether the medium is present and already formatted, and to which size it will be possibly formatted during the burn run. As said, growisofs formats all BD by default. One can force it to use maximum media payload size by option [code] -use-the-force-luke=spare=none [/code] dvd+rw-format has option "-ssa" which besides the documented "none", "default", and "max", also takes "min" or a number with suffixes "G", "M", "K" which it obviously treats as merchants GB, MB, KB with a block size of 2000 rather than 2048. An adventurous computation which is wrong at least with MB and GB. (KB depends on what Andy Polyakov intended "K" to be exactly: 1000 or 1024.) See: https://sources.debian.net/src/dvd%2Brw-tools/7.1-11.1/dvd%2Brw-format.cpp/#L273 cdrskin does not format BD-R by default. One would have to use an option from the following list [code] format_defectmgt_max format_defectmgt_min blank=format_defectmgt_none format_by_index_<number> blank=format_defectmgt_payload_<size> [/code] where "<number"> picks a size from the --list_formats output and "<size>" is the decimal number of desired payload blocks. BD-RE must get formatted. If no blank=format_.., is given, then the default size as of format "00h" is used. Normally: 23098 MiB. Henyk Hecht wrote: > I think this bug is at least a couple of years old; I am surprised that > it is still around, and that no one has reported it. Both, unpatched and patched numbers, are not overly significant. Decisive is the payload size when burning begins. growisofs is not very good in this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699186 So on unformatted BD media K3B should decide which size it wants, enforce that size, and use it for its own calculations. On already formatted BD-R, it must use the currently formatted size. Already formatted BD-RE could be re-formatted to a different size. But that's unusual. (Dunno whether it does harm if done too often.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
