#1 Burning Software

1) Wrote a reply. Please check your inbox.

2) Sure. www.daemon-tools.cc product is our "friendly" one. Just like Alcohol software stuff and CloneCD it has special driver built-in layered at the top of the CD/DVD hardware. Just above it, lower then broken SCSI filters from Roxio/Sonic/etc. So it's able to redirect SCSI traffic from burning application (RDS library and your app using StarBurn) to this hooking SCSI filter bypassing Roxio/others. That's the idea in a nutshell.

3) We'll do what we can do here to find out the solution/workaround.

1) Haven't received it yet, can you resend it ?

2) Does it mean if the users installed this "Daemon Tools", the problem can be fixed ? Do I need to change the code ?

Thanks.

1) Done!

2) Could be... Yes, just a bit (replace one call with another).

1) Maybe it is too late, the customer just replied me that he tried to remove Sonic finally, but the problem is still the same, so he reuqested for refund and refuse to try any more... so as you said, the problem may not be caused by Sonic this time...
The "Exclusive Access" approach will only help if the problem is caused by Sonic/Roxio, right ?

2) So this approach seems easier... I have saw the "FindDeviceEx.c" example, and I still can't figure out the exact code I need to change...
If just install "Daemon Tools" and change one call may help, we may try this first...

1) It's a pity

2) Replace Create(...) with CreateEx(...) and change a bit device enumeration code.

1) The "Exclusive Access" approach will only help if the problem is caused by Sonic/Roxio, right ?

2) Could you tell me the details? or send me an email? This approach is easier, next time if my user got the same error message and again installed Sonic, I may ask them to try this approach.

Thanks.
raymng

1) No. Against others (for example Packet CD/DVD writing software) too.

2) Already did a lot of times. Did you get the one with attachment of the driver and sample?

I recevied an email with the details of the "Exclusive Access" approach, but I want to know the details for the "Daemon Tools" approach as well.

"Exclusive Access" and "Daemon Tools" should be two different methods, right ?

Thanks.

Just replace CreateEx for SPTI with CreateExEx for SPTD. Rest of the code would not change. The version of the Daemon Tools we rely on is not released to public yet. Start doing SPTI support as FindDeviceEx sample shows and when DT Pro would be released you'll add support for it's SCSI transport in one minute.

Yes.

> Just replace CreateEx for SPTI with CreateExEx for SPTD. Rest of the code would not change

Do you mean my Original code or the FindDeviceEx sample ??

Thanks.

If you want to make your code use SPTI and SPTD it's obviously you need to chance YOUR code and not somebody else.

No offence. Of course I need to update my code. As you said, just replace CreateEx with CreateExEx and rest of the code would not change, right?

So is that mean I just need to change one call of my original code ??

Thanks.

Again. Slowly

Right now your app uses Create(...) and ASPI to deal with burners. I've implemented special driver which blocks access to devices when we (StarBurn and you) keep handle to it (device) open. So you need to:

1) Change device enumeration method. Instead of calling FindDevice you need just loop all drive letters checking for DRIVE_TYPE_CDROM (see FindDeviceEx sample). You can still use FindDevice call to enumrate burnrs. Just keep track of Symbolic links callback would report to you.

HOWEVER from my point of view mixing SPTI and ASPI is not a good thing so I'd just cut-n-paste FindDeviceEx enumration sample.

2) Change device creation method from Create to CreateEx. It used drive letter (or cdrom%d) name instead of SCSI address. Rest of the parameters are the same.

After you'll do this you'll be able to use ASPI (if you'll still have this code in some sort of "if" switch) and STPI. Turnable. On 2000/XP/2003 you'll be able to use SPTI as "native" method to access burners and also there's a driver (StarOpen) to help with pure exclusive access.

After you'll have this all working and DT Pro would be release you'd have to add CreateEx -> CreateExEx add (I'll declare API call a bit later you don't need it rihgt now) and you'd be able to use alternative path for SCSI traffic so NOBADY would be not only access the drive but also intercept your traffic to it (right now SCSI fitlers can...).

Is it clear now?

Hi Anton,

1. Recently one of my user reported this problem (Writing failed, exception 8, status 31, text icStarBurn, Scsitransport ASPI, etc) again, he reported that when he use 8x DVD+R, it works fine. But when he use 16x DVD+R, he got the error message.

2. Do you think it is a good idea to enable starburn LOG for all users ? Currently I will only ask the users to enable it when they got problem. I afraid it will affect the efficiency or something.

3. I got your email regarding the new IFO patching, but I was busy to work on the new version. I should have time to try it out tomorrow and I will let you know.

> we've added new code to StarBurn. Now all IFO/BUP patching is fully automatic and completely rewritten. Plus we build the files ourself, no need for you to do anything except pass VIDEO_TS folder name to us.

Do I still need to call "StarBurn_UDF_FormatTreeItemAsDirectory()" and "StarBurn_UDF_FormatTreeItemAsFile()" ??

So I just call like this: StarBurn_UDF_PatchIfoTable("C:\DVDTitle\VIDEO_TS\") ??


Thanks.

I've checked your logs and if my memory does work for me you do allocate only 64MB (could be as small as 32MB) of RAM for device caching. It could be OK for 8x burning but for 16x you need to grab as many memory as you can (128 and up). Could you please do it?

No, it's a bad idea to enable logs just for everyone. I think what you do now is correct thing (enable them only for problematic cases).

No, you need to call DVDVideo_Create *ONLY*. Just like "C:\\Stuff\\VIDEO_TS" and that's all.

Manual patching code is completely removed from SDK.