LIGHTNING UK!

It is from hitachi, as you mentioned earlier. I just found it over at cdfreaks and put it on for testing on another reported problem.

Sorry, no. It's burning tool, not a shrinking one.

Yeah that's how it is now. value at 0x0c is just last lba in bup - first lba of ifo. I believe that was was already ok. For Last Sector of VMGI, I'd taken sectors in IFO (-1) and added amount of padding (in sectors) applied to BUP. I honestly have no idea why! lol As it's normally 0 unless there's no VOBs or a small VOB, it's not a problem that occurs every time you build. Oh and I don't always remember everything - again I'm only human - when that happens I just look on mpucoders site!

It's all part of the fix vts sectors bit of code. I have to update 0x0C offset for end of BUP, I then just updated this one too for good measure - the two seem to go hand in hand. I made a mistake and calculated it all wrong. Silly me! I guess I am only human after all

I did notice you're burning via some other program, unless you're actually manually setting the layerbreak position in the settings - is that correct? Just wondering if you get the same problem loading the ISO manually in the program. I (nor any othe beta team) have reproduced this error so it's tricky to fix. Code wise, everything looks as it should do. If you can find v1.3 on the web, try that version and see if it does the same thing. (You'd have to test it a few times to be sure it wasn't fluke!)

I know we posted at the same time blu but this is one of the bugs fixed in the betas you're now using.

I think this is the same problem mentioned in the 'bugs' forum. Namely, incorrect (or in my case, very weird!) calcualtion of IFO size, as then written to offset 0x1C in VIDEO_TS.IFO / BUP. It wouldn't matter if you had run the files through PgcEdit. If the 32k padding comes into play, ImgBurn would change stuff and put the wrong value in the IFO.

Maybe one day, there are certain things beyond my control that need to be considered though.

1. Fixed. 2. You can now use the '|' character to seperate multiple entries (files/folders). 3. I've added a /rootfolder cli command for this purpose.

Your JL11 is supposed to have updated strategies in it I believe. Perhaps one of those 'updates' messed it up?!

Ok, it might be wm_quit instead then! anyway, now that you've gone to all that trouble, I've gone and added a /closeinfo cli switch that will close the app down once the info has been written to the file. You are of course free to continue using the alt+f4 method if you so wish

-R has always been more compatible with players. I doubt you'd find one now that can't read them. btw, did you say all your ricoh discs have this error in the middle of the burn/verify? I've burnt that same dye on mine and never had a problem - that I can recall. I am using the JJ11 firmware on mine though, not the other one. http://forum.imgburn.com/index.php?s=&...ost&p=19071

1. Although the documentation appears to be wrong, it is actually correct! The path without the trailing backslash is passing the CLI parsing code ok because it looks like a file. The folder is blocked (well, ignored) because it's failing some other check. I'll fix that. 2. No, sorry. 3. No, sorry. There is now (ready for next release), but only for gui purposes. If you set it in advance, even when you load ImgBurn with CLI parameters it'll still use that value. I guess I could add an extra cli switch now though and I'm sure that would be the better way of doing it.

You probably have to get the right window handle, I'm sure it should work... not that I've tested it of course! Borland apps have hidden main windows so you may need to send it to that one - or vice versa if that's what you're doing already. Also, try it with a delay after finding that the info file exists - incase it's busy with other stuff and so I'm not letting it close.

I've had a little mess around with where the 'Disable MCN' stuff kicks in, and basically moved it to the places that count rather than being active from the second the program is loaded. So now it just disables it during write/verify/erase. Once re-enabled at the end of a burn/verify/erase, I also refresh then drive handle (close / reopen). That makes Windows spring into action and read the drive - hence refreshing it properly. This all happens just before you click the 'ok' button to the 'operation successfully completed' messagebox. It all seems to work ok on my pc, now to let the beta team have a little play.

HDD Tools could benchmark it db! If you get over ~1mb/s, it's running usb 2.0 hi-speed.

I would prefer to read the log without the debug info, it doesn't actually 'add' anything here and infact means I miss other bits I want to read. It's very odd that the entire program locks up... that 'waiting' is done inside a thread and so would have no effect on the GUI at all. Out of interest, are you able to cancel a burn without this problem? Try it on a -RW/+RW, or use 'Test Mode' on -R media. Just set it burning and then stop/cancel it after a minute or so.

Not during the burn it won't and so it's pretty pointless in this situation.

ImgBurn just issues an eject command, it then issues the load command. That's it! It's pretty hard to get that wrong, even for someone like me I guess the only difference is that ImgBurn issues the two commands straight after one another - and who knows what really happens (internally) when you manually press the eject button?! I don't know if it emulates sending those commands or acts on a completely different level.

I honestly don't know myself. Try it and see! No harm in it just sitting there anyway is there?

It means the drive starts a fresh and has to go through the initialisation stuff all over again. As you've seen yourself, that doesn't always work! You're lucky in that it worked second time around after another cycle of the tray - for many people (normally burning really bad discs), it does not. Once the tray has been told to go in (inserted), the drive will initialise the media when it's ready. We have no control over that. Not having the ricohr03 thread open (and being too lazy to open it), I can only remember the burn on the plextor was awful. I personally prefer the DVD-R version of the TY media, I don't find the +R's are all that good.

hmm nope, I don't think that's possible currently.... nor will it ever be I suspect. It would be too much faffing with 'if this options set and this one isnt etc, do this, otherwise do that'. Basically it's just not worth complicating matters. Best I can offer right now is to check for the file and then send the imgburn window the 'wm_close' message.

Click on the 'Modified' column in explorer! lol %d and %D use the system wide date formats (being the 'long' and 'short' ones), I don't format them that way manually - but I'm sure you already knew that.

That pretty much just means the drive is failing to initialise the disc that first time around. No software can access (read / write) the disc until it has initialised it properly. The problem lies between the drive, its firmware and the media. I had actually implemented an auto-retry mechanism for when that happens but that particular error code (the 'Logical Unit not ready, Cause not reportable' one) is not in my list of 'common' faults and so it doesn't kick in. Although you could indeed just tell it not to eject, that's a workaround, not a fix. The best fix would be to try some (and switch to) other media (not ricohjpn r03) and see if the same thing happens. Going from the 'Drives & Media' test forum, I don't think they're really all that good anyway.

Nope, but one of the above should work anyway.