> Unreadable means, parts (something between only the (probably) rear part up > to the biggest part) of the DVD cannot be read in my DVD ROM drive > (Toshiba). It can read the directory, but when it comes to reading certain > data the drive gets stuck.
Sounds like hardware problem with your unit. As if laser power was not enough at the end... Though it still might be bad media, e.g. if ADIP is corrupted, unit might have burned larger pits which is confusing for legacy DVD-ROM unit or something... > when it comes to plus (does it use different write-heads?). Not that I know of. > After all, I > believe the drive is doing the writing as such, not the program sending > the data, right? Right. > > Does it mean that that application programs succeeded and did not report > > any errors, yet one of disc was unreadable? > > I do not think there is a problem with the recording software > here. No, but depending on how application fails [or does not], you can draw different conclusions about the nature of the problem. > > What's dvd+rw-mediainfo output for affected media? > > ** [EMAIL PROTECTED]:~> dvd+rw-mediainfo /dev/scd0 > Disc status: blank I didn't mean mediainfo for a blank media of some particular brand, but that that particular *recorded* disk which you could access under Linux, but not under Windows. > The growisofs-error > is something like "cannot close session". > Now, such media I can read(mount) under Linux. > But guess: I cannot read them with Windows. BTW, what does "with Windows" mean? Does it mean that you rebooted Windows on same computer or did you test it on *another* DVD unit attached to another computer which happens to run Windows? > ** the log messages after growisofs with dash-medium > (after this the result can be mounted under Linux, but is > not recognized by Windows) As I mentioned yesterday in another thread, there is kernel bug which causes you trouble, if your unit executes some command for longer than 30 seconds. *But* all commands issued by growisofs at the end of recording return instantly [they use so called "immediate" form, which "kicks off" procedure in background and then you simply poll the unit till it's ready] and it shouldn't suffer from it. > ** the log messages after dvdrecord timeout while fixating > (after that the result cannot be mounted under Linux, but > reading with Windows is no problem dvdrecord uses another programming interface which is not affected by that kernel bug. The final conclusion is therefore that it's the unit which effectively crashes at the end of recording and it's hardly kernel or application software problem. > now compare with > the situation above :) growisofs records in Incremental mode, others - in DAO. I mean your interoperability problem might have more to do with recording mode, than with the way recording process crashes... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
