VSHost.exe error on multiple burn drive usage

vbimport

#1

Hi

I’m trying to burn several disc’s at once and i’m having some trouble…

I have read the other threads on the subject, but i don’t understand what to do…

I have a situation, where i successfully can start a burn session, burning on 2 drives simultaniously. This works wiothout any problems.

The first og the drives to finish the burning also works fine, but as soon as the second drive has ejected the finished disc, my c# app crashes with an error in the vshost.exe…

I initialize the NeroClass sperately for each drive, selecting diferent drives after getting the drive collection, so in my mind i’m working with to absolute different instances of the NeroAPI in memory.

I have tried multithreading the setup with the same result…

Both discs have been successfully writen and are fully functional, so does anyone have any idea what goes wrong??

/FStampe


#2

Hi

Problem solved using MemorySharing, Multi-Processing and IPC

/FStampe


#3

[quote=FStampe;2033492]Hi

Problem solved using MemorySharing, Multi-Processing and IPC

/FStampe[/quote]

Can you tell us more specifically how you got it to work? What memory did you share? Did you make the instance of nero static? I tried many different things like that, but always got the same result you had. I want to give it another try.
Thanks


#4

Hi bob1at7shore

[quote=bob1at7shore;2033693]Can you tell us more specifically how you got it to work? What memory did you share? Did you make the instance of nero static? I tried many different things like that, but always got the same result you had. I want to give it another try.
Thanks[/quote]

Very cruedly explained i did this…

I have made a solution i studio 2008 doing the following…

  1. I have a shared memory warpper, enabling me to reserve a named part of memory and then streaming any object into it.

  2. Both the managing code and the actual burning code and access this memory block by name. The name of the block is passed to the process at startup…

  3. The managing code creates a nero object, examining number of burner present and then creates the corresponding memoryblocks and Burninfo objects containing the data to be exchanged between burning process and manager (i.e. progress - phase info and so on).

  4. It then startes up the appropriate number of burning processes corrospondig to the number of present burndrives and passes on the name of the memoryblock, so that this process can share the Burninfo object with the managing code…

  5. Now i have a burning process for each burndrive on the computer.

  6. I communicate between the processes using IPC with SendMessage and wndproc override to send triggers telling the process or the manager, that the BurnInfo object has been updated in the shared memoryblock and that it should be examined… This is also used to command the burnprocess to start burning…

  7. Every time a nero event updates the BurnInfo object, it is pushed into the shared memoryblock, the managing code is IPC’ed and then reads the object from the shared memory and updates the appropriate controls (progressbar and so on)…

All of the above i, for now, done very cruedly and needs a lot of cleaning up and retouching to be made failsafe. But the actual burning process works without any problems, so the actual multiple drive burning problem has been solved…:slight_smile:

/FStampe


#5

I tested by create 2 different exe for burning. It is working fine. Is there any solution to make it success with the single exe.

ThiruKumaran


#6

Fstampe:
Thanks for explaining. I have not had time to work on it lately. Maybe in a few weeks. I just want to say thanks and I will monitor this forum for more info on this topic.


#7

[quote=thirukumaran;2053285]I tested by create 2 different exe for burning. It is working fine. Is there any solution to make it success with the single exe.

ThiruKumaran[/quote]

Hi ThiruKumaran

I my solution the actual burn processes are done by a single exe file, that is executed seperately in different processes…

I think i could incorporate this into 1 exe, that is started with appropriate parameters and that then internally interpretes these. Actually the burn processes are for now started up doing this and in that respect there is no problem joining these into one exe…

But to start up several burn processes using multithreading is not doable with the current dll file. They start up fine and also burn okay, but it seems that there is a global stack/variabel area, that cannot handle this and it shows itself as follows… All burns work fine, but only the first first burn terminate okay… All the following burns terminate in error and it cannot be resolved by an try/catch statement… Doing it i seperate processes will initialize seperate dll’s and that seems to clear that problem…

/FStampe


#8

Hi stampe,

I have gone through your article but still i am having some doubts in that. If its possible can you provide an explaination on shared memory wrappered class with examples to understand.


#9

From what I’ve read on this forum, it is not possible to run parallel burns in a single process.


#10

Could’nt have said it more precise myself…

You need, as detailed above, to create seperate processes for each simultanious burn… The DLL does not, as of the version i had, support multiple burns in one process…

Seems to be some overall status registers that can’t handle it, since multiple simultanous burns can start and will finish okay, but the DLL will throw an exception and your software will crash…

Try / Catch from C# won’t work, since it is not the application that crashes, but the DLL thread…

I have written, how ever crude, an app. that does it as described above…

/FStampe


#11

Does anyone know if a future version of nerocom will support this? Is there a timeline?


#12

Hi. I have no knowledge of that, but aside from a little extra programming, there really is no need for it. It is actually quite simple and wether you want an visible interface or nor is up to you…

/FStampe


#13

Not taking anything away from your work:clap:, but your solution is definitely not optimal. The amount of complexity that is introduced to your app has increased, and its maintainability has decreased.

So is there a Nero Engineer/Product Manager out there who can give us some insight into future releases of the NeroSDK?


#14

You are absulutely correct, that it is not the optimum solution. My thoughts are, that it probably not is something high on their TODO list, since it would take some of the edge off their application…

But true, it is more complex. But with good programming and a lot more thoughts put into it, i think it is doable…

Would greatly appreciate the upgrade to the nerocom though…:iagree:

/FStampe…:slight_smile: