Showing posts with label wodim. Show all posts
Showing posts with label wodim. Show all posts

Friday, February 12, 2010

cdrecord/wodim woes

Links: Bug w/wodim info  Firmware info


Apparently there has been a fork in what previously was cdrtools. What's apparently happened is the previously robust cdrecord may have had licensing issues so that what's now called cdrecord is actually an alias for wodim. Wodim appears to be Jörg Schilling's freely licensed forefather to his more developed offspring cdrecord. It seems that, once the licensing problems with cdrecord became evident in 2006, the freely licensed, and more rudimentary, wodim was resurrected and included in cdrkit nee cdrtools.

This came up in an attempt to upgrade firmware on an old Pioneer drive that, for some reason, was only burning at about a 1/10th of its rated speeds. When I ran the reliable and familiar
$ cdrecord -scanbus
just to get a part number, I found results under the command wodim, which caused concern. On a web-facing PC, any time I enter one command and another appears, I'm going to ponder the worst scenario. Ah, but it's just a licensing issue.

But a real concern are any limitations with wodim not present in cdrecord. For example, in the same box that I used to have good results with cdrecord, I get these results with wodim.

$ wodim -scanbus

wodim: No such file or directory.
Cannot open SCSI driver!
For possible targets try 'wodim --devices' or 'wodim -scanbus'.
For possible transport specifiers try 'wodim dev=help'.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
the wodim documentation.


$ find -name README.ATAPI

./usr/doc/cdrkit-1.1.9/READMEs/README.ATAPI

Saturday, December 19, 2009

dvd-burning burn-out

Links: Firmware info   Firmware   Latest DVRFlash
It used to be that DVD-burning was pretty straightforward under various distributions:
$ growisofs -dvd-compat -Z /dev/hdc=myvacation.iso
Mostly, all would go smoothly. However, hardware driver advances have been uneven, such as for drives and cables and I/0 ports, firmware, and the BIOS. A DVD drive might read OK, yet might encounter glitches when burning:
$ growisofs -dvd-compat -Z /dev/hdc=myvacation.iso Executing 'builtin_dd if=myvacation.iso of=/dev/sr0 obs=32k seek=0' :-[ PERFORM OPC failed with SK=3h/POWER CALIBRATION AREA ERROR]: Input/output error

A user could run a burn program (eg. Brasero) to overcome manual settings. However, the next problem is the DVD drive, which is supposed to burn at, say, 4-16x, is burning instead at about .5x. That would be something like 680 KbSec, if we agree 1x is supposed to be about 1.32 MB/Sec. This is annoying, to be sure. (Note: one good thing about Brasero, it seems a rare non-K3b burner which will do video, at least if configured properly.

Is the cable the problem, the DVD firmware... some other? The burner only working at 1/8 of its lowest burn speed is going to cause I/O problems and user delays. We could also test the burner's native capacity, as described here, to provide a rough view.

# hdparm -i /dev/sr0
Model=PIONEER DVD-RW DVR-108 , FwRev=1.18 , SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=13395, BuffSize=64kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4
AdvancedPM=no
Drive conforms to: Unspecified: ATA/ATAPI-2,3,4,5

* signifies the current active mode

# hdparm -I /dev/sr0

ATAPI CD-ROM, with removable media
Model Number: PIONEER DVD-RW DVR-108
Serial Number: DKDC451400WL
Firmware Revision: 1.18
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
cache/buffer size = unknown
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 64.0kB
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* Power Management feature set
* PACKET command feature set
* DEVICE_RESET command
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper

# hdparm -tT /dev/sr0

Timing cached reads: 1234 MB in 2.00 seconds = 616.60 MB/sec
Timing buffered disk reads: 22 MB in 3.23 seconds = 6.82 MB/sec

Speed

With an advertised 12x reading speed, a speed of about 16 MB/sec, we see that the true, uncached read speed of 6.82 MB/sec is not coming close. And, as noted above, a write speed of about .682 MB/sec, is anywhere between 1/8 to 1/32 of the advertised 4x-16x write speed range. Hmm...

DMA

The first two checks confirm UDMA (Ultra Direct Memory Access) is working, and that in fact UDMA4, one of the faster forms of UDMA, has been selected. It's also worth the reading the IDE ffile with $ cat /proc/ide/piix.

Cable

UDMA4 requires an 80 pin cable to transfer reliably at the 66 MB/Sec transfer rate. Apparently, avoiding capacitive interference is the issue for using the 80 pin over its 40 pin predecessor. I haven't opened the box, but it's unlikely that an 80 pin cable was used for this drive, since I simply cannibalized two drives from older systems when constructing the system. The 80 pin cables are more reliable as well as backwards-compatible to earlier drives. At any rate, I can note this as potentially a problem, but perhaps not a full explanation.