Hello all,

Now that i seem to be getting the drive to accept the cue sheet for DAO, i'm very stuck on a problem that seems to be resetting the SCSI bus - or at least thats the error codes i'm getting. I believe the reset to be caused by a command timeout - at first very little of the track would record before the error - so i increased the timeout field in the sg_io_hdr to 40000 (40 seconds) and now the pre-track gap zeros seem to be sent fine and then the track starts and gets stuck at the same place; lba 10fd. At this point the same write command i've been using, times out for no reason i can spot.
Another thing i find quite strange is this happens at this spot if i send the write data in blocks of 2353 bytes, but if i go for 63504 it times out inside 3 writes. At first i thought it might be a buffer problem, but reading back the capacity it looks fine, and anyway i was under the impression the command would return with a busy error code instead of timing out - in which case the command is retried moments later.

Has anyone come up against this before and does anyone know a way around it?

Thanks
Andrew

Well i'm not sure this actually helps me work out whats going wrong, but i extended the timeout to 200 seconds. Now the scsi bus does not reset due to timeout, i get an error code at 10fd 5/21/2. Now according to the specs this is an invalid write address, which certainly makes sense in the context, but i output all the parameters i pass to cdb and the addressing looks fine. I'm sending the blocks one at a time and incrementing the LBA by 1 - have i missed something?
Looking at the output of my read_buffer function, i'm not underrunning, if anything i'm sending it too fast, but i was under the impression the unit would slow down the reply or return a busy error code if it got too much?

Anyone think of anything - its very frustrating to get so close, but still not have a single written disc!

Thanks
Andrew

Ah ha! OK so clearly my own fault, i was counting up in msf and converting to lba and i guess something went wrong in the process. I'm now counting up in lba and it seems fine, right up until the end - where the last packet writes, there are no errors given when i send the synchronise cache command, but the disc wont play (its an audio CD). Is there any tools that will give an idea of what went wrong? My suspiciouns lie in an incorrect lead-out, but my impression was the unit would write this to the disc once i had finished writing the data and sent the sync command?? If i can track down whats wrong with the disc it should give me an indication of what went wrong with the write...

Thanks

Andrew

Since you are already writing code, it may be quick and easy to write a little CD reading program. Don't forget to add various read options (unless you are only doing audio). You could read audio with Q subcode near the start of leadout and then increment a sector at a time to see if there is actually leadout or not (watching for track AA). Some drives will not play CDs that do not have leadout while others will.

I think Truman or someone here has already provided a program like this.

Sounds like you're going through a lot of the same issues I've been facing.
I think what's probably missing is a close session/track command.

Something along the lines of

5b 00 02 00 00 00 00 00 00 00

Although I've been having problems with this.
I'm getting back 05/64/00 Invalid mode for this track.
Which according to the info in INF-8090 should only
be returned when issuing a command starting with
'5b 00 01'

follow-up to my previous post. that CDB I listed did the trick, however...

on my old yamaha scsi burner at work a read disc information is required
before the close session will work properly while the opposite is true
for my benq dw1640. (That is, it *only* works if you don't issue the read
disc information before closing the session)