Bug 505698 - Brasero is burning DVDs very slowly
Summary: Brasero is burning DVDs very slowly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: brasero
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Xavier Lamien
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-12 23:47 UTC by Mace Moneta
Modified: 2010-06-07 14:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-07 14:43:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
qpxtool info on the drives (86.85 KB, image/png)
2009-06-12 23:47 UTC, Mace Moneta
no flags Details
Now brasero burns even slower ;-) (51.78 KB, image/png)
2009-09-17 00:25 UTC, markm
no flags Details

Description Mace Moneta 2009-06-12 23:47:48 UTC
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):
brasero-2.26.2-1.fc11.x86_64
gnomebaker-0.6.4-2.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Insert a DVD
2.Drag some files to the Brasero window
3.Burn
  
Actual results:
A looooong wait

Expected results:
About 5 minutes to burn the disk

Additional info:

$ cdrecord -scanbus
scsibus0:
	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) *
scsibus1:
	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) *

Comment 1 Jörg Schilling 2009-06-13 11:03:04 UTC
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.berlios.de
ftp://ftp.berlios.de/pub/cdrecord/alpha/

cdrecord knows about most firmware bugs and implements
work arounds.

Comment 2 markm 2009-06-14 18:54:48 UTC
(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.

Comment 3 Jörg Schilling 2009-06-15 15:08:06 UTC
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.

Comment 4 Mace Moneta 2009-06-17 06:27:08 UTC
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.

Comment 5 markm 2009-06-17 11:00:58 UTC
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.

Comment 6 Mace Moneta 2009-09-11 08:56:47 UTC
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.

Comment 7 markm 2009-09-17 00:24:47 UTC
(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.  

lucky you!

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).

Comment 8 markm 2009-09-17 00:25:12 UTC
Created attachment 361404 [details]
Now brasero burns even slower ;-)

Comment 9 Mace Moneta 2009-09-17 00:42:48 UTC
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.

Comment 10 markm 2009-09-17 07:43:08 UTC
(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
> supports.

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 :)

Comment 11 Mace Moneta 2009-09-17 08:45:47 UTC
(In reply to comment #10)

> where did you install binaries?

As I said, see comment #4.

Comment 12 markm 2009-09-17 20:28:55 UTC
(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).

Comment 13 ymedians 2009-10-02 03:34:58 UTC
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.

Comment 14 ymedians 2009-10-02 03:58:23 UTC
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.

Comment 15 ymedians 2009-11-05 01:59:51 UTC
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.

Comment 16 Brent R Brian 2009-12-26 16:56:37 UTC
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

Comment 17 Bug Zapper 2010-04-27 14:51:05 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 18 Mace Moneta 2010-06-07 14:43:50 UTC
I don't care about this issue anymore.


Note You need to log in before you can comment on or make changes to this bug.