Description of problem: Tried to use k3b to burn some movie files to a blu-ray data disk. With the blank media in the drive, it tells me I have 3.1 TB available, which makes it hard to know when you've tried to put too many files on the media. In fact, the media is Verbatim BD-R 25 GB 6x media. Version-Release number of selected component (if applicable): k3b-2.0.2-5.fc15.x86_64 How reproducible: Every time Steps to Reproduce: 1.see above 2. 3. Actual results: Wacko size info. Expected results: It should know the media is 25GB. Additional info: If I bring up the screen with media info, it appears to have the right information, so it seems like something is going bad in the arithmetic on the way to the GUI. The drive I'm using is an LG: BD-RE WH12LS30
Created attachment 525904 [details] screenshot of k3b media info page I was remembering wrong - the media info page also has the wrong size info for the media. The screenshot is attached here. On the other hand, the dvd+rw-mediainfo tool seems to get the right info: zooty> dvd+rw-mediainfo /dev/sr0 INQUIRY: [HL-DT-ST][BD-RE WH12LS30 ][1.00] GET [CURRENT] CONFIGURATION: Mounted Media: 41h, BD-R SRM Current Write Speed: 12.0x4495=53946KB/s Write Speed #0: 12.0x4495=53946KB/s Write Speed #1: 10.0x4495=44955KB/s Write Speed #2: 8.0x4495=35964KB/s Write Speed #3: 6.0x4495=26973KB/s Write Speed #4: 4.0x4495=17982KB/s Write Speed #5: 2.0x4495=8991KB/s GET [CURRENT] PERFORMANCE: Write Performance: 5.0x4495=22323KB/s@0 -> 12.0x4495=53859KB/s@12219391 Speed Descriptor#0: 02/12219391 R=44879KB/s W=53946KB/s Speed Descriptor#1: 02/12219391 R=44879KB/s W=44955KB/s Speed Descriptor#2: 02/12219391 R=44879KB/s W=35964KB/s Speed Descriptor#3: 02/12219391 R=44879KB/s W=26973KB/s Speed Descriptor#4: 02/12219391 R=44879KB/s W=17982KB/s Speed Descriptor#5: 02/12219391 R=44879KB/s W=8991KB/s READ DISC INFORMATION: Disc status: blank Number of Sessions: 1 State of Last Session: empty "Next" Track: 1 Number of Tracks: 1 READ FORMAT CAPACITIES: unformatted: 12219392*2048=25025314816 00h(3000): 11826176*2048=24220008448 32h(3000): 11826176*2048=24220008448 32h(25000): 7369728*2048=15093202944 32h(1000): 12088320*2048=24756879360 READ TRACK INFORMATION[#1]: Track State: invisible incremental Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 12219392*2KB Track Size: 12219392*2KB READ CAPACITY: 0*2048=0
Looks like the capacities are detected inside K3b (not by Solid or some external program), in libk3bdevice/k3bdevice.cpp.
I just tried it in fedora 16, and it gets closer: It only thinks there are 2.2 TB on the media in f16 :-). k3b-2.0.2-5.fc16.x86_64 is the f16 version installed.
Created attachment 527055 [details] screenshot of patched k3b OK, I have no idea if this is a legitimate change, but I noticed that the dvd+rw-mediainfo tool always uses a read of media format capacity for the size it prints, but k3b does something completely different with the MEDIA_BD_R_SRM case my media happens to fall into (trying to dig up last track and compute capacity from the offset and size). I built k3b from the source rpm after moving the case for MEDIA_BD_R_SRM down to the next case which only handles MEDIA_BD_RE as written, but looks like it is reading media format capacity judging from the name of the function it is calling. That produced a considerably more realistic size, but I don't actually know if the 23GB value is accurate either - that matches the "formatted" size that dvd+rw-mediainfo prints, and I don't know if formatted size is the right size to use for BD_R media or not (I could imagine formatting overhead might only apply in the case of erasable media). In any case, I think the code doing the last track calculation must be completely bogus. Perhaps it should be digging up the unformatted size the way dvd+rw-mediainfo does it?
Created upstream bug report: https://bugs.kde.org/show_bug.cgi?id=283693
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping