After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 366183 - Wrong "maximum" burn speed
Wrong "maximum" burn speed
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
unspecified
Other Linux
: Normal major
: 0.5
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-10-28 09:37 UTC by Michael Monreal
Modified: 2007-03-30 18:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Monreal 2006-10-28 09:37:28 UTC
I burned the xen live-cd iso using brasero yesterday, writing speed set to "max". I noticed the burn process was actually at about 4x speed, where the same process using nero uses 40x speed. Is thsi a bug with brasero or perhaps the libburn backend?
Comment 1 Philippe Rouquier 2006-11-03 18:46:13 UTC
If you used, libburn backend, then maybe. But it could also be a problem with the speed chosen by brasero as the max one. It's hard to say. Do you have a reliable way to trigger this bug ?
Comment 2 Michael Monreal 2006-11-03 19:56:24 UTC
I have disabled libburn now. Had do burn a few discs yesterday but I used nero for that because I needed it to be fast. I will try again with brasero as soon as I have something to burn.

I *think* triggering this would be as easy as burning a CD with brasero (at least with libburn). I'll update the bug with more information as I get them.
Comment 3 Michael Monreal 2006-11-07 11:29:37 UTC
Ok, I got myself a bunch of CD-Rs and used brasero to burn a bunch of ISOs. Not using libburn, the speed was normal. So this bug seems to only affect brasero+libburn...
Comment 4 Philippe Rouquier 2006-11-07 16:09:07 UTC
I think the problem is in fact in HAL itself. HAL sets the speed of a drive just once (possibly when it starts). Now if you read mmc specs, they state that a drive reports its speeds (write/read) according to the media inside. That is, if you have a CDRW inserted, the drive reports 10x, a CDR around 30x (at least) for modern drive, and so on. So if you have, say, a CDRW when HAL starts up, the speed will remain at 10x whatever the media you insert afterward because HAL doesn't poll for the new speed when the media changes for a drive.

An easy test is to use hal-device-manager, and start HAL with a CDRW inside. HAL reports 10x or 4x (according to the speed of your CDRW) whatever the media you insert.

Two solutions: fix it in HAL or write a small scsi library for 0.6.X.
Comment 5 Mario Danic 2007-01-13 18:19:14 UTC
Speed detection has been worked on in SVN of libburn, and works quite reliable now.
Comment 6 Benjamín Valero Espinosa 2007-03-21 14:21:16 UTC
I have the same problem. The maximum burning speed of my drive is 56x, but when I insert some old rewritable CD (4x or 10x) Brasero still shows 56x as maximum speed.

Perhaps, this is the same bug that #359258.

(In reply to comment #5)
> Speed detection has been worked on in SVN of libburn, and works quite reliable
> now.

Well, at least in Ubuntu Feisty, the version 0.5.2 doesn't depend on libburn anymore, so this is not the solution :(
Comment 7 Philippe Rouquier 2007-03-30 18:00:35 UTC
I fixed this bug in brasero. Thanks to the new SCSI library it can retrieve the right speeds by itself. I also sent a bug report to HAL but no answer so far. Once it is fixed in HAL I'll see if this fix should be kept.
Comment 8 Philippe Rouquier 2007-03-30 18:01:45 UTC
I forgot to mention this is fixed in trunk and will be fixed in trunk only so don't expect improvements in stable except if it is fixed in HAL in the mean time.