LIGHTNING UK!

Are you doing a full erase? Is this 98% something that takes minutes to reach, or does it only take seconds? I ask this because there are 2 stages to a DVD+RW erase / format. The 1st part (foreground) will only take a few seconds and if it's stuck at 98% on that, it's different to when it's stuck at 98% on the 2nd part (background) which takes much longer.

On top of what donta said, stop using 2.3.1.0, it was buggy and will mess up your burns. That's the whole reason 2.3.2.0 was released.

In the drives firmware. To be honest, I still don't think the drive can burn DL discs. Where it says dual, it probably mean dual format. i.e. DVD+R and DVD-R. Of course, if as I said above, it will recoginise a blank DL disc, maybe it can in fact burn them.

Try this firmware update. http://h10025.www1.hp.com/ewfrf/wc/generic...=en&lang=en

In post 21 donta? Building on the fly is not a fair test. It will use the file structure info that's already in memory. You have to burn + verify an existing ISO that lives on a networked PC.

Ok and did you try burning from an ISO file rather than on-the-fly? It really shouldn't be putting that much stress on your PC just to burn something. Oh and as for changing something in the code.... you've seen my changelogs yeah?! They're very detailed and if you look at the differences between 2.3.1.0 and 2.3.2.0, there's nothing at all that could be doing this. What does the task manager performance graph look like when you burn with 2.3.1.0 ? About the same or is the CPU much lower?

The reason the capabilities page doesn't list DL support (if indeed it does support it) is because the drive's firmware isn't reporting that it's supported. In any case, ImgBurn doesn't actually use that info. If you can put a DL disc in the drive and it can recognise it, ImgBurn will burn it.

ImgBurn won't backup anything that's protected.

The two lines in bold show the time taken to parse the file system (plus other stuff) when buring the Win98 SE ISO from a networked PC. Again, my 4 seconds is nothing like the 1 hour yours takes!

Unless you've got a 1Mhz processor, that's way too high. Click onto the Performance tab and click on the 'View' menu, followed by 'Show Kernel Times'. Get me a screenshot of the graphs on that tab when ImgBurn has been burning for a bit. You should have a green line and a red line. But before you mess about too much, I'd just quickly uninstall your IDE controller in Device Manager as per the DMA post in the FAQ and then reboot. Something just doesn't seem quite right at the moment.

Yes you need it open when burning. You want it on the processes tab. Just look for 'ImgBurn.exe' in the column on the left (Image Name) and then see what it's reading for 'CPU' during the burn. If it's low (i.e. not the 60% your CPU claims to be running at), find which process IS using a large amount of CPU.

It looks to me as if the machine just can't handle going over 11x and I've no idea why that is. The buffer is rock solid until it hits that point, then it all goes pete tong. Again, take a look in task manager (or process explorer) and see what's taking up all the CPU time. I find it very hard to believe that ImgBurn would be doing it on it's own.

How comes your CPU usage is so high? If you look in task manager, is ImgBurn really using up all that CPU time or is it sitting at ~3% where it should be? High cpu will mean low I/O and low I/O = buffer problems. Buffer problems = drive slows down (by itself, this isn't something the program does). Do you have the same problem if you don't build/burn on-the-fly, but go via an ISO file?

Ah, it works, but not if you just add the video_ts folder into the source box. If you add the parent one, it works ok. The same is true if you add the ifo/bup/vobs etc. Thanks for reporting it. Consider it fixed for the next version.

'Read' copies everything 'as-is', so that's the best way to get a 1:1. That said, ImgBurn won't copy a commercial (protected) disc, so if that's what you're trying to do, you're wasting your time.

The 'Last Attempt' at closing the track seemed to work ok, so in theory, it should be fine.

Most odd! Oh well, so long as it's ok for you now

Nope, sorry, I'm not seeing it. I built a few different ISO files, both with and without the option turned on. Everything looks fine if I examine the 2 folders containing duplicate files and note the files starting LBA address - I used IsoBuster for this. I also mounted the ISO I just made in DT and then did a binary compare between the files on the folders on the CD and the folders on my desktop that I'd just burnt. Everything checked out ok. Here are some pics to show you what I'm seeing... 1. 'Optimise Duplicate Files' - Off (Note the different LBA for the files, even though their content is the same) 2. 'Optimise Duplicate Files' - On (Note the same LBA for the files, because their content is the same) Even though these screenshots only show the Joliet filesystem, all 3 were identical.

Thanks, I'll look into it.

Please be aware that this is a potential problem for ALL burning programs and is not in any way limited to just ImgBurn.

The function that does the actual sending of data to the drive is not something I ever really have to change, and certainly not when going from 2.3.1.0 to 2.3.2.0. It's just a loop that reads data from the internal buffer and then sends it to the drive for burning. Just as shamus said... if you have an IBG file for the burns, we can see exactly what the buffer is doing during.

I guess you're asking this question because of the warning message in the Log window yeah? Well if you read it again you'll see it mentions 'Verify'. Due to the nature of AnyDVD, it changes data on the fly as it flows from 'Optical Drive' -> 'Software'. If you're trying to compare (verify) what's supposedly just been burnt to the disc against what you can then read back from it, any differences will show up as miscompares - hence anything that could potentially change the data as it's read from the drive will cause issues, IF it actually does so.

To be honest, I though anything that wasn't immediately visible would be of little use - i.e. not a tooltip and certainly not an option on the context menu! The smilies one is the best idea so far I think.

It's a shame the controllers seem to need to be in IDE mode for optical drives to work properly. A lot of decent PC's now come with SATA optical drives and a couple of HDDs in RAID on those same channels. As they're using RAID, the controllers are obviously on RAID or AHCI, which in turn kills some optical drives! Anyway, glad you sorted it

I doubt there's anything wrong with the burn. If it burns + verifies ok, the disc is free from errors and can (at least) be read fully in the drive that just wrote it. I suspect your problem lies elsewhere. Perhaps there is an update for the game to fix the issue? Maybe it's a common one?