#1 Burning Software

Hi,

when installing VirtualDrive Pro http://www.farstone.com/software/virtualdrive-pro.php (tested on a WinXP machine), initialisation of StarBurnX works fine, but it hangs at the following piece of code:



The highlighted line never (waited for a few minutes) finishes.

Use SPTD to bypass broken filters they install. That's what SPTD was designed for.

Well...I am not going to use SPTD by default, since I don't want to add further dependencies unless necessary. I still don't trust SPTD, it can (and did in the past) also add issues instead of solving them.

So: If you say that with VirtualDrive Pro installed, StarBurn simply cannot be used in SPTI mode, that is fine with me and I can always tell the user to use SPTD instead, *but* my application needs a way to figure out that something is wrong. Hanging is not good. So is it possible that StarBurn, instead of not responding, can emit an exception? Or is it reasonable for my app to have a timeout for this property access?

No it's not what I say. It could be something inside StarBurn so it's a good idea to try STPD and if your user would continue having the same issue we'll be happy to take a look. Ether locally or with remote session.

Nah, that's not my point

Even assuming that it works fine for my user with SPTD (which is not necessary to check, because he already uninstalled VirtualDrive Pro), every other user with this software installed will also suffer from the issue. So in my app I need a reliable way to determine whether or not a conflicting app is installed and then advise to either use SPTD or uninstall other applications. So whether or not SPTD works fine with StarBurn, the SPTI access needs to be fixed in a way so that I either get an exception or a more or less valid response.

If I'd write a filter driver just spinning some command forever would you suggest another app developer whose command we're spinning "fix" their application? How? And that's basically what you're suggesting us to do... SPTI is unreliable way to access hardware and that's why no serious commercial app uses it entirely. You may use it or not but telling us we need to "fix SPTI either way" is a little bit confusing.

Now you are confusing me:

I said:


Then you said:


Now you say


Sooo...is there a way to make StarBurn work properly with SPTI under the given conditions or is there not? As I said, if it cannot be fixed because VirtualDrive Pro messes up the system, I can live with it, but if it's possible to add a workaround for such cases, I'd like to have it.

1) I cannot guarantee it's StarBurn or VDP issue. If it's StarBurn issue (the same things happen with "safe" SPTD layer) we'll fix it. It's not StarBurn issue - we cannot fix it. Right now SPTD is only the way to check.

2) We cannot workaround every broken software. We'll have a MESS inside our code. That's what SPTD is going to help with. Bypassing broken filters.

OK, got it. Result: SPTD *does* work.



Hm, I noticed that the older NMS SDK does not hang up though. Only StarBurn does. Don't get me wrong, I don't want you to write messy code, but if there is a non-messy fix, please consider it.

Excellent! Could you please ship both versions (STPI Vs. SPTD) logs initially and we'll try to find out what we could do here.

There you are.

According to the log StarBurn does not hang. It's just trying to get virtual device properties and emulator completes command with I/O device error (Windows code 1117). So we're trying again and again as this command is not supposed to fail until it does not reach maximum limit (5000 iterations). Unfortunately there's no way to turn off this is control number of retries (we don't have such an API as these values are hardcoded) so we'll take a closer look later - I think we can fix this some way.

Great, thanks. 5000 tries might indeed not "hang forever", but long enough to assume the application needs to be closed using the task manager.

Nope... It's VERY fast in normal conditions (less then 1 second) it's just VDP who also delayes every command for quite a time.