Defenestration

No rest for LUK until he releases version 2! Only then can he have a 5 minute tea break (and that includes boiling the kettle).

Maybe it's because I'm running it on a laptop, although I do have a 7200rpm drive. I also use the Firefox web browser and have lots of tabs open at a time, which uses up a lot of memory. After a while the memory gets paged out to disk and when I go back to the browser, the memory gets paged back in causing high disk activity. I may also start another app during this time which adds to the disk activity, resulting in high queue length. I don't set out to cause the high disk access, but it does seem to occur quite often on my system. I would never purport to be an expert in anything but the way you've implemented it sounds perfect to me, even down to being able to tweak each value. As always, I appreciate your hard work LUK! <thinking>Hmmmm.... what else can I ask LUK to implement... ?</thinking>

Awww... shit, and I've just had another 2000 delivered. I'll probably be OK if I just use them for long term archival purposes That was a bit lax on my part but hey, that's what you're being paid for! You ol' charmer LUK. No one's ever said such a nice thing like that to me before. You know more than me about how interruptions during a burn affects quality, but from what I've read (and I believe everything I read in the "Daily Star" and "Sunday Sport"), these interruptions affect burn quality (although I've never done any tests myself). If this is in any way true, then please implement both features (including the anal one) because.... a) if you implement the 100% thing, then the disk queue length adds more robustness, and is not really any harder to do (ie. just another lookup to get the queue length, and then including this info in the if/while statement) b ) as the Erase RW feature has proven you like to do things the correct way, and also checking the queue length fits in with this philosophy. c) the whole point of implementing the 100% thing is to minimize the interruptions in the burn procedure. However, if you don't also implement the queue check then the problem is only half solved (since at times of high disk activity, the buffer could be re-filled to 100% and then just empty again due to high disk access from other apps/processes) since the original problem still exists in times of high disk access. EDIT: d) Most important of all - Because I say so! While a lot of new drives may not suffer from this linking problem, there are also a lot of older drives still in use which do have this problem. It's because of this, and my argument above, that I ask you to reconsider implementation of both points.

When the buffer empties during a burn (eg. because of high disk access by other apps), ImgBurn will continue with the burn as soon as some extra data has been placed in the buffer (ie. it doesn't wait until the buffer has been fully filled again (ie. reached 100% full), and also doesn't wait for the disk queue length to lower). With Nero, when the buffer empties during a burn, Nero waits until the following condiitions have been reached before continuing with the burn... 1) the buffer has reached 100% full 2) the disk queue length has reached an acceptable level. I haven't done any real quality tests, but I would guess that Nero produces better quality burns in this example since it waits until it has a full buffer of data, as well as waiting for the disk activity to lower. IB, on the other hand, will burn in continuous spurts (ie. LED flashes on/off) during this time. You can use the performance counters to determine the current disk queue length (which indicates high disk activity) - to see them in action, run perfmon.msc and add the Average Disk Queue Length counter. This would improve overall burn quality when system activity increases during the burn. One other minor point I noticed is that ImgBurn cannot find DVDInfoPro when clicking 'Display Graph Data using DVDInfoPro...', if DVDInfoPro is installed after ImgBurn is running. This tends to indicate that IB checks once when launched. Granted, this situation is not going to occur often, but it would be better design if IB checked for DVDInfoPro dynamically (ie. when needed).

Aha, but you are using the latest and greatest IB v2. For those without v2, we have to use other apps in some cases when we want to burn files (and not ISO's). You're one step ahead of us, as usual.

OT - Hey Mav99, what XP theme are you using ?

On this issue, I swing both ways (oo-er missus!) in that I can see the logic behind LUK doing it the correct way, while at the same time seeing the need for only doing a quick format. The ideal solution is to make the full format optional, as suggested by ADude, so people can choose to either keep the current behaviour or leave the disc "in limbo". BTW, I'm curious as to the cons of not doing a full format in these cases when a disc has been left in limbo ?

With or without a parachute ?

Not furiously enough! Now, where's my whip.......

Didn't know that. Thanks for the info. I always thought you just needed to put the relevant DVD-Video files in a VIDEO_TS folder. Now I know better.

Feck! Girls! Drink... Drink... Drink!

Yet... Nudge nudge, wink wink, say no more. A nod's as good as a wink to a blind bat! This feature along with the ability to create ISO from unprotected CD/DVD and the ability to copy unprotected CD's/DVD's would mean I could elope to Las Vegas with IB, get married at a drive-through by Elvis, and burn to our hearts content, never to be seen again.

I guess I'll stick with SPTI then for reliability, although I prefer running in a limited account most of the time for security reasons unless installing apps or doing some general admin stuff. Interesting trick chewy. I'll give that a try myself, although it tends to suggest there might be a problem with Windows if it's allowing access to certain parts of Windows which it shouldn't, when running under a limited account.

From I recent topic I discovered that SPTI does not work under limited user acounts on XP. What are the various advantages/disadvantages of each I/O interface, and which one(s) can be used under limited accounts ? Has SPTI been chosen as the default simply because it's included on each OS version ?

So it can be run under a limited account without this error occurring now ?

You could, if you were inclined, add a workaround so that once the erase had reached 100% for the background erase, it would check to see if the percetage being sent is less than this. If it is, ImgBurn would not change the display. On the other hand..... you could not

I've just done another erase of a DVD+RW and below is the last part of the log for this erase with I/O Interface debug logging enabled. I've highlighted the line where it reaches 100%, after which the drive sends 0% (ie. 00 05) for about 5 seconds. As the status is '80', I guess it's the drive at fault then. Is this common with drives ? BTW, as the drive can only report a maximum of 65535, I would suggest that you should use this value instead of 65536 in the percentage calculation. Yet another showstopper moi has spotted

All hail the Worshipful Master LUK! I actually happen to be a member of their armed militia, the SKK Time for me to begin my quest for membership.... =))

OK, I'll check Sense Area info the next time I do an erase (probably tonight).

I understand what you're saying, but I'm not so sure. It took quite a while to get up to 99% (I assume because it was the background part which was actually doing ther erasing part). The 0% occurred after this and lasted only a few seconds before continuing with the burn of the ISO. Is there no part in the IB code which could cause this after an erase, but before the burn (eg. displaying static text, or static text built with the percent variable) ? I will check with the F8 when I next do an erase and report back here. Thanks for the info about the taskbar text. I'll try to reporoduce this in VC++.

I've just burned my first image to a RW DVD disc (DVD+RW) and before the burn ImgBurn promted me that the disc had to be fully formatted before use. I clicked OK and the erasing procedure begain. At the end, the Imgburn status bar showed "99% - Erasing" which is OK, but then showed "0% - Erasing" for a bit until the burn procedure started. It would be nice if at the end of the erase, the drive showed "100% - Erasing" or 'Preparing for burn...' (or something like that) Now, I know you say that Imgburn only displays what the drive reports, but this "bug" does not appear to fall into that category. --- You can count on me to only report the really important showstopper bugs! A couple of questions: 1) When using a RW disc, does Imgburn always leave it un-finalized after a burn (ie. you have to use the menu option Tools->Drive->Close->Disc to do that) ? I ask because <spit> Nero has an option on the burn dialog "Allow files to be added later". 2) A programming question - During the burn, the taskbar button for ImgBurn shows the percent complete, but the ImgBurn window title bar does not. How do you do this because I thought the taskbar button just used the text from the window title bar ? 3) My DVD+RW discs are only rated at 4x, but the Write Speed was left at 12x (ie. the speed I normally burn DVD-R's at). The burn completed at 4x, but I wanted to clarify how Imgburn works in this regard. If the selected speed is greated than the DVD burners rated max speed for this disc, does Imgburn just use ignore the specified speed and use the burners rated speed instead ?

How do I enter the inner-circle ? Is the initiation ceremony anything like Homer Simpson's in the season 6 episode "Homer The Great" ?

OT - I'm currently deciding on which forum software to use for my website and wondered why you picked IPB (as opposed to vBulletin, phpbb etc.) ?

You're a star LUK! Can't wait for IB 2. Any update on when we can expect a new version or beta of it ?

=))