Description of problem: In the drive properties dialog, Brasero 0.7.1 (and 0.7.0) displays even CD-burning speeds, e.g. 1x-3x-5x-7x-etc instead of 2x-4x-6x-8x-etc. This way, most people can't burn, except for burning at the maximum speed. Version-Release number of selected component (if applicable): 0.7.0, 0.7.1 Additional info: Upstream bug 525501.
Created attachment 299871 [details] Possible patch Someone please test it, it works with me. The fix is absolutely trivial, and it was only tested on systems that had correct speeds with Brasero 0.6.1 (*NOT* 0.6.90!!!) and incorrect speeds with 0.7.0 and 0.7.1.
Can't reproduce here, I'm seeing correct burning speeds. You may want to report your CDROM type ("sudo sginfo /dev/sr0") on the upstream bug.
I am away from my laptop right now, but it happens *always*, with several distros (at least Fedora, Ubuntu, Parsix), and on both a laptop and a PC! Both are LG units: -- laptop unit: HL-DT-ST DVDRAM GSA-T20N. Capabilities: CD-R: 24x; DVD-R/DVD+R: 6x ZCLV. -- PC unit: GCE-8526B. Capabilities: CD-R: 52x. These models are reported in dmesg anyway. I can't run sginfo, but these units are *very* popular. I can't believe that *only* the LG units report speeds in KiB or in KB that get computed in incorrect Nx speed values in Brasero >= 0.6.90!
Please also report the output of # sg_modes /dev/sr0
[root@chapelier ~]# sginfo /dev/sr0 INQUIRY response (cmd: 0x12) ---------------------------- Device Type 5 Vendor: HL-DT-ST Product: DVDRAM GSA-T20N Revision level: WP03 [root@chapelier ~]# sg_modes /dev/sr0 HL-DT-ST DVDRAM GSA-T20N WP03 peripheral_type: cd/dvd [0x5] Mode parameter header from MODE SENSE(10): Mode data length=246, medium type=0x70, specific param=0x00, longlba=0 Block descriptor length=0 >> Read-Write error recovery, page_control: current 00 01 0a 80 63 00 00 00 00 03 00 00 00 >> Write parameters, page_control: current 00 05 32 60 05 08 10 00 00 00 00 00 00 00 20 00 96 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 00 >> Caching, page_control: current 00 88 0a 04 00 08 00 00 00 00 80 00 80 >> CD device parameters (obsolete), page_control: current 00 8d 06 00 0b 00 3c 00 4b >> CD audio, page_control: current 00 0e 0e 04 00 00 00 00 4b 01 ff 02 ff 00 00 00 00 >> LU control, page_control: current 00 18 1a 00 01 00 01 00 00 00 01 00 01 00 01 00 00 10 00 01 00 01 00 01 00 01 00 01 00 00 >> Power condition (mmc), page_control: current 00 9a 0a 00 03 00 00 00 64 00 00 01 40 >> Fault/failure reporting control (mmc), page_control: current 00 9c 0a 00 04 00 00 02 58 00 00 00 00 >> Timeout and protect, page_control: current 00 9d 08 00 00 00 00 00 1e 2a 30 >> page_code: 0x20, page_control: current 00 a0 0a 01 00 00 64 00 03 00 00 00 00 >> MM capabilities and mechanical status (obsolete), page_control: current 00 2a 3e 3f 37 f1 73 29 23 10 8a 01 00 08 00 10 8a 10 00 00 10 8a 10 8a 00 01 00 00 00 00 10 8a 00 04 20 00 00 10 8a 00 00 0b 06 00 00 06 e4 00 00 02 c2 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [root@chapelier ~]# Frankly, I don't see anything useful here!?
Moving discussion on upstream bug.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fixed upstream, but backporting the patch is non trivial, so closing.