#1 Burning Software

Hello,

I'm currently facing an issue in my application written in Delphi 7. In fact the application can run on notebook and desktop plateforms.

At the end of the creation of the media, I have a testing function that checks the media for a successfull burnin. On desktop I eject the tray and reload it, but on notebook plateform I can eject the drive but not reload it.

Unfortunately Eject/Load functions return En_SUCCESS even if the load section failed on Notebook. I have seen that the load function returns a CDB_Failure "CStarBurn_ScsiTransportSPT::ExecuteDB(): Command failed". Usually you said that this information is more for debug usage, but in my particular case can I use this information to know if the Load command has failed.

I've seen that you have a GetMechanicalOptions that should really help me, but it doesn't seem to work as expected. First, it's not available in V7.1.10, but when I try to use it from V20.2.7 it doesn't work. If it works, is it linked to the device firmware, is all the devices will have this information ?

I could use the MediaTrayStatus and check if IsMediaPresent is set but I'm afraid about the time it needs to really return result (and so it could have impact on Desktop process).

Thanks & Regards,
F!o

1) It's WRONG forum. So I'm moving the thread to the "StarBurn SDK" place.

2) Notebook drives cannot do automatic loads as they require human assistance (you need to push the drive tray or the disc to slot). You can use StarBurn_CdvdBurnerGrabber_GetMechanicalOptions(...) API call to determine do you have "tray" or "pop up" loading mechanism.

3) We don't support anything earlier then 7.2.20 (latest published version).

4) If something does not work as expected we expect you to issue us with the debug log. "Does not work" is not enough of the information to proceed. Please issue us with the log and we'll try to find out what's wrong.

Thanks!

[url][/url]

Anton,

Thanks for your answer and sorry for posting previous post in the wrong forum.

So I have finally corrected my prb with the GetMechanicalOptions, but unfortunately this function will not help me analysing wich kind of optical drive disk is available on the system. I have tested it on some plateforms (desktop and notebook) and each time the MechanismType returns 1 (Tray). Could you let me know what are the differences between each values, Caddy, Tray, Pop-up, Changer, Cartridge is it normal that Notebook and Desktop ODD return Tray, there is no link with the fact notebook drives cannot be loaded programmaticaly. As I can't use the LoadEjectSupported variable because it returns True if at least the Eject is available (even if the load is not available), I'm not able to detect if the drive supports the Load programmatically.

Do you know if there is a way to detect this information ?

Thanks and regards,
F!o

1) It's ABSOLUTELY no problem! You've just received my reply a bit later then you could

2) It should not happen this way! For notebooks it should return "Caddy" (0x00). Could you please send me the logs from the notebook drives returning bogus values? Thank you!

Got the logs from you. Indeed, your hardware perfectly reports wrong values. I'll double-check the SDK (however it's nearly 100% clear it's not it) and will try to find a workaround. If possible of course (hope so).

No good news. I still cannot find out how to differ manual loading tray (notebooks) from motorized tray (desktop units). I'll continue the investigation in the background if you don't mind and I'd like to offer a workaround for you. We'll do "load", check for it's status (it's not always bad if the loading process did not complete) and ping device with "test unit ready" for some time. If it will not complete with success for say 10-15 seconds you can pop up a message "Drive failed to close automatically, if you have a notebook device please load the disc yourself and push OK button to continue". I'll wrap everything into the new LoadEx(...) call if you want. And if I'll come around how to differ devices I'll update you.

Is this OK for you?

Sorry for the late reply.

On my side (waiting for a better solution) I will ask user each time (notebook and desktop) to close the tray.

Thanks & Regards,
F!o

No problem absolutely! OK, so you'll use a workaround ATM and wait for me to find a solution (no guarantee however unfortunately...). Right?

Yes you're right.
Thanks for your support.

Regards,
F!o

Thank you very much for understanding! Hope I'd finally manage to find a solution for you.

If all you're doing is verifying that the disk burned correctly then why not use the built in verify routine? It does not require the disk to be ejected and reloaded to function.

In our burner I do it like this...

1) Call StarBurn_CdvdBurnerGrabber_TrackAtOnceFromTree
2) If succeeded call StarBurn_CdvdBurnerGrabber_CloseSession
3) If succeeded call StarBurn_CdvdBurnerGrabber_VerifyTree
4) If the verification routine was successful it will return EN_SUCCESS

Dan

Works fine for TAO but not for SAO or DAO... They need the disc to be ejected (buggy devices cannot handle software reset in "calm" way).

Ahhh... I've seen other programs, such as ImgBurn and Nero, do the ejct/reload trick. How do they handle notebook drives? Seems like they could just check if the load fails then popup a message asking the user to close the drive.

Dan

This is what I've proposed Florian to do. What he really wanted - to differ motorized tray and manual tray devices. I don't know how to do this so far

I have tested it on some plateforms (desktop and notebook) and each time the MechanismType returns 1 (Tray).