#1 Burning Software

While gus would be preparing the DLL can you send me again:

1) GrabTrack log (successful I guess)
2) You app log (unsuccessful)

or just 1) if you did not apply any changes since last log you've sent me.

Thanks!

I'll send you both logs. I've been trying different things(added StarBurn_CdvdBurnerGrabber_GetInsertedDiscType to see if that was it). It wasn't. Check your email in a bit.

Nathan

OK! Thanks!

For anyone else who may run into this problem, the staff at RocketDivision was able to figure out the fix. I had to add:

StarBurn_SetIsSafeGrabbingEnabled(TRUE)

before my calls to GrabTrack. The cause was my USB to ATAPI adapter.

Nathan

"Secret" API call. Anyone who's having issues with frozen grabbing on USB mounted ATAPI devices - please contact support via e-mail. Thanks!

Does this also apply to Verify functions? I've got a customer that has had a freezing problem with verify. I've added the Safegrab command but want to confirm it also applies to verify or is this something else?

Yes!

Here is some more info on the best way to use SetIsSafegrabbing. If you just turn it on while grabbing/verifying it will greatly slow down your grab/verify. For example I normally get max 15000KB/s when grabbing but when safe grabbing is enabled I get max 13000KB/s. When verifying I normally get a max of 15000KB/s also but when safe grabbing is enabled I get max 7500KB/s.

The following practically removes the slow down but still keeps the advantages of safe grabbing(eg doesn't freeze up on my USB to ATAPI). Note my USB to ATAPI only freezes up when multiple single LBs are read in sequence. When 10 or 30 LBs are read at one time this never happens. So at the end of a grab it always freezes unless the track LB count is an exact multiple of 10 or 30 LBs. Obviously this may not apply to all USB to ATAPI bridges that are broken.

1. Don't enable safe grabbing unless your read/verify speed is under 6000KB/s(or one of the next rules applies). Since my max speed is 7500KB/s when reading with safegrabbing enabled I can safely leave it on for anything under 6000KB/s.

2. Enable safe grabbing before the last 10 LBs are read. To do this I check if I have less than 1.5seconds worth of LBs left when my callback gets called. If so I'll enable safe grabbing. My callback gets called every second when grabbing so I always enable safe grabbing well before the last 10 LBs are read. When verifying make sure your callback is called every LB. When verifying I just enable safe grabbing 1000LBs before the end of the track.

3. Enable safe grabbing if a BadBlack, ECCBadBlock or Read Retry happens. I don't know if this is absolutely necessary but it works so I'm not going to change it. SafeGrabbing gets disabled if read/verify speed gets back above 6000KB/s.

Obviously the better solution would be able to make sure safe grabbing is enable when reading single LBs but not when reading multiple LBs(hint hint RocketDivision ).

Thank you very much for info!

However listed scenario is for your case only. Our solution was results of quite a lot of complains (well, few of them, but around say 5 or so). Other guys got random freezes...

Safe grabbing switch should be applied ON only if user has broken ATAPI-USB bridge and not always.

Agreed. Thats why qualified my statement that this was the case for my broken atapi bridge. But my atapi bridge is based on the Cypress CY7C68300A(or B, both show the same problem). This bridge chip is probably in over half of all ATAPI bridge adapters so I suspect my hack above will fix many peoples problems without reducing the grab and verify speeds.

Nope. Quite a few of them really have problems.