Created attachment 107116 [details] patch to correct BD capacity for 25 and 50 "GB" discs When adding files to a data project without a blank disc in the drive, k3b will use the built-in capacities for Blu-ray media. However, these are wrong. k3b thinks that blu-ray media is 25 or 50 GB ("GiB"), but it is actually only slightly more than 25/50 "salesman GB", a little less than 23.3 "real" GB. This means that the capacity gauge cannot be used precisely when making data projects, and one must resort to shell tools, or one's favorite pocket calculator. 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. The fix is very simple, and I have attached a patch. In fact, one can see from the adjacent code comment that the author knows the values are wrong.
Hi Henryk, Thanks for your patch! but I am not familiar with it, so I can't review it, ask Thomas for help :) Regards, Leslie Zhai
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
Hi, it's too early in the morning. My post needs mending: > 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. Ignore the first three words "The real size". They are remnants of an older attempt to phrase what i mean. > [code] Duh. Wrong wiki language. Well the marked text still looks readable enough on http:''bugs.kde.org. > format_defectmgt_max > format_defectmgt_min > blank=format_defectmgt_none > format_by_index_<number> > blank=format_defectmgt_payload_<size> They all need the prefix "blank=" in order to be recognizable cdrskin options: blank=format_defectmgt_max blank=format_defectmgt_min blank=format_defectmgt_none blank=format_by_index_<number> blank=format_defectmgt_payload_<size> Further i see that i first propose to examine the formatted sizes and later propose to enforce them. Both is appropriate depending on the formatting situation which K3B encounters. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #2) > 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. yes, I need your help :) > > (I guess a native speaker of english ROFLs all the day when seeing > us foreigners stumbling through the language.) Sorry for my poor English :( and I experienced Brain spasm last weekend when I was bathing, I feel really difficult to read and write English... perhaps I need some medicine to relieve my brain high pressure... > > ---------------------------------------------------------------- > > 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. Sorry for my illness, please give me some hint about how to get the correct MediaSizeBluRay25Gb/MediaSizeBluRay50Gb value before the buring job. > > 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
Dear Albert, I need your help if I pass away, please find another maintainers for K3B if the repository keep quiet more than one year, it means I pass away... I experienced Brain spasm twice last weekend when I was bathing, I feel really difficult to read and write English... I seriously hurt my head several times ago, sorry fellows. Regards, Leslie Zhai
Hi, > I experienced Brain spasm [...] > I feel really difficult to read and write English Go see a doctor. A good one, who does what is needed, not just what he can. > please give me some hint about how to get the correct > MediaSizeBluRay25Gb/MediaSizeBluRay50Gb value before the buring job. Let's look for occurences. Since i don't see a code search facility in k3b.git, i use the Debian source tree (which might be a bit outdated): https://codesearch.debian.net/search?q=package%3Ak3b+MediaSizeBluRay25Gb which yields: -------------------------------------------------------------------------- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=729#L729 Here MediaSizeBluRay25Gb is used to detect the media type. The value to which it gets compared stems from KConfigGroup c.readEntry( "default media size", 0 ); For now i assume, that this function returns one of the sizes from the list where MediaSizeBluRay25Gb is defined. -------------------------------------------------------------------------- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=373#L373 http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=375#L375 seems to set the displayed size to a caller defined value. (I riddle about the combination of exact sizes like MediaSizeDvd4Gb and naive values like 2306867. A normal single layer DVD has 2295104 blocks. DVD-RAM has less.) -------------------------------------------------------------------------- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=585#L585 I really wonder where the value set by this function is used. -------------------------------------------------------------------------- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=822#L822 seems to set the displayed size to one of the defined sizes, depending on media type and d->doc->length().lba(). The type of "d" is somewhere in the C++ spaghetti definitions. It seems to be a class which describes some device aspects. (Zorry, i am an old C programmer. Maybe we need a C++ expert.) ------------------------------------------------------------------ All in all the symbols MediaSizeBluRay25Gb and MediaSizeBluRay50Gb seem not to be used for internal program control purposes but rather for display only. (I can be wrong. Better check yourself, too.) If so, then the change should beautify the user interface but not trigger decisions whether the intended data fit on the loaded media. So: The patch proposal looks good to me. Have a nice day :) Thomas
Dear Thomas, > Go see a doctor. A good one, who does what is needed, not just what he can. Thank you! I will see a doctor tomorrow to take ultrasonography consultation. my eyes were congested this morning, and right now not congested any more, I took photo via webcam to check my status, but only headache... not feel good, maybe some part effect my reading and writing functions, a lot of typo... thanks for web browser's spell check. > The type of "d" is somewhere in the C++ spaghetti definitions. D-pointer https://bugs.kde.org/show_bug.cgi?id=344392#c28 the good news is my brain's memory function is OK :) > So: The patch proposal looks good to me. Then could I apply Henryk Hecht's patch? sorry for my reading function... Regards, Leslie Zhai
Hi, Leslie, i am crossing fingers for you and your health. My best wishes. Get well soon. > Then could I apply Henryk Hecht's patch? sorry for my reading function... Do it. Have a nice day :) Thomas
Git commit d70ef9a8c89e954a223f25e25bd5c2202aefaa2e by Leslie Zhai. Committed on 08/08/2017 at 02:15. Pushed by lesliezhai into branch 'master'. Fix Blu-ray media sizes in fill widget are incorrect issue. A patch by Henryk Hecht! Thank you! I am better now :) I will fix my Cerebral vasospasm issue, and take ultrasonography consultation this afternoon. Reviewed By: Thomas Schmitt M +2 -3 libk3b/core/k3bglobals.h https://commits.kde.org/k3b/d70ef9a8c89e954a223f25e25bd5c2202aefaa2e