LIGHTNING UK!

Yes, besides being made for images using file splitting, it’s made for anything with a layer break and for anything under 1gb in size - as that’s the cut off point for daemon tools to emulate a cd rather than a dvd.

Try another usb port / cable etc.

I don’t recall them ever actually releasing rewritable dual/double layer dvd media. I guess they had their reasons for that, but I’m afraid I don’t know what they were.

It might be the 'Delete Incomplete Files' option on the Events tab in the settings.

It might be tied to the batch mode checkbox.

It won't *only* be making the mds file, the ISO will be there somewhere too. Make sure Explorer is configured to show file name extensions.

You're also burning at max speed. Try slowing it down to 3x or 4x.

The log only gets saved when you exit the program. If you haven't done that yet, copy and paste everything from the log window instead (use CTRL+A to select all of the it). Your posts are missing key info that we'd normally easily get from a complete log of a burn/verify operation.

When using file splitting, it would be making a layout file. As it then knows it's made one, it would load it. You're in a situation where no layout file has been made, but one exists... therefore you run into the situation where ImgBurn basically tells you off for loading the wrong file. I could perhaps silence the prompt when it knows no layout file has been created but one with the correct name (as per the built in checks) exists.

On quick examination of the code, if the program thinks it has made a layout file (CUE/DVD/MDS etc), it'll use that file when loading into the Write mode queue - so you should not be seeing the message you're seeing. Do you always output to the same folder / file name? Your issue may arise if using the same output folder and file name - whereby one build HAS made a layout file but a subsequent one hasn't (the files from the previous build still exist). Write mode checks for the existence of a CUE/DVD/MDS file with the same name as the file you've loaded and then displays the message you're seeing if it finds one.

I'm guessing you must have the 'Add to write queue when done' option selected within Build mode?

Your machine probably lost connection to the drive and the I/O request has basically got stuck. If you unplug the drive, the program may well eventually get an error back from the OS that it can show you. You are using the Y cable into 2 USB ports yeah? You need one to be USB 3.0 for the drive to achieve the speeds it's capable of, but it may also need that little bit of extra power USB 3 provides over usb 2.0

It isn't, which is why the program wouldn't choose ISO for an Audio CD.

It'll use ISO for single session / track (mode 1 track) discs. For other CDs, it'll default to BIN (with the accompanying CUE file). I don't recall ever adding a setting that tells it to always use BIN/CUE - even for basic discs where ISO is easier and usually preferable.

It switches back to reading a block at a time pretty quickly, so any slowness is just where your drive is really struggling to read the disc. You should probably save images of them or burn to another disc ASAP, in case they’re eventually totally unreadable. Hard to know where the fault lies without trying to read those same discs in another drive. I don’t recall having seen that other error you mentioned before. That in itself probably isn’t a good sign!

That means the drive initially failed to read the block of sectors, but then managed to read them all when the program switched to reading them one at a time.

What were the 2 files you burnt to the disc?

Test mode isn't going to tell you anything useful anyway. The only way to see if a drive can burn the discs is to actually try burning the discs.

There’s no need for more ‘debug’ info. The drive reported a write error and that’s pretty much all there is to it. You could try enabling the ‘perform opc before write’ option, that may help your drive do its job. As I said though, all you’ve shown us is the log from test mode on a cdrw. Where’s the log from you attempting to burn the actual discs you want to be burning (before the multiple failures prompted you to use cdrw) ?

I couldn’t rename the entire mode just for when the box to compare against an image file gets unchecked Given the choice, you should always verify a disc against the source that created it. When that isn’t possible, I guess a basic read test is better than nothing.

I don't really class that as verifying, but yes, it would work purely as a read test.

Your drive reported a 'write error'. It didn't like something about the disc... which is weird because you've told it to use 'Test Mode' and the drive isn't actually meant to be burning the disc. I can't comment on any failures prior to that one (where you weren't using that CD-RW), as you didn't include log info for those.

No, it won’t work if you didn’t burn from an image file. Do the eject / load button seen under the box where you select your device not work for the pioneer? Maybe the belt is slipping or something. It just sounds like you want to try and get that working correctly again.

I don't actually know. That crash is from something to do with destroying the components on the main 'form' (window), but that's all handled outside of my own code and I've never had it happen to me when in the actual development environment - whereby I might then be able to look into it a bit more. Your issue could be causing that crash. Maybe sometimes the issue doesn't cause the weird characters, but still causes the crash on close. It all depends on how much memory is being overwritten. I expect the only way to catch the issue this topic deals with is to enable additional debugging stuff that checks for anything accessing bits of memory it shouldn't be accessing. Enabling it adds a lot of overhead though, so it would need to be a test build just for you to attempt to recreate the issue again.

The stack dump in that crash report shows a (familiar) crash from when you closed the app down. It didn't capture anything about what happened when the program was open and that weird stuff happened.