#1 Burning Software

I've got a problem with the verify functions freezing intermitently(I assume from bad media) but when it freezes(I'm guessing its trying to verify a particular LB but can't so it retries) the callback is never called again(because it's only called every x LBs). Is my only option a worker thread that times the delay between callback calls during verify and then having it cancel the verify if it gets stuck?

Verification routine should unblock after problematic region would be over. Or does it get stuck forever? What's written in th log? See, if it's wait for SCSI command's completion there's no way to unblock the thread...

So far the problem has only happened a handful of times and only on systems running release versions so no log. I've tried to reproduce it on my development system but with no luck. I can tell you when the problem happens the callback never gets called again(the callback updates a message window directly when called) and the starburn verify function never returns. The verify is running in a seperate thread from the main program. I am able to do other things in the program even when the verify is frozen so it's not a general program error.

If verify routine does not return this means something really bad happened to drive. And command sent itself is hanging. You can stop the thread and warn the user to reboot the machine.

P.S. Doing eject / drive reset may help BTW.

Some more info. I'm using a USB drive and I've had to use Set_IsSafeGrabbingEnabled or the drive hangs when ripping. Could this be the same problem but with verifying? Does Set_IsSafeGrabbingEnabled also apply to the Verify commands?

Ah, that's broken USB-ATAPI bridge. Unfixable...

How so? It happens infrequently. If it was a broken bridge I would expect it to happen a lot or allways as I saw with grabbing. Why wouldn't verify work the same as grabbing(ie use the Grabbing fix)? Also what USB bridges do you know DO work? We are using a Cypress bridge. I've looked at a dozen other bridges and they were almost all cypress. Also Primera uses the same Cypress bridge as we do. They use PrimoDVD. Is PrimoDVD better than Starburn at handling broken bridges?

Slowing down operations helps a bit. But not in 100% of the cases.

USB is not reliable way of attaching storage devices. All customers we have finally ended with FireWire attachments. Problems were also with other burning engines/apps so it's not StarBurn issue. Re-mount unit as ATAPI one and the issue would be gone. Re-mount unit to the newer firmware USB bridge and the problem would be gone.

Do not know. Ask Primera Composer guys - maybe they have statistics. However I don't think they would respond to your request.

I don't see an answer to my SetIsSafeGrabbing question. If grabbing works with IsSafeGrabbing then why can't the same method be used when verifying. Isn't verifying also "grabbing" and comparing to a file/tree?

Also it seems to me that the "call callback every x LBs" is a bad method for calling callbacks. Any chance of getting a verify with a time based callback in the future?

A general "USB sucks" doesn't help me at all. If you don't know the answers to my questions just say so. I know trying to debug something like this is a pain. I do tech support as well.

1) Sequences of actions are different. So I cannot just take working code for grabbing and use the same one for verification assuming there's a possibility it would work. B/c it would not And I don't have here around anything working (or not working better say) with USB enclosures in the same way. If you have at least partial reprodiction ratio - I can modifiy the code and test it on your hardware remotely with your help. If it would work fine - we'll add this code to production branch. Does it sound good to you?

2) Nobody except you ever complained. So we would not change/add new callback to verification unless we'll get multiple requests from different people.

3) "Replace USB with FireWire" is perfect answer. Sorry it did not work for you

1. Yes, I'm more than willing to work with you on this. On average I can get it to reproduce once in 100 discs so it is reproducable, just slowly.

2. Please keep it in mind. If you ever have to go in and do major mods to the verifying functions.

3. Only if you can stand Firewire.

1) OK, I've altered the code so please drop me a message to info@rocketdivision.com so I'll be able to send you test DLL.

2) For now we're a bit busy with UDF and Blu-Ray thing

3) Well... I don't see much of the problems. If you do - I'm sorry

You can email nathan@basicmicro.com


2. Good, I was wondering when BD would be ready.

3. The problem with firewire is it is not a universal connection format. I can't get printers/comport adapters in firewire format, but I can get usb printers and comports. If we had to use firewir we'd have to have a second connection(usb AND firewire) in our units and the enduser would have to support USB adn firewire as well.

Thanks.

1) OK

2) Just a bit more work then we've expected...

3) Most modern M/Bs and notebooks comes with 1394 connector. And you can always add cheap 15$ card to your unit (if you do hardware things). It would save more time and money on support requests in any way. Just my 0.02$