Created attachment 57907 [details] Fix dataLen on readTrackInformation for dataLen <= 6 Version: git (using KDE 4.6.1) OS: Linux On my HL-DT-ST BH10LS30 with an empty BD-R the capacity size was returned as "0 bytes" Investigating in the k3bdevice_mmc.cpp code I found out I have a buggy drive/firmware that returns dataLen = 6 on readTrackInformation request. The code comments state tha buggy firmwares return datalen <=4 and corrects the length. Mine needs a dataLen <=6 test. Using the patch included capacity is correctly returned on my burner and seems working fine (at least much better since I had 0-byte or random capacity report before ...) Reproducible: Always Steps to Reproduce: Insert blank BD-R in BH10LS30, go to the disc capacity tab Actual Results: capacity is shown as 0 bytes Expected Results: actual capacity shown (with patch it reads for me : 2715:25:17 (23.3G) ) Please apply simple patch below. I don't think "6" is a valid value for dataLen on any drive so it shouldn't have side effects
Git commit fb12ab0afd49493df8d33a4e334775d9407ddfa9 by Sebastian Trueg, on behalf of Stephane Berthelot. Committed on 08/08/2011 at 09:39. Pushed by trueg into branch 'master'. Too short track info dataLen returned at least on HL-DT-ST BH10LS30 Workaround the structure len like other drives but extend from 4 to 6 bytes minimum check. This avoids a 0 byte BR-R capacity bug with this drive BUG: 268307 M +1 -1 libk3bdevice/k3bdevice_mmc.cpp http://commits.kde.org/k3b/fb12ab0afd49493df8d33a4e334775d9407ddfa9
Git commit 94bfeeba9d97d7d8b0fc02cc04008acefd5f0168 by Michal Malek, on behalf of Stephane Berthelot. Committed on 08/08/2011 at 09:39. Pushed by mmalek into branch '2.0'. Too short track info dataLen returned at least on HL-DT-ST BH10LS30 Workaround the structure len like other drives but extend from 4 to 6 bytes minimum check. This avoids a 0 byte BR-R capacity bug with this drive BUG: 268307 M +1 -1 libk3bdevice/k3bdevice_mmc.cpp http://commits.kde.org/k3b/94bfeeba9d97d7d8b0fc02cc04008acefd5f0168
*** Bug 243549 has been marked as a duplicate of this bug. ***