dvd+rw-tools: Hardware Compatibility Notes

Background information

MMC specification is evolving all the time and MMC compliance is therefore somewhat fuzzy term. The situation is intensified by the fact that sometimes specification leaves room for ambiguous interpretation and it does get misinterpreted by manufacturers. On the other hand, one of dvd+rw-tools design rules is to be a "common denominator" for all units. So that whenever you see an announcement that "new update adds support for some particular unit," it doesn't actually mean that e.g. growisofs recognizes the unit in question and modifies its behaviour accordingly. It rather means that it permits for some particular vendor dialect/interpretation without breaking backward compatibility. This approach unfortunately doesn't guarantee that dvd+rw-tools will perform exactly as expected in every possible situation, which in turn implies that there might be a need for some vendor-specific procedures. This is what these notes are about.

Keep in mind that most information provided on this page is contributed, or in other words based on user feedback. I therefore can not personally guarantee its accuracy, and welcome all kind of input, preferably through <cdwrite@other.debian.org>.

NEC ND-1x00 derivatives fail with "[software] write protected" code...
Apparently it happens with DVD+RW media formatted in a recorder unit of different brand. This is firmware deficiency. It's not clear when it was fixed, but upgrading to latest available revision is the only way around this.

Recording speed chosen by Plextor PX-708A, possibly other units...

growisofs expects recorder unit to readjust the list of supported velocities and pick optimal one upon every media re-load. Plextor unit (and possibly some other units) reportedly tends to retain once chosen velocity value. E.g. if you set 2.4x for 4xDVD+RW media and then load 4xDVD-RW media, even then it will pick 2x. Unless you explicitly tell otherwise that is. Therefore you have keep track of current velocity and explicitly pick one for every recording. If you wish to unconditionally default to highest speed, possible workaround is to "alias growisofs 'growisofs -speed=256'." Yes, this means that whenever you specify -speed option, there will be two -speed options passed down to growisofs. But that does the trick as it's the last one in command line which applies. -speed=256 alone effectively means "pick highest possible." Well, any insainly high value would do...

growisofs fails to auto-format DVD+RW blank in LG GSA-4040B...
The issue was addressed in dvd+rw-tools 5.14.x update. Either upgrade the tool chain or explicitly format DVD+RW blanks with dvd+rw-format prior actual recording.

DVD+RW recordings with SANYO derivatives, such as OptoRite DD020x...

dvd+rw-format -force followed by DVD+RW recording attempt reportedly produces unpredictable result. Unit seems to fail to resume DVD+RW background formatting transparently. Recommendations are: install dvd+rw-tools 5.15.x or later; forget all about dvd+rw-format, growisofs will apply initial formatting procedure whenever appropriate; stick to growisofs -dvd-compat ...; Once again! This applies to DVD+RW recordings and DVD+RW recordings only. Don't fall into belief that -dvd-compat option is required for all recordings with this unit. Keep in mind that in write-once DVD±R context -dvd-compat results in unappendable recording, which is not necessarily what you had in mind...

Crash of Philips/Benq 8x derivatives, such as HP dvd400c...

Unit apparently crashes if media is reloaded immediately after dvd+rw-format procedure. Attempt to record [after re-load] may result in system lock-up. Unit can be "brought back to life" by running dvd+rw-mediainfo, which reportedly results in bus reset... "Natural" workaround is to abstain from applying DVD+RW formatting procedure with dvd+rw-format, but rely on growisofs to do it for you automatically, which is proven to work.

Short DAO recordings with Pioneer units...

If you attempt to perform DAO recording smaller than ~750MB in Pioneer unit, IDE bus gets monopolized for significant amount of time at the end of recording, despite growisofs' attempt to deploy "immediate" MMC commands form. Depending on hardware configuration this may lead to a dead-lock condition. Well, such small recording was most likely mistake in first place - indeed, you could as well have used a CD-R for that little data...

Philips DVDR824P doesn't obey -speed argument...
The problem was observed with firmware revision P1.2 and is caused by a firmware bug. Unit in question fails to return the number of avaliable performance descriptors as MMC specification requires. In wait for firmware update you have the option to download and use this snippet.

-dvd-compat/-video DVD-R recordings performed in BTC burner are hardly playable in legacy units...

The problem was observed with DRW1008 unit and firmware 0054. The unit apparently records bogus [zero to be specific] "Last border-out" value [which in -dvd-compat context is also first border-out] into lead-in, which is believed to be a firmware bug. If [and only if] you're to perform -dvd-compat/-video DVD-R[W] recording in BTC unit, complement growisofs command line with -use-the-force-luke=dao option.

Plextor PX-708 and NEC ND-2500 "Failed to change write speed" for >4x media...

It's possible to effectively work around the problem by letting growisofs fail first time and then [without re-loading media!] rerunning it without -speed argument. The unit should perform as specified in failed command. The issue was addressed in 5.19.x update. You'll also notice that recording doesn't necessarily starts at specified speed, instead it [abruptly] increases as recording progresses. The units in question implement ZCLV, Zoned Constant Linear Velocity strategy, when media is divided into several, 2-3 zones with increasing speed toward outer edge.

growisofs fails with "Not an MMC unit" on original Pioneer DVR-A04 firmware...
I personally didn't even believe there ever were non-MMC DVD units out there. On the other hand there were claims that it might be some subtle Linux kernel problem. In either case, firmware upgrade reportedly helps.

Short DVD+RW recordings come out "blank" from Lite-On LDW-451S...

After recording less than ~1GB on a virgin DVD+RW disc, media is still recognized as blank by the recorder unit in question, but not necessarily by DVD-ROM player! The problem was observed at least with firmware revision GSB7. Make sure the first recording is larger than 1GB. If you don't have that much data instantly, nullify first 1GB with e.g. 'dd if=/dev/zero bs=1024k count=1024 | growisofs -Z /dev/dvd=/dev/fd/0' prior recording.

Toshiba and NEC derivatives units fail to start DVD-RW recording with "COMMAND SEQUENCE ERROR"...

As you might know Disc-At-Once is the only recording strategy applicable to minimally blanked DVD-RW media. Even though growisofs is explicitly programmed to detect minimally blanked media and to engage DAO automatically, several units were reported to lead it to wrong conclusions, which in turn results in the above failure. If it has to be Sequential recording, complement growisofs command line with -use-the-force-luke=dao option or apply full blanking procedure. Overwise you have the option to format media for Restricted Overwrite and forget all about blanking and DAO.

Newer Pioneer units fail to complete recording with "Device or resource busy"...

The issue was addressed in 6.0 release. If you wish to know gory technical details, the reason for growisofs prior version 6.0 failure is divergence between MMC and Mt.Fuji specifications. The MMC specification requires LUN to reply to TEST UNIT READY command with "OPERATION IN PROGRESS" status, while background close operation is in progress. Mt.Fuji maintained by Pioneer on the other hand requires LUN to reply with "GOOD" status in same situation. Upon close operation growisofs polls unit with TEST UNIT READY and versions prior 6.0 didn't tolerate non-MMC behaviour...

LG GH20NS10 might hang at the end of DVD-R[W] DAO recording...

The problem was observed with image sizes not divisible by 32KB and firmware version EL01. It manifests itself as I/O error in the last WRITE command, which is caused by latter's timeout. The recording per se is properly completed by unit and no data loss occurs. To work around the timeout condition pad input image file up to the nearest 32KB boundary or avoid DAO recordings. One way to pad is to perl -e '$blk=32*1024; $nm=@ARGV[0]; $sz=(stat($nm))[7]; \ truncate($nm,int(($sz+$blk-1)/$blk)*$blk);' image.iso