LIGHTNING UK!

Chinese whispers is like this: 1 person starts off by saying something (whispering) to someone else. "LFC likes football" That person then repeats what they heard to the next person. "LFC likes balls" (spot the accidential mistake - but seriously this is what happens in the game of Chinese whispers!) That person then repeats what they heard to the next person. "LFC likes malls" (LUK pretends he's in America) That person then repeats what they heard to the next person. "LFC likes shopping" I think you get the idea now EDIT: Damn, too slow. Shamus beat me again

Depends how well they're written I guess! All the I/O stuff has to pass through each filter before it reaches its final destination. Along the way, they can modify stuff, be it on purpose of accidentally. It's almost like a game of Chinese Whispers!

I 'plan' to get it out ASAP. Trouble is, people keep finding new things for me to implement and I want to do them before I release the next version. It'll be version 2 and so I want it to actually have some new / improved bits in it! Although the /info stuff is indeed in there and working, it's not the only thing currently on 'test' here during the beta stages. Sorry but I cannot make it available to you in its present form.... it's just not ready! Rest assured I'm working around the clock to get it done though.

I can see where that would have its uses. I'll try and squeeze it in somewhere!

It's actually very easy, the filters are just strings in a multi-sz reg key value. So you just delete the ones you don't want by editing the text. Do that, reboot and they're gone!

Yup, just put an empty ini file in the app folder and then when it closes, it'll populate it. It doesn't need to be complete during the 'load settings' part, it just needs to be there. Anything that doesn't exist in the file will just use the default values. It doesn't even need to be able to save the ini on close - incase of file permissions or read-only type stuff, it'll just exit quietly. That could be handy for Admins who want a fixed config that the users can't change.

lol well I've wanted the ini file one for a while actually! This just prompted me to get off my arse and do it!

The idea was to keep the main interface as simple as possible. Anyone who wanted additional functionality would use the queue window. The queue window just updates the main one with the options selected in it. (That's what happens when you bolt something on ) Not sure I'll go messing with this right now. It's working ok at the moment! lol btw, I've done your registry / ini file thing. /settings from cli, or [appname].ini in exe's dir are checked before defaulting to read from registry.

You're lucky this next version is going to be v2 ! A big jump in numbers deserves a jump in functionality. As such, this will be done ready for its release. I'd already implemented this in another app ages ago so it's just a copy + paste job really, with the addition of some checking that it's actually ok to refresh there and then, or if not, to queue it up for when it is.

It's always been set to high during a burn - as you've seen. No need to try and check for/prove otherwise Sorry, I don't know of any tools to monitor drive buffer usage outside of the burning app itself. Most apps (ImgBurn included) prevent other tools from looking at the drive during a burn, so they wouldn't work anyway. I'm somewhat amazed you see such a difference when switching apps, I have about 20 windows open and mine doesn't really budge! Take a look at the graph data output using DVDInfoPro. The buffer usage/cpu usage graphs might some some interesting stuff.

Follow what it says in the FAQ, it'll help you figure out which other program is causing the issue.

Yeah that's kinda how I'd imagined it would work, with the exception of the 'current directory' stuff. I tend to just look in the exe dir for such things. If I get a minute to play around with this 'would be nice' stuff, I will see what I can do. It's not high up on my priority list right now though, so no promises that it'll be in there for the next release!

2) Personally I never suffer from buffer drop offs. If I did, I would probably be more inclined to increase it! 3) As the 'Copies' info is only short - i.e. '1 of 1', I've stuck the Write speed in brackets next to it. This is then directly to the left of 'Write Rate' and so ties in quite nicely. 4) I have had a few instances where ini file settings would indeed be handy. It's just a case of deciding which settings to use if both are present. Whichever way I do it, I'll always want it round the other way at some point! Also, if not all ini settings are present, would i then use registry ones, and vice versa.

It doesn't and I've never said such a thing myself. Like you say, it's down to the drive.

Only because that's what I started off in and that's what it's built around. Each has their own way of doing things and so basically I don't know visual c++ at all.

The drive thinks it's empty - so it's the problem, not the program as such. I guess it doesn't like that media...maybe a firmware upate would fix it?

1) Because it's the only way to get a true representation of how the burnt disc will perform when it's read back. Some drives burn the media ok but then won't reinitialise it once it's been ejected / reinserted. 2) It's calculated from the amount of info sent to the drive over a period of time (and averaged slightly so it's not up and down all over the place).

c++ builder

1) To do this, the 'Copies' in the queue would have to be implemented like the Write Speed and Device selection stuff - i.e. you'd have to enable and override the default setting (taken from main window) via a checkbox. I'm not sure people would prefer that to the current method. 2) Yes it defaults to 20MB and is not based on ram size. No matter what I do, someone will always fault it If I make it tie in with available ram, someone with 2GB will soon check taskmanager and complain that it's now taking up 256MB when it only use 20 before. If I default it to 40MB, the person with 64mb will moan it's having to swap to hdd. 20MB is small and yet large enough. If you're killing the buffer (and do so all the time) buy another hdd and use that for your images. I would rather leave the user in total control of buffer sizes and start with a conservative size as I am doing at the moment. 3. Have now done current/total copies. Do you REALLY need a static bit of text showing the speed you selected?! What do you gain from it? Surely you just need to see the speed it's actually burning at ('Write Rate'). You can always look in the log for the speed you actually selected. 4. It's called RegEdit 5. Ok, done.

I can't see anyone's name on the birthday list so I'm guessing you lot are actually a day early due to timezones etc So when it's Saturday here in the UK.... Happy Birthday LFC!

Anything that uses more than 1 thread will make use of HT - and ImgBurn is multithreaded. The actual use of HT is controlled by the OS though and it does the job of assigning cpu time slices to these threads - it also controls which CPU (be it real or logical, as in the case of HT) the thread runs on.

Sounds like a media/firmware problem to me. The drive isn't letting the program reserve the track. Check for firmware updates and/or switch to different/better media.

If the MDS supplies the layerbreak position, the IFO files are not examined. Therefore, whatever builds the ISO/MDS must do it correctly in the first place. It's hard to help at the moment because you don't have a real log.... so basically, for now, stick the topic 'on hold' and then reply back when you have a log to show us. Without the real numbers, it's hard to know where the problem lies exactly.

This is the one you want: http://www.microsoft.com/whdc/devtools/deb...ng/default.mspx

Check and see if you're getting minidump files in c:\windows\minidumps. If you are, you can analyse them with Microsoft's debug utility. You can also try messing with the Dr Watson program (drwtsn32.exe) to get some additional debug info.