LIGHTNING UK!

If Verbatims don't work either, clean your drive or buy a new one. The error is from the drive producing low quality burns which it then can't read back - or that the reading in general is messed up (cleaning may fix that, along with improving write quality). Never assume that because your mates drive / media combo work that yours will too. No two drives are created equal - nor are two spindles of discs.

lol it says VOLUME LABEL, not VOLUME LEVEL. The two are very different things. ImgBurn has *nothing* at all to do with volume levels - it doesn't even really care about the content of the files you're burning - everything is burnt as-is.

The program automatically changes the booktype to DVDROM on Samsung drives. What exactly is the error that your player is giving? By the sounds of it, your player needs a clean or you need to get a new one that *does* play your discs. Everything in that log looks fine to me.

What happens if you press the 'audio' button on your DVD player's remote control? Wouldn't it be easier to find yourself a cheap dvd player that accepts AVI file? Then you wouldn't have to mess around with this stuff at all.

It doesn't really matter. If your source files are too big for either one of them (whatever's selected) it'll build it as if it's a double layer disc - with a layer break position etc. Of course if that happens you've got a whole other bunch of issues! I doubt any authoring package would spew out files that ONLY fit on DVD-R (which I believe is the bigger of the two and so probably the default anyway). The 'Media' tab in ImgBurn does nothing more than provide ImgBurn a little guide as to how and when it should build an image as a DL image.

I really wanted to write a sarcastic reply but I can't be bothered. Try to post something we can actually work with - i.e. a log / screenshot or at least a bit more detail!

The problem is not with ImgBurn, ImgBurn just burns the data as-is. Try the DVD Flick guy.

Extract the contents of each ISO and then make a new one based on it. Normally places offering CD sized downloads will also do a DVD one - and then you wouldn't have this problem.

That's the whole idea of the 'add to write queue when done' option. You do still have to switch modes though - handy if you want to do multiple reads and then multiple writes.

You might find your drive has just worn out. Try cleaning it and if that fails, be prepared to buy a new one.

You can't rename a vob to an iso, it doesn't work like that. Preparing the source files is nothing to do with ImgBurn I'm afraid and so it's something you'll have to figure out yourself. Needless to say, the VIDEO_TS folder should have a whole load of IFO, VOB and BUP files in it. If it doesn't, there's something wrong with it.

Nope, nothing to do with it.

That latest log showed you burning 41MB. I'm sure that can't be a complete set of DVD Video files!

Seems Microsoft changed the default performance counters visible between XP and Vista. I was going by what XP (or in my case Server 2003) shows but it appears you're on Vista - so really it's all my fault Yes it would be better to use the individual drives queue length.... but only sometimes! (I did kinda say that in my first post when I said it was my problem and not yours!) Disk activity in general will slow the system and of course the same hdd could be partitioned several times. I cannot ignore those other partitions and it was just too much of a pain to attempt to get it perfect for the number of times this issue would actually crop up - you're the first I've heard of where it waits for an unreasonable amount of time. Not only that, the burn code is the same for all modes and whilst it would be possible to get the source drive for an image burnt in Write mode, it's a whole lot harder when burning loads of folders/files in Build mode!

Yeah that's cool, I figured that was the case. It's just you said it was on 1.7 when idle in an earlier post. It must not have been quite so idle then as it was in the 0.731 pic

Build mode was designed to be basic and burn an existing folder structure 'as-is'. If that ever changes, the things you mentioned will be possible. It's my own code.

As mentioned in post 8, yes it's an average over ALL the drives, not just the 'source' drive. So any activity on any of the drives would push up the average and mean ImgBurn keeps waiting.

Those pics only show it going up to 0.731, which of course is still below the 0.8 default value in the settings - hence it wouldn't be waiting.

It could be anything where the disc is too busy/unable to process all the I/O requests. That's the idea of the 'Disk Queue'. If there are lots of I/O requests being made and the drive is too slow to cope, the queue length obviously increases - until a point where I guess the OS just rejects them or something. Is your drive a slow/old one? Is it partitioned / compressed or anything? You can see the queue length I get in that screenshot... I have quite a beasty hdd setup and it's almost always on zero when I'm not doing anything and it's hard for me to judge what a 'normal' setup might idle on. This might be useful: http://technet.microsoft.com/en-us/library/aa997558.aspx

If yours is at 1.7 when the machine it totally idle then I guess you need to change it from the default of 0.8 to something like 1.5 - otherwise every time the buffer recovery kicks in it's going to take forever to start burning again. 1.7 does seem a tad high though

cynthia, This is perfmon. 'Average Disk Queue Length' is one of the standard performance counters. The range 0 - 5 is just my own one, it's doesn't mean anything outside of Imgburn (you could use any range).

No, just change 'Output' (menu at the top) to 'Device'. Then it'll write whatever you add to the 'Source' box directly to your drive without going to an image first.

All of that info is already written to the log - so just don't close the log window.

It stops working in one way or another and you've already tried decent media and new firmware. It's a technical thing, probably best to Google it!

This is probably more my problem than yours, I believe it takes the average queue length of *all* drives rather than just the *source* drive, so that's why it took ages to recover (the drive you were installing to was still busy and therefore pushing up the average). Of course that doesn't really explain why the buffer went down below the threshold level in the first place - but I believe that's just the way windows works. Doing a lot of I/O on one drive will slow down all of them. Raising the buffer won't actually make it recover any quicker - if anything it'll take longer as there's more buffer to fill (but it could make the pause less likely to happen in the first place). To make it less sensitive to disk activity (and therefore start back up faster), you'd need to increase the 'Avg. Disk Q' value. The program won't start back up until the 'Average Disk Queue Length' drops below the value you set - you can monitor that value by running 'perfmon.msc'.