LIGHTNING UK!

Ok, where it lists the full file name (you've got 2 in that screenshot), it means the break won't be in the middle of anything you watch - so they're your best bets. The closer you can get to the 'Image File Midpoint' value, the better. All in all, the top option is the best one for you. Select it and click ok.

Either would have been fine, just not both

It'll only be a matter of days before I put another build out. Just a minor bugfix one... probably 1.2.1.0

Look at the values in the 'LBA' column. Are they all different? I'd personally suggest you do a bit of reading before burning DL discs. They're not as straight forward as single layer ones. You need to consider far more things, and it helps to know what you're doing! If you're getting choices, that's a good thing. It means you can put the layerbreak at a point where you won't notice it too much. i.e. if it points at Cell 12 in a certain PGC and that's in the middle of high action, fast moving scene, it's probably better to try a different one. It's not a decision ImgBurn can make for you, this is a personal choice thing. If all the options are at the same LBA, you can select any of them, they're all the same! If in doubt, get a screenshot of the window and post it up here so we can see / help.

tsk tsk tsk Didn't anyone ever tell you it's very rude to cross post. http://forum.imgburn.com/index.php?s=&show...indpost&p=10737

Noooo, that's the Device (dvd drive) transfer length, you cannot configure the value used for reading from the hdd. The two are very different. As mentioned earlier, Windows proxies all hdd reads, it doesn't proxy drive reads. If I read 256kb at a time from a hdd, it'll just issue multiple physical reads from the hdd if it can't do 256kb at a time - and then return me the full 256kb. If I read 256kb at a time from a dvd drive, I get an error. Most direct/physical I/O is limited to 64kb at a time - MAXIMUM. Many old/shite drivers are limited to 32k. As I never saw using 256kb as a problem (because the OS is supposed to deal with it), I never gave the users a slider so they could select the size they wanted it to use. Before you started this thread, I had actually already implemented a slider so people COULD change that value. This was added after reading / dealing with that other post in this forum about slow burning. Basically, I think you both have the same issue, only because that other chaps system can't cope with having no free memory, his swap file is being used and it's killing the transfer rate - the image is on the same physical drive as the swap file. So now this issue has been brought to my attention (again, but in a different style!), I've removed the slider again and gone back to the old trusty 64kb (fixed) for hdd reads.

Yeah, if it's on the same physical drive, it'll still cause a problem. It's the random accessing and multiple I/O request to a single drive that kills it.

You need to find out the chipset used on your motherboard. If you don't know the answer to that immdeiately, look in Device Manager under the system branch. You should see several entries with a similar manufacturer - be it Intel, Via, Ali etc. Once you know that, visit the appropriate website and download the latest motherboard/chipset/ide drivers and install them. btw, have you manually disabled autorun/play at system level or anything? These warnings are added in newer versions of the program, that's why you've not seen them before.

doesn't the BSOD message give you any clues? Open the dump file in WinDbg and see what it reports as the cause of the problem. Unless it's hardware related, it'll probably give you the driver name. But I guess as you say you've changed all the hardware and reinstalled (from a decent CD I hope!) that OS, it's unlikely to be a problem like that. So what IS the common denominator here? PSU sounds like it's the only thing it could be right now

btw, do you have autorun / play enable on your machine? I'm wondering if that could be something to do with it? Maybe the command fails if it's already disabled at some lower level... who knows!

Think we've found the cause of this now. When burning, the OS eats all your memory in file cache. Eventually you run out and windows then starts using your swap file. As I assume that's on your C: drive - along with your image file - the machine just dies because it can't do two things at once. This was indeed caused by the change in transfer length from 64k per read to 256kb per read. It appears to now bypass some code within windows that stops it from caching the reads and so although I assumed it was a good thing to issue less read commands, it's actually made things worse. I have a bit of a beasty machine and so didn't notice the problem, mine is mainly scsi and I never burn off my C: drive. I also have 2gb of memory. If you're bored, feel free to burn another disc in 1.2.0.0 and watch your available free memory vanish to 0 via task manager.

Like I said, I have the same issue on my pc with 1.2.0.0. When I burn, the available memory vanishes into cache. As such, I can do some testing my end - which makes things sooooooooo much easier!!! lol I think this is something windows has done recently as I remember way back when (during DVD Dec days) that someone reported this as a bug (or maybe a suggestion), that I tell windows not to cache the reads. It's clear to me as a programmer that this is what's happening, although to a user, I can understand that's not what you'd think to be the cause. Maybe with DVDs becoming more popular, Microsoft changed the way it dealt with caching big files and reads, and kinda bodged it so 64k reads didn't cache on certain (?) large files. When I said I'd only changed the sequential file flag earlier, I forgot about another change I'd made - on the transfer length. As reads are proxied by Windows anyway, I just saw making the number of physical reads my programs makes smaller as being a good thing. Read larger amounts at a time = less reads = less for the OS to do. It was actually added in an attempt to speed up reading from a network drive - again because I assumed it would have less work to do. Anyway, that seems to have backfired and now windows is not ignoring the fact that I'm reading big files. I've just done a test with the transfer length set to 256kb (as is default in 1.2.0.0) and then again at 64kb (default for 1.0.0.0, 1.1.0.0 etc). NOTHING else was changed. At 64kb, I saw no change in available memory. At 256kb, Windows gobbles it all up. So the sequential flag is not the problem, it's the transfer length and the (guessed) fact that I'm now bypassing Window's caching controls on large files. Oh well, we live and learn! I bet I could search google all day long and not find that little gem documented

Oh, the only difference I made to the file reading was that I added that 'sequential' flag to the 'CreateFile' API call. It's supposed to tell windows to optimise caching for reading a file from start to finish - which is of course what I'm doing. You seem like a clued up guy, so if you want, go check it out on msdn. Just search for 'CreateFile' and looks at the programmers help on it. EDIT: look here: http://msdn.microsoft.com/library/default..../createfile.asp

This has been something I've been aware of since DVD Dec days, it's nothing new, I promise you. It really is just windows caching the data that's read from the image file, does it on my pc too. The second the file handle is closed, windows frees it up again. Hell, kill that handle in process explorer if you like - ImgBurn won't do any cleanup, it'll just give you an error message - and yet your 'available' physical memory will shoot back up. As you mentioned earlier, it's not ImgBurn itself that's using the memory, if it were, it would be added onto ImgBurn.exe memory allocation - which is clearly visible in task manager. Not only that, as the beta team will vouch, the program has been run through codeguard many many times without any leaks being reported.

I'll email you a version where you can change the transfer length used when reading files from the hdd. The new default is 256k, change it back to the old default of 64k and see if it makes a difference. As I said earlier, this is the only bit I changed that's being run during a burn, the rest run leading upto it or run after it. I don't feel those bits could be causing your problem.

This is just your OS caching the reads/writes. Nothing I can do about it (except to specifically telling the OS not to, but that causes me additional problems) It's only temporary and windows will recycle it when it needs to.

The program traps errors perfectly, ImgBurn is one of the only tools that gives you a full description for every possible error a drive could return. The problem here is that the drive is not returning ANY error at all - or more to the point, it's not returning anything full stop. You've got an un-named drive, with media that's not recommended either. I'd tell you to look for an updated firmware but I've no idea what your drive is. All the decent ones show their name in the device string, as you can see, yours hides it and just says 'ATAPI DVD RW 8XMax' - hmm that's helpful! Press the F8 key and you'll see info being sent to the drive scrolling up in the log window. If you don't see anything scrolling, your drive (or drivers) have accepted a command and just sat on it - not returning an error and not saying it was successful. What do you want me to do, guess how it turned out?

You have to physically go in and change those options via the new 'Advanced Settings' window. They're not touched otherwise. Do a test mode burn (on a DVD-R disc of course) and look at the buffer when that's on. See if it's any different to normal (by normal, I mean where it's jumping). Disabling PowerRec should also stop wopc doing its thing. The device buffer displays the value returned by the drive for how much data it thinks is in the drives internal cache. When WOPC is doing it's thing, it tends to empty the buffer each time it tests the disc. Your issue wouldn't be so bad/difficult to understand if the graph didn't clearly show it recovering from whatever the problem is. If it was a real issue/bug, you'd get 1.5x all the time - as it's just the same command repeating over and over again. To go from 4x to 8x, then slllloooooooww, then 4x again is quite mad!

Tis very odd then! Do keep me posted if you manage to make it happen again

Incase you're not already, it may also be worth going back to the default settings. 'something' appears to be interferring with the burn. As I said, with a full up normal buffer, there is no reason for any slowdown other than by external forces over which I have no control.

I guess none of the others issue it, or they fail silently. Just turn it off in the settings, no big deal. It's the 'Disable Media Change Notification' option.

I believe PIE's should be no higher than 280... (and that's very bad anyway). So you're well out of spec. Yes, ditch that disc and reburn it.

Your drive doesn't like burning to, and then reading back from those discs. It's a sure sign of a very low quality burn. Ditch them and buy some other discs. I very recently had to RMA one of my drives because that's all it ever kept saying. It had totally lost the will to burn, poor thing

Ok, the only way to make that cancel window appear is to click the 'stop' button when the program is doing something, or to close the main form (or have some other program try and close it) - i.e. via the top right cross (X thingy). So basically I'm guessing you'd finished a burn, clicked 'ok' to the 'completed successfully' box, and then immediately clicked the X. In doing that, you'd have actually closed (well, tried to) the program before all of the thread cleanup code had finished running. The program kinda remembers that you've clicked the X if it's busy doing something... it then normally checks if you have, once the lengthy operation has finished, and acts upon it if it has. I've jumbled a couple of lines around in the code to make this less likely to happen in the future. Still, you'd have to be super quick with the mouse to make it happen as it stands, I guess that's why you've not been able to reproduce it!

Hello everyone, nice to meet you