Re: cdrecord problems
> 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
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
(If one wants to be picky then above statement belongs to
18.104.22.168 "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,
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
- Try wodim-1.1.6.
Have a nice day :)