Hello, This is a known problem for a lot of distros, and apparently only the cdrkit devs aren't unable to reproduce it. Wodim ignores the speed setting: $ wodim speed=2 dev=/dev/sr0 /path/to/img.iso wodim: No write mode specified. wodim: Asuming -tao mode. wodim: Future versions of wodim may have different drive dependent defaults. wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identification : 'CD/DVDW SN-S082D' Revision : 'SS03' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd). Driver flags : SWABAUDIO BURNFREE Supported modes: PACKET SAO Speed set to 11080 KB/s Starting to write CD/DVD at speed 8.0 in real unknown mode for single session. Last chance to quit, starting real write in 4 seconds.^C So as you can see, the specified speed setting is ignored, and wodim always tries to write at full speed. This unfortunately means a lot of ruined dvds, and no workaround possible. This also seems to happen with cd's, although I haven't tested it myself. This should affect most of the burning frontends (k3b, brasero, gnome baker, etc...).
This bug can cause unnoticed loss of data, because even if the writing fails, wodim will not give you any error. For some people it will make it impossible to reliably burn dvds (it took me months to figure out why some of my dvd's ended up corrupted). So this should be at least a "major" ;) Anyway, I found a suitable workaround. This is the hunk of code where the bug must be, probably the cdr_set_speed_dummy (line 1022 of wodim/wodim.c): if ((*dp->cdr_set_speed_dummy)(usalp, dp, &speed) < 0) { errmsgno(EX_BAD, "Cannot set speed/dummy.\n"); if ((flags & F_FORCE) == 0) comexit(EX_BAD); } dp->cdr_dstat->ds_wspeed = speed; /* XXX Remove 'speed' in future */ The workaround is to comment out the last line. This should save people some money before it gets corrected upstream.
(In reply to comment #1) > The workaround is to comment out the last line. This should save people some > money before it gets corrected upstream. Nevermind this, it still burns at 8x, and results in a corrupted dvd... :(
Note to self: This occurs with all versions of cdrkit in portage.
cdrkit is completely dead for ages... people should either go back to cdrtools or, if they don't like its license, try alternatives like libburn
I think dvd+rw-tools are the most common choice these days.
I am unsure... they are also pretty much abandoned by upstream :/ As far as I remember, only libburn and cdrtools are still actively developed
# Michał Górny <mgorny@gentoo.org> (05 Jun 2017) # (on behalf of Treecleaner project) # Abandoned upstream and downstream. Buggy to the point of producing # corrupted media. Use the original app-cdr/cdrtools or one of the many # other alternatives (app-cdr/dvd+rw-tools, dev-libs/libburn...). # Removal in 30 days. Bugs #254312, #591778. app-cdr/cdrkit
commit 05f5454a3108c4ffaeae8be59f4a32c74048293c Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Wed Jul 5 12:17:52 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Wed Jul 5 12:35:12 2017 app-cdr/cdrkit: Remove last-rited pkg, #591778
