Re: cdrecord problems

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> The failure depends on timing between wodim and hal. IMHO there is 
> a chance that it fails earlier if hal polls the drive in the right moment.

Not impossible, i have to confess.

But reading wodim's source for write-mode detection
i have to conclude that hald would have to _reliably_
sabotage at least half a dozen consequtive attempts
to set the write parameters by mode page 05h.

There are other points against your theory.

- The known hald vulnerability of CD burning is with
  the actual process of writing.
  This is not a sin of LG but complies to MMC-5,
  6.44 "WRITE (10) Command"
  
  "While writing is occurring, the Drive may not be able to
   process all commands. The following is a list of commands
   that shall function during writing without causing a
   SYNCHRONIZE CACHE.
    1. TEST UNIT READY
    ...
    8. GET EVENT STATUS NOTIFICATION
   All other commands shall process normally, but may force
   a SYNCHRONIZE CACHE before executing."

  SYNCHRONIZE CACHE implies the (premature) end of the burn.
  That's what we usually experience when hald spits into
  our soup.
  (If one wants to be picky then above statement belongs to
   6.44.3.3 "SAO Raw on CD-R/-RW, DAO and Incremental on DVD-R/-RW"
   and would not necessarily apply to TAO.)
 
- There is another drive on pengsens' system which
  works without problems. Both occurences of zero
  supported write modes are with a LG GSA-H30N drive.

I concede that this still does not outrule hald problems.


> I think that updating wodim is a good idea anyway,

Agreed.


To pengsens (if you are still reading):

Please make the following experiments
- Try  dev=/dev/sr0  rather than dev=1,0,0.
- Kill your hald process and try wether your burner works
  better afterwards.
- Try wodim-1.1.6.


Have a nice day :)

Thomas