'Checking Discs' stops

vbimport

#1

I am having a problem with burning a DVD. My application builds a DVD image correctly and the NeroBurn function is called.

Nero gets as far as the ‘Checking Discs’ part of the burn process but then stops, at 85%, and refuses to go further.

I get no error messages, as far as I can see, to tell me exactly why Nero has stopped.

My customer has successfully burnt several CD’s / DVD’s before this problem arose.

This is an urgent request for help and a quick response would be greatly appreciated.


#2

Does this happen with media from different manufacturers? Does you app run continuously or is the client running/exiting it at will? Are you using NeroAPI or NeroCOM? What programming language do you use? Which OS does your client run?

Does your app stop responding or does the burn process end? Do you have an error log?


#3

Thanks for the reply.

The media my customer is using has been used for successfull burns already. The app runs continuously but the Nero side of things is only initialised, used and closed when neccessary.

I am using NeroAPI under C++ and Windows XP.

The burn process does not end, as I log the return code from NeroBurn into a log file, and there is no entry after the ‘Checking Discs’ log entry.

As I mentioned earlier the app builds a set of files to burn, the size of the set dependant upon the current disk info returned by NeroGetCDInfo. When the compilation is complete the app initilises Nero, (NeroAPIGlueConnect, NeroInit etc…).
The app then fills in an NERO_WRITE_CD structure, creates an ISO tree from the set of files, and then calls NeroBurn.

We tried restarting the app, which would have used the already compiled set of files, but the result was the same.

As a last resort I instructed the customer to clear the compiled set, which would force the app to rebuild it, and the burn was successfull.

I can see no reason why this should have worked as the files are simply copied from one location to another, to form the set, and the file size of the set that was failing was only 4.3Gb.

My question now would be, what exactly is Nero checking during the ‘Checking discs’ phase and, since it is a check, is there a chance that the check can fail and if so should NeroBurn be exited with an appropriate error code.


#4

The burn process does not end, as I log the return code from NeroBurn into a log file, and there is no entry after the ‘Checking Discs’ log entry.
Are you also monitoring major phase callback?

The app then fills in an NERO_WRITE_CD structure, creates an ISO tree from the set of files, and then calls NeroBurn.
How long is NeroBurn stuck before you (presumably) terminate the app?

As a last resort I instructed the customer to clear the compiled set, which would force the app to rebuild it, and the burn was successfull.
I assume the two resulting ISO trees (old and new) are not identical then? Could it be that there is a problem with the original ISO tree? Perhaps it is not terminated with NULLs?

I can see no reason why this should have worked as the files are simply copied from one location to another, to form the set, and the file size of the set that was failing was only 4.3Gb.
Did you try to burn to an image file with an “Image Recorder” and then simply burn the image? If the problem is on the NeroAPI side (I am not saying it is), this might be a workaround. You did say you were burning a DVD image in your original posting, but I am not sure this is what you really meant.

My question now would be, what exactly is Nero checking during the ‘Checking discs’ phase and, since it is a check, is there a chance that the check can fail and if so should NeroBurn be exited with an appropriate error code.
I am unaware of the details but presumably if the check failed, the process would have terminated itself with no outside intervention. Monitoring the major phase callback might reveal more details.<!-- / message -->


#5

All major phase callbacks generate a log file entry.

The burn stopped at 85% on Dec 27th, and was exited today. The app was still running, menus and dialog boxes all working for example.

The two ISO trees should have been identical as the app stops building the file set once the size of the set is, approximately, 90% of the disk size. It takes a file to add, works out the size of the set if the file were to be added and either adds it or starts the burn process. I will re-check my code on building the ISO tree but, from memory, it is based on one of the SDK samples.

I did not use the “image recorder” and then burn the image. That was just an unfortunate description on my part.


#6

Sorry. The ‘Checking Discs’ process stops at 85% NOT the burn.


#7

Can you check that NeroAPI cleanup is done properly?

The two ISO trees should have been identical as the app stops building the file set once the size of the set is, approximately, 90% of the disk size. It takes a file to add, works out the size of the set if the file were to be added and either adds it or starts the burn process. I will re-check my code on building the ISO tree but, from memory, it is based on one of the SDK samples.
Well, I cannot ask you to post source code as it must be pretty big but I guess something must be different. One would expect two identical ISO trees to have the same burning outcome.

I did not use the “image recorder” and then burn the image. That was just an unfortunate description on my part.
Actually, that was also a suggestion. It shouldn’t be too difficult to change the code.


#8

Thanks again for the replies.

The Nero clean up operation complies with the API sample code.

BOOL CNeroInterface::CleanUp()
{
BOOL bRetVal = TRUE;

if(m_bNeroInitialised)
{
	//	from NeroOpenDevice
	NeroCloseDevice(m_NeroDeviceHandle);

	//	from NeroGetAvailableDrivesEx
	NeroFreeMem(m_NeroDeviceInfos);

	//	from NeroGetCDInfo
	NeroFreeMem(m_NeroCDInfo);

	NeroClearErrors();
}

WriteLog();

if(NeroDone())
	bRetVal = FALSE;

NeroAPIGlueDone();

m_bNeroInitialised = FALSE;

return bRetVal;

}

Also NeroFreeIsoTrack and NeroFreeIsoItemTree are called after the burn process finishes and before the cleanup operation.

The ISO tree is not built until enough physical files have been copied to the CD image directory on the hard disk.

Exiting the app would only have the effect of rebuilding the ISO tree from the same files in that directory and therefore the ISO trees would be identical, and probably was as the checking disks process stopped both times.

By getting my customer to delete the file set all that they have done, via the app, is delete the physical files from the directory. The app would then have rebuilt the file set, which would simply copy same the files back to the CD image directory on the hard disk.

Since this worked I can only assume there was a problem with one of the files in the directory (but not sure what that problem could have been). If this is the case then I suspect that this caused the ‘Checking Disks’ section to fail but without generating an error.

If the copied files were exactly as before then the ISO tree built would have been exactly the same as if the app had been exited, and should have failed once again.

Most odd.


#9

I now have the answer to this problem. It reoccured the day before I was due to visit my customer, and was able to see it in action.

As before my app had built the directory structure to burn to DVD and it failed during the Checking Disks phase at 85%.

What I did to try and find out what was wrong was to run Nero Express and added all of the files in the directory structure my app had created, to a session ready to burn. I noticed that the size of the files was ever so slightly over the yellow marker to show the disk capacity and when I attempted to do the burn the program told me that there was not enough disk space to complete the burn.

In re-programmed my app to start the burn process when adding a new file would have left less than 100Mb of space. After this the DVD burned without fail.

My question now is that since Nero Express knew that there would not be enough space to do the burn, why am I not getting the same error message at some point?

As usual I am probably missing something obvious but your help would be appreciated.


#10

Do you allow overburning? Could it be that you are not handling all messages in your user dialog callback? If using a recent Nero and NeroSDK you should always return DLG_RETURN_NOT_HANDLED for messages you do not support nor care about. It could be that the NeroAPI is asking you something and you return a wrong default answer which gives you the undesireable behavior you are seeing.