LIGHTNING UK!

Either it's just given up and not burning anything correctly or there's some other issue with your machine. Have you tried a cleaning disc in the drive? Oh and try burning at 8x or 12x As you can see, 2x isn't even supported by the drive / firmware. If it's still doesn't work, throw the drive in the bin! (maybe try it in a different pc first though, or another drive in yours)

Happy Birthday! (probably too late now - doh!)

Different media is indeed the way forwards! Well, that and firmware - but yours is already 'current'.

When you read a disc, it's read sector by sector. i.e. what goes in is what comes out. If you need compression of some sorts, you need to look elsewhere. ImgBurn is a burning program, not a compression / transcoding /re-encoding tool.

Learn how the program works, read the guides.

If you're already using MKM-001 discs, stop wasting any more and just buy a new drive.

I never said levels were the problem

You'd need to reauthor them and that's not something you do with ImgBurn. Google it, I'm sure you'll find something.

Yeah and personally I'd stick with buying the MKM-001 (2.4x speed) discs too!

Hmm ok, having tested 2.3.2.0 with some deep folders (18 levels), it's working ok here. I can't even extract (using WinRar) a file whereby the resulting folder structure exceeds the lower limit, it just complains. Windows won't let me create any more files / folders beyond the limit either. This is as far as I can go: C:\TestLongPath1\TestLongPath2\TestLongPath3\TestLongPath4\TestLongPath5\TestLongPath6\TestLongPath7\TestLongPath8\TestLongPath9\TestLongPath10\TestLongPath11\TestLongPath12\TestLongPath13\TestLongPath14\TestLongPath15\TestLongPath16\TestLongPath1 It wouldn't even accept '17' for the folder name! I put 4 files in the 'TestLongPath16' folder and ImgBurn found them all just fine. So even Explorer itself can't cope with long pathnames. Having now just tested 7zip, it DOES allow files to be extracted beyond the limit. Of course they're then not visible within Explorer, it simply won't let me change directory beyond that initial limit. You'll be pleased to hear the changes I've made within ImgBurn DO allow it to read the files that explorer can't see though.

Ok, glad you've updated it a bit. I believe 1.06 is newer still though. Please go and read the 'Guides' forum to see what that 'Auto' write speed means. I don't think you've understood the idea of it.

You can't force the program to terminate, not even through taskmanager. Once the DeviceIOControl command has been called, that's it! The OS has control and ImgBurn can't do anything about it. When it returns control to the program, the program will know to quit if that's what you've told it to do. Back to the actual error.... You're getting issues before the 'Write' commands are even being sent. That's never a good sign. Your drive simply cannot handle those discs at the moment. Go and update your drives firmware and then try again. http://forum.rpc1.org/dl_firmware.php?download_id=1973 (Updating the drives firmware is the FIRST thing you should have tried)

All done

You might be exceeding the MAX_PATH character limit. I know there is a change I can make for the new (ish) implementation of unicode versions of the 'FindFirstFile' API function to extend it beyond the 'MAX_PATH' (255/6 ?) limit and up to 32767 chars, but I've not done it yet - never needed to! So all I can assume is that the function is failing or whatever and so ImgBurn doesn't see them. I'll look into tweaking the functions so the 'MAX_PATH' limit can be exceeded ready for the next version. Ta.

Your drive doesn't appear to like that media much. I don't know the specs for the drive, but the media is 16x and your drive is only reporting 2.4x as a supported write speed - that might just be a 'generic' one. You might like to try a firmware update, but it all depends on what machine the drive came with - I'm guessing Fujitsu. http://forum.rpc1.org/dl_firmware.php?download_id=1930 If there are no firmware updates, look at buying some older media, say some decent 8x stuff. I recommend Verbatim / Taiyo Yuden.

Indeed, ISO9660 is 32, Joliet is 16 and UDF is 126 (or 63 unicode). There's no issue using what's available to you.

I meant I've done it ready for the next version.

Which DL discs are you using? (Verbatims are the only ones worth buying) Is your drive's firmware up-to-date?

At this stage, I've no idea! It could be any number of things. As asked earlier, is this happening with a range of discs? i.e. CD's, DVD-R, DVD-RW, DVD+R, DVD+RW - all different makes/dyes? Have you tried changing the cable(s)? Have you tried following the DMA post in the FAQ? Doing that process can sometimes fix odd problems like this. Have you got any dodgy filter drivers installed? Take a look in the option on the Tools menu. Copy + paste the info here. When you've done all that, get the program running without any discs in the drive. Then press F8 to enabled I/O debug mode and insert a disc in the drive. When it's finished initialising it, press F8 again to disable I/O debug mode. Save the log to a file and upload it.

Hmm, obviously the first thing you notice is that the drive reports the media status as 'complete' rather than 'empty'. Then we see it's missing the pre-recorded info and also the supported write speed info. Do you have *any* other discs besides these to see if they're initialised / reported correctly?

Switch into Write mode and then copy + paste all the info from the panel on the right.

It's done automatically before you burn - and DVD+RW supports 'direct overwrite' so you don't need to keep erasing/formatting before you can use the disc again. If you do want to do it manually though you can either click the button as shown in the picture, or you can click 'Tools' -> 'Drive' -> 'Erase' -> 'Quick / Full'.

So you're telling me DVD's don't have 7 layers?

It changes to high when it's burning.

1. Try removing the appropriate line within the IBB. If it's not there (and unless this is a more recent change!), it won't wipe out the CLI custom destination file name. 2. No - but it will be possible in the next version using '[DATETIME]' or '[DATE]'. 3. Erm... No?