[k3b] [Bug 383211] Blu-ray media sizes in fill widget are incorrect
Thomas Schmitt
bugzilla_noreply at kde.org
Mon Aug 7 07:38:30 UTC 2017
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #2 from Thomas Schmitt <scdbackup at 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 the assignee for the bug.
More information about the k3b
mailing list