Red Hat Bugzilla – Bug 505698
Brasero is burning DVDs very slowly
Last modified: 2010-06-07 10:43:50 EDT
Created attachment 347685 [details]
qpxtool info on the drives
Description of problem:
I burned some files to DVD using brasero, and the burn progressed at about 1x speed. I burned a second disk with gnomebaker, and it burned at the expected 16x.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Insert a DVD
2.Drag some files to the Brasero window
A looooong wait
About 5 minutes to burn the disk
$ cdrecord -scanbus
0,0,0 0) *
0,1,0 1) 'HL-DT-ST' 'DVD-RAM GH22LS30' '1.01' Removable CD-ROM
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
1,0,0 100) 'HL-DT-ST' 'DVD-RAM GH22LS30' '1.01' Removable CD-ROM
1,1,0 101) *
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) *
RedHat does not distribute crecord but a defective fork
(called wodim) that cannot even be legally distributed.
The clone does not offer working DVD support.
I recommend you to removed wodim and to replace it
with recent original software.
cdrecord knows about most firmware bugs and implements
(In reply to comment #1)
> RedHat does not distribute crecord but a defective fork
> (called wodim) that cannot even be legally distributed.
telling people things like that is like asking them to change a distro.
I am the Author of the original software and for this
reason, I am the Copyright holder of the fork as well.
RedHat and Fedors ignore the legal problems as well as the
quality problems and so do suse, debian, ubuntu and mandriva.
What I can do as Author, is to inform the users. What you as user
do as conclusions is your private decision.
I downloaded cdrtools-2.01.01a60.tar.bz2 from the above link, and built it. I then:
- renamed /usr/bin/wodim to /usr/bin/wodim.orig
- move the newly built cdrecord to /usr/bin/wodim
I tried a burn with brasero (via the nautilus CD/DVD creator), and the same slow burn occurred.
Since gnomebaker also uses wodim, but works at full speed, I would guess that the two are passing different options to wodim.
I restored the original wodim and removed the newly built cdrecord.
I did similar test:
installed cdrecord, burnt one dvd with brasero - it gets burnt correctly (finally!) but at slow speed (2x), then I burnt dvd with K3b and it burns at full speed.
for the record: when I burn dvds with wodim, the dvd gets burnt successfully but on the disc surface you can see there is a gap 1 mm wide just at the beginning of the burnt data which makes disk useless.
also: regardless of the backend I use (wodim or oryginal cdrecord), brasero and k3b are not able to eject dvd after burning and wait for it to be reinserted before they start to validate burning process.
I found that the problem is wodim. If brasero uses growisofs instead, the problem does not occur. To work around the situation:
1. Run gconf-editor
2. Go to apps, brasero, config, priority.
3. Change wodim-burn to "-1".
4. Change growisofs-burn to "1".
5. Quit gconf-editor
6. Set a manual burn speed in the brasero window dialog when burning (e.g. 8x or 16x).
With this change, brasero is able to burn at full speed.
(In reply to comment #6)
> I found that the problem is wodim. If brasero uses growisofs instead, the
> problem does not occur. To work around the situation:
> 1. Run gconf-editor
> 2. Go to apps, brasero, config, priority.
> 3. Change wodim-burn to "-1".
> 4. Change growisofs-burn to "1".
> 5. Quit gconf-editor
> 6. Set a manual burn speed in the brasero window dialog when burning (e.g. 8x
> or 16x).
> With this change, brasero is able to burn at full speed.
on machine wodim burns at 2x speed, with your changes done it burns at... mere 0.3x speed :-( I've tried two times - once with a speed set to “maximum”, second time manually set to “8x” (maximum for my burner), same result. See image attached.
BTW: wodim is THE PROBLEM, it's old fork of cdrecord and not maintained - to solve wodim's problem just get genuine cdrecord from http://cdrecord.berlios.de/private/cdrecord.html and use K3B to burn cds/dvds (K3B will make use of genuine cdrecord).
Created attachment 361404 [details]
Now brasero burns even slower ;-)
Marek - I tried "genuine cdrecord" from ftp://ftp.berlios.de/pub/cdrecord/alpha/ (see comment #4). No change here. The only thing that worked was switching to growisofs, which brasero apparently supports.
It seems that there are burners that work better with wodim and those that work better with growisofs. The only real problem I see is that the brasero user interface doesn't allow for the selection.
Could that be made a user visible option, so that end-users don't have to stumble through gconf-editor? That seems to be the only way this bug will ever get resolved.
(In reply to comment #9)
> Marek - I tried "genuine cdrecord" from
> ftp://ftp.berlios.de/pub/cdrecord/alpha/ (see comment #4). No change here.
> The only thing that worked was switching to growisofs, which brasero apparently
where did you install binaries? by default they go to /opt/schily/bin and braser will make no use of them. K3B will use them if they are present in /opt/schily/bin.
> It seems that there are burners that work better with wodim and those that work
> better with growisofs. The only real problem I see is that the brasero user
> interface doesn't allow for the selection.
In same scenarios yes, wodim works, but it is still an old fork which is not maintained. check out the http://www.cdrkit.org/ - it says latest version of wodim is dated... 2008/10/26 while cdrtools are updated constantly, I've just compiled version dated 2009/09/15 (two days old!).
> Could that be made a user visible option, so that end-users don't have to
> stumble through gconf-editor? That seems to be the only way this bug will ever
> get resolved.
Debian is on course to drop wodim and include genuine cdrtools, Ubuntu will follow, so let's hope Fedora developers will follow them too :)
(In reply to comment #10)
> where did you install binaries?
As I said, see comment #4.
(In reply to comment #11)
> (In reply to comment #10)
> > where did you install binaries?
> As I said, see comment #4.
right... I guess cdrecord from latest version of cdrtools has incompatible api to wodim (wodim is a fork, it has been forked in 2006?). I suspect brasero can make use of wodim, but won't be able to make use of the latest version of cdrtools.
when you check k3b's config, you'll see it's pointing to /opt/schily/bin to make use of genuine cdrtools and probably that's why they work for me fine (with k3b).
I have the same problem with every DVD that I burn. I'm using an LG GSA-T10N DVD burner. Brasero burn extremely slow (2x or under) and checksum of burn fails saying 'You do not have the required permissions to use this drive'. Burned data is always fine, but is extremely slowly and checksum fail.
What is the backend used by nautilus-cd-burner? Brasero burn very slow under Fedora 10 too, under Fedora 10 nautilus-cd-burner burn as expected.
Disabling File Checksum and Image Checksum in Brasero Preferences I get burning time like old nautilus-cd-burner, burning 4.2 GB of data into a DVD take about 12 minutes. But, this is disabling both checksum pluginn of Brasero.
The errors on this bug report seem to go hand in hand with other bug reports:
549939 532896 531361 530801 528080 513979 507121 505698
Attachments were posted to 549939
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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:
I don't care about this issue anymore.