6000+ Burns, first time hangs on 'reserving track'

[Beck38]

I've been using vr. 2.5.8.0 since it came out, was using commercial programs before that, but I've never run into this particular problem.

 

Looked it up and found that many others have run into it upon occasion, don't really see why it came out of the woodwork right now.  No changes to the machine (Vista64) other than the usual weekly 'fixes' by m$.  My burner is the tried and true Pioneer 205 that's burned almost all my discs except for about the first 500 which were done by a very old Sony back 10+ years ago.

 

Burning about 1 disc per day on average, started doing BD50's some 6+ months ago, Ritek 6x (burned at 4x) no problems whatsoever.  Zero 'coasters'.  All play just fine on multiple systems, both linux and consumer. 

 

Then I hit this 'reserving track' error.  Size of data is well within the 50GB of the disc, somewhat less than 48GB.  

 

I've read through all the topics that are listed here where folks hit the same thing, and don't see any real 'solution', just the usual/typical response: replace your drive, replace your firmware, replace your OS, replace your (put whatever here).  I simply don't see any specific reason as to why the program generates this error, other than some internal calculation tells it that the media doesn't have enough room (although it does) and exactly where that limit is, is not well defined so one can easily burn data larger than that which triggered the error, just that it doesn't trigger something in the program that tells it that is 'too large'.

 

So this problem has been out there for awhile, and probably is going to be seen more often now that BD50's are more common/lower priced. 

 

So in the meantime, what exactly is the 'trigger' for this error, and if indeed the program is somehow not seeing enough space on the disc, one doesn't get that 'disc too small' message (I used to get it all the time burning DVD9's that were just a bit too large).

 

 

[LIGHTNING UK!]

I don't know why you think this is an issue in ImgBurn. If you're read the previous threads, you'll see I've said that when that message is in the status bar, the program is simply sending (has simply sent) the 'Reserve Track' command to the drive with the number of sectors it wants it to reserve. It's one of the most basic commands you can get in the world of optical drives.

 

Once a command has been submitted, ImgBurn has to wait for a response. That's it, period.

 

Your drive should either process the command successfully and return 'ok' or fail and return an error. ImgBurn will continue waiting until one of those two happen.

 

If something else in your system is preventing the ok / error from reaching ImgBurn, I'm afraid that's out of my control.

 

As to what might be causing it - either in terms of software or the drive just getting 'stuck' - I have no idea on the root cause and I can't do anything to diagnose the problem because I'm not the one sat at your PC. It's something you have to troubleshoot yourself and that means a bit of messing around an potentially trying different hardware etc. (which I do understand isn't an option for a lot of people).

 

The program sees as much space on the disc as the drive reports to it. All of the sizes etc. are in the disc information pane and written in the log at the start of the burn. You'd also get a warning the second you clicked the 'Write' button if what you're attempting to burn won't fit on the disc.

[Beck38]

If your program refuses to exit upon that (exit) command being issued, then this is a programmers error, not the operator or anything else.

 

This occurs on 3 (three) different BD burners in two different manchines (two different OS's), all running the most recent firmware from the manufacturer, including one model that is the newest BDXL drive.  The fact that many folks that report this error have found that the only way to end the program is up to and including a hard (power cycle) reboot is fairly serious, although I have been able to end the Imgburn task  through the windows task manager every time.

 

The DL discs used are properly id'ed by several programs, so exacly why Imgburn is not recognizing them is a good question, and why burning of discs right up to the 'limit' of the disc space have proven to work and be good with no errors.  The only other possibility is that it's somehow figuring the size of the data to be burned (from the HD space report) is somehow being figured wrong, or (see below).

 

Without looking at the source code (and I'm not about to, I have way too many NDA's that cover what I can do and can't, and will not spend good time/money getting my lawyer to review things) it does appear that burning certain disc sizes is falling into a programming 'trap' of some kind. 

 

In short, I'l guess I'll have to get a commercai burning program, something I haven't done since the early days of Nero and the like.  Perhaps you will eventually realize the problem exists.

[LIGHTNING UK!]

Can you show me anything that actually shows there's a size issue here?!

 

There isn't one. You're barking up the wrong tree.

 

Even if a disc only has 10 sectors and I issue a request to reserve 20 (because I'm stupid like that), the drive would hopefully be more competent and return an error.

 

What's happening is the deviceiocontrol API call is being issued and control is never being returned to the program.

 

Don't forget that imgburn always issues that same command. The only thing that changes is the number of sectors it asks the drive to reserve. I'm happy to show you the error your drive should be returning if you attempt to overburn a disc and the 'reserve track' command returns an error. What it should never do though is just get stuck.