#1 Burning Software

It is currently Thu Dec 19, 2024 7:48 am

All times are UTC




Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: Canceling frozen verify
PostPosted: Wed Nov 08, 2006 9:01 pm 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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?


Top
 Profile  
 
 Post subject: Re: Canceling frozen verify
PostPosted: Thu Nov 09, 2006 12:26 am 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
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...

Acidtech wrote:
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 2:04 am 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 3:05 am 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
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.

Acidtech wrote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 5:40 pm 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 6:57 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
Ah, that's broken USB-ATAPI bridge. Unfixable...

Acidtech wrote:
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 10:08 pm 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 10:24 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
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.

Acidtech wrote:
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 09, 2006 11:19 pm 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 10, 2006 12:58 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
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 :)

Acidtech wrote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 10, 2006 5:26 pm 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 10, 2006 9:16 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
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 :)

Acidtech wrote:
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 11, 2006 10:30 pm 
Offline

Joined: Thu Jun 02, 2005 8:50 pm
Posts: 115
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 11, 2006 10:51 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
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$ :)

Acidtech wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 33 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group