Concurrent use of several IDE drives

vbimport

#1

Hello,

I need to concurrently burn different data on two IDE drives

I’m able to start burning on each drive, but when a burning ends on a drive, the burning on the other drive simutaneously fails.

I tried this both in the same process, or in two separate process but :

  • In the same process (in two different threads) the Nero API returns some sort of internal error when the first burning ends, and then, the second burning fails
  • In two separate process, the Nero API return an SCSI error for a drive and the burning on this drive fails.

Does anybody know if the API is designed to simultaneouly use the handles of several drives to concurrently call the NeroBurn function ?

Am I missing something ?

At first I thought that I had problem coz my two drives were on the same IDE controller. But, I saw that a was able to concurrently burn two CD with the Nero GUI (starting two GUI process). Both burning were OK. So the Nero GUI can do that in two separate process !

Is there some way to initialize the API to avoid these errors in one process. Or at least in two different process ?

Thank a lot.

StephG


#2

Hi,

I reply to myself because I have found the same probleme I
described in my first post, in the ‘NeroFiddles’ exemple provided
with the SDK

If you have two drives try this :

  • Launch two ‘NeroFiddles’ programs
  • Simultaneouly burn two large files on each drive (with each
    ‘NeroFiddle’).
    the end of a burning kill the other one (SCSI error…)

Actually, I used ‘NeroFiddle’ as an exemple
for my own program, so it is not suprising
that the same problem can be reproduced.

As the problem does not appear with ‘NeroCmd’, I suspect
a probleme with the ‘NERO_ISO_ITEM’ ISO track creation
(both my program and ‘NeroFiddles’ use ‘NERO_ISO_ITEM’,
but ‘NeroCmd’ does not use it (it uses one of the C++ ISO track
creation))

Can anybody reproduce this problem with ‘NeroFiddles’ ?

Thanks


#3

Actually, ‘NeroCmd’ does use ‘NERO_ISO_ITEM’ (that’s NeroAPITest that uses the C++ ISO track creation, sorry)

Given that the SCSI error doesn’t appear with ‘NeroCmd’, and appears with "NeroFiddle’, and given that both programs seems to use the API the same way…well…The more I test, the less I understand…


#4

Hi, once again I reply to myself : I’ve just found that my problem has nothing to do with the API itself.

I was able to reproduce the probleme with the nero GUI, or NeroCmd

It happens for a TAO burning.

It explains why the problem appears with the exemple ‘NeroFiddle’ and my program, given that the DAO flag is not activated in ‘NeroFiddle’ The default mode for the Nero GUI and for NeroCmd is DAO

So, my probleme can be reproduced with the nero GUI this way :

I open two Nero GUI, I set the TAO mode, and I burn data with each GUI on each drive (I have two drives on the same IDE controller)

When one burning ends, the LED of the the second drive flashes, showing that something is happening on the bus. Both burned CD are OK though.

However, if I set the burnproof mode off on each GUI, and I retry the same thing, one burning fails, and the Nero GUI for this burning says ‘Invalid Bloc Address’. The log file repports an SCSI error.

So does it mean that I may have a probleme with my configuration, or my drives, or, is two drives on the same IDE controller a bad idea ?


#5

The IDE bus itself is the problem as it can completely block the pci-subsystem and therefore one burn-process can block another e.g while creating lead-in and out.

I suggest that you try to enable buffer underrun protection with NBF_BUF_UNDERRUN_PROT when burning with NeroAPI.


#6

Hi, thanks matze.

Actually, NBF_BUF_UNDERRUN_PROT improved the concurrent
burnings.

However, when I burn using two NeroBurn commands in the
same process (with two threads), the result is always an
API error for one of the burning, even with one IDE controller
per burner.

Is the API thread safe and reentrant ?

Thanks


#7

No, NeroAPI is not threadsafe and reentrant. It is not allowed to call two NeroAPI methods simultaniously in different threads.


#8

OK, matze, thanks.

I think this information is important and should be added in the API documentation, or, better, in the headers.

All the more so as the API design looks reentrant and threadsafe (uses of handles for drives, and so on…It could be a bit misleading).

StephG


#9

At least in the NeroSDK 6 documentation they mention, that neroSDK supports only 1 Drive in the “Knowen Problems” section!


#10

Has anyone tried to do the same thing on SCSI driver ? any issue on that ?