Jump to content

Recommended Posts

Posted (edited)

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).

Edited by Defenestration
Posted

The DVDInfoPro stuff is actually a fault on their part.

 

Nic and I agreed on a reg key that I'd check for, and he'd update.

 

I did my part (which IS done each time it's needed), he somehow did his part and then deleted it again. Doh!

 

Shame on you for not running regmon and finding that out for yourself. :P

 

Anyway, he assures me it's fixed in the next version and he WILL actually write/update the key we decided on.

 

As for the buffer stuff, that's borderline on being very anal!

 

Waiting for it to reach 100% again is one thing (and something I've thought about doing on several occassions), but checking disk queue lengths is something you do to pass your MCP/MSCE exams - and for a little tool like ImgBurn, taking things a tad too far!

 

All the drives have zeroloss linking now so I very much doubt you'd see any difference at all in burn quality. In any case, with people out there still buying Princo and CMC discs, a couple of links are the least of their problems.

Posted
:o Theres problems with CMC and Princo ? ,next you'll be saying Ritek is down the tube ,this is how nasty rumors get started =))=))
Posted (edited)
:o Theres problems with CMC and Princo ? ,next you'll be saying Ritek is down the tube ,this is how nasty rumors get started =))=))

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 ;)

 

Shame on you for not running regmon and finding that out for yourself. tongue.gif

That was a bit lax on my part but hey, that's what you're being paid for! :D

 

As for the buffer stuff, that's borderline on being very anal!

You ol' charmer LUK. No one's ever said such a nice thing like that to me before. :wub:

 

Waiting for it to reach 100% again is one thing (and something I've thought about doing on several occassions), but checking disk queue lengths is something you do to pass your MCP/MSCE exams - and for a little tool like ImgBurn, taking things a tad too far!

 

All the drives have zeroloss linking now so I very much doubt you'd see any difference at all in burn quality. In any case, with people out there still buying Princo and CMC discs, a couple of links are the least of their problems.

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! :nunchucks:=))

 

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.

Edited by Defenestration
Posted

It's never been an issue before thru my time on the old DVDD forum or here........ Doesn't burnproof help prevent any quality probs in such circumstances too ?

Posted

I've been looking at this and God knows how you even get your buffer to empty out to test this!

 

I have to set ImgBurn to low priority, run defrag on the drive I'm burning from and use 'Search' to find files containing some random word.

 

Only then will the buffer start to fluctuate enough to cause a problem!

 

People doing that whilst burning deserve to be shot :P

 

Anyway, it's done now, so let's talk about limits/thresholds...

 

Currently set to main buffer being

It has to stay at these levels (it works on a counter, where count must be over 10 for it to do anything) for a short period and then the write thread is told to pause, fill up the buffer and wait for the avg queue length to go below a certain value - 1.0 by default.

 

The user can configure these settings should they be geeky enough to want to do so. :P

 

In your expert opinion, is that going to be ok?

Posted (edited)

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. :geek:

 

As always, I appreciate your hard work LUK!

 

<thinking>Hmmmm.... what else can I ask LUK to implement... ?</thinking> :)

Edited by Defenestration
Posted (edited)
You could ask him to take a break for a while.............. :innocent:

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). :D

Edited by Defenestration
Posted

just to add

 

nero tells lies anyway , it reports wrong write speeds , just check the amount of time it takes to confirm this.

 

forget the hdd speed, whats the max speed your laptops writer will write at ? regardless of hdd speed , laptops are extrememly slow in comparisson with a desktop set up .

 

as for emptying the buffer , well i test on an old laptop( only has an internal dvd rom , its that old), with a very slow hdd speed , and ive burnt to an external burner and dvd drive whilst doing all of the following at the same time;

converting an dv camcorder tape to vobs (very cpu and memory intensive)

browsing web

using MS word

 

i can even run shrink ( which slows the laptop down even when nothing else is running) and burn at the same time

 

ive even had the auto scan of my Anti Virus kick in before now when ive forgotten to disable it after a reinstall.

 

so im baffled as to how you can empty the buffer !!

 

sadly the releae of V2 will probably be delayed while LUK and the team double check/test for buffer underunning now :ermm:

Posted
Guess I'd better put another beta out then so you can all get started :P

Since I'm the only one who seems to suffer from these problems, maybe I can get a copy to test this new buffer underrun feature ? :whistling:

 

Well..., you can't blame me for trying. :P

Posted

so im baffled as to how you can empty the buffer !!

Give me something that can't be broken, and you can be sure I'll break it. It's a gift I possess. ;):D

You would have some tough competition from our own DB there. :P

Posted

Back to the DVDInfoPro thing, I just looked at my copy - version 4.61.4 - and it's making the key as it should do.

 

So perhaps you're not on the latest one?

 

Previously I only had 4.61.0 and that didn't create the key. I think the .4 revision was snuck out there when nobody was looking.

Posted
Back to the DVDInfoPro thing, I just looked at my copy - version 4.61.4 - and it's making the key as it should do.

 

So perhaps you're not on the latest one?

 

Previously I only had 4.61.0 and that didn't create the key. I think the .4 revision was snuck out there when nobody was looking.

I'm also using DVDInfoPro 4.61.4. Maybe it only creates the key after it's been run for the first time, and not during installation.

Posted
I'm also using DVDInfoPro 4.61.4. Maybe it only creates the key after it's been run for the first time, and not during installation.

Just done a few tests, and it is only created after it's been run for the first time.

 

BTW, DVDInfoPro does not do a very thorough uninstall as it leaves behind HKEY_CURRENT_USER\Software\SWN in the registry and also the DVdInfoPro program folder.

Posted

Guess I'd better put another beta out then so you can all get started :P

Since I'm the only one who seems to suffer from these problems, maybe I can get a copy to test this new buffer underrun feature ? :whistling:

 

Well..., you can't blame me for trying. :P

 

:lol: Nope we can't - you're very trying !!

 

 

I'm also using DVDInfoPro 4.61.4. Maybe it only creates the key after it's been run for the first time, and not during installation.

Just done a few tests, and it is only created after it's been run for the first time.

 

BTW, DVDInfoPro does not do a very thorough uninstall as it leaves behind HKEY_CURRENT_USER\Software\SWN in the registry and also the DVdInfoPro program folder.

 

Have you pointed this out to Nic W the programs author ? He might be as keen as LUK! to fix his program.... :)

Posted
I've been looking at this and God knows how you even get your buffer to empty out to test this!

I actually do this on purpose sometimes just to see how things are working with the s/ware. I start a burn from a network drive and then request the same image or another large file from the same drive using a few other PCs (Basically overloading the drive with requests).. It's guaranteed to empty the buffer and bring the burn to a complete halt. In this example, Burnproof does what it's supposed to do when the buffer empties. Incredibly, it worked fine last week, last month, last year, the year before that and the year before that and...........

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.