????

Hehe, somehow I must have missed that you can see the same behaviour on your machine. This raises my hope that you may find a way to optimize ImgBurn on this one. And as it seems you have already found the reason for this issue. Do I understand correctly, that changing the transfer length to 64kb should "stabilize" the available memory? I just did that in the I/O settings, did another burn and had to say bye bye to my RAM again. I bet it had a good time on va-cache-ion. However, thanks a lot for looking into it, your efforts are highly appreciated. Best Regards

Thanks for your reply. Unfortunately I am not into programming, but I will have a deeper look into the topic, maybe I can understand something on a theoretical basis. But I just don't understand why this occured for the first time on my machine with this version. You wrote something about an added flag with this release, is there a way to disable this (it's not a bug, it's a) feature on my end to test if this is the culprit? Thanks for your efforts. Best Regards

@ cornholio7 Thanks for testing, and honestly, I do not have a clue what is happening here. Again, ImgBurn does not grab the memory itself, as it takes maximum 30 MB in the taskmanager, the RAM vanishes for no real reason and that happens only when v1.2 is handling the content of an imagefile. And this applies to all of my imagefiles which are processed from HDs connected to an Intel- (ICH5 Raid0 S-ATA) and Promisecontroller (20378 simple S-ATA and P-ATA).

Thanks for your reply, but "loosing" 500-600 MB of free RAM is not a typical behaviour of ImgBurn as I know it and it occurs with every write attempt of the latest 1.2.0.0. And it's only about 500-600 MB because of a RAM-Management software is kicking in. I would bet, if I had 2 GB of RAM (right now I have 1 GB) installed on my machine, all of it would vanish as well. I am not sure, if I was precise enough, but the memory vanishes stepwise pretty quickly - and it would definitely drop down to zero free RAM - when ImgBurn has finished the lead-in and starts to write the image file. With the beginning of the lead-out the vanished memory will be free'd up and vanishes again when the verification process beginns. The memory remains "missing in action" until verification has finished. Not to mention that the whole PC slows down while this happens and would probably lead to a coaster if there wasn't this "doorblocker" named "Cacheman" on my machine. ImgBurn 1.0.0.0 + 1.1.0.0 is not affected and leaves about 500 MB of free RAM, so does your previous tool or any other writing-software. The drive with which this was observed is a Plextor 716A 1.09 in combination with Verbatim 16x and Ricoh 8x quality media. PoweRec was disabled via ImgBurns advanced settings. Best Regards

Ladies and Gentlemen, I have just updated ImgBurn to 1.2.0.0 and for some reason my RAM seems to dissapear while writing and verifying with this most recent build, although ImgBurn stays rock-solid at 10-30 MB in the taskmanager like the swap file as well (no fluctuation here neither). My observations make it look like that the RAM gets eaten up by no visible process in the taskmanager, but starts to drop in steps of about 20 MB from 600-700 MB free RAM when ImgBurn starts to load the image file (for writing and verifying) until "Cacheman" kicks in and frees up some RAM, which will get eaten up again and again and so on. This occurs with using both SPTI and ELBY I/O. It doesn't matter if Slysofts red fox is active or not, nor does it matter from which HD I am writing. Since this behaviour was introduced with the latest build and as other Software (DVDD as an example) is not affected, my wild guess would be that there is something wrong with this version. What do you think of it LUK!? I wonder, if anyone could confirm this behaviour or has an idea of how to fix this? Best Regards

:worthy: Thanks a lot, LUK! #39;(

LOL! Now that's nice! I can't wait to get my hands on the new version! Hooray for Lightning_UK!

Dear L_UK!, would you be able to add a possibility to configure (enable/disable) the PoweRec settings for Plextor drives in ImgBurn without that much of work like in Nero and/or PlexTools? As I find that PoweRec is way too sensitive and often makes my discs stutter in my standalone it is just annoying to fiddle around with PlexTools to disable PoweRec before using ImgBurn to get a decent burn. I know, most people seem to be fine with PoweRec, but for me it just gives headaches. As this command seems to be hidden in the firmware it can't be disabled in general and must be set everytime I want to write something to a disc via PlexTools. However, the Nero team found a way to permanently store that setting somewhere in their program and so it does not need to be re-set everytime. I wonder if you could implement such a feature like in Nero. It would be very appreciated. Thanks in advance. Best Regards

Okay, thanks for your confirmation and providing a fix in the upcoming version. I am glad this one is already worked out without that much of a headache. I guess it's time to donate a few bucks as everything is perfectly legal now, although I am afraid it can't be that much as I am a poor student on an almost everyday low budget basis, but your efforts and of course your software must be supported. Cheers ????

Please find a screenshot and the logfile attached. I get a notification about overburning and right after accepting it ImgBurn comes up with the error message. ImgBurn.log

Yes, you are right, in my case ImgBurn doesn't write anything to the disc at all. It just fails right after the attempt to start the lead-in and I can still use the very same disc just with closing ImgBurn and using DD. I don't touch neither writer nor disc and it works perfectly just with a "different" software. Just closing ImgBurn and restarting the application does not help. I am sorry if I was not that clear (which I wasn't, quite obviously ). Well I am not sure if this behaviour occured everytime I tried to write with ImgBurn, but IIRC it has always failed after successfully writing a +R DL (MKM001-000). Could this be the culprit? I hope I'll find the time to burn some discs today and that my observations can be useful in this case. Best Regards EDIT: Forget about the +R DL thing, it's nonsense. As I have read this thread on cdfreaks.com (from the fourth post on) it seems to be related to overburning with my PX-716A, as the last discs I have tried had to be overburned. I think I can save my media from wasting for testing purposes. Or would it help to post a log nonetheless? 2nd EDIT: Aaargh, my bad, I had only searched for the "check condition" error message and haven't noticed that the original poster had a different "check condition" error message than me. I am definitely suffering from the "reserve track" problem. LOL, I am sorry for that. ???? feels like a retarded noob and stands ashamed in the corner...

Thanks for your reply LUK!. I'll try to track down the problem this weekend. The strange thing about it is that I don't even need to force the drive to reload the disc if ImgBurn failed in order to write the disc with DD. I just close down ImgBurn, open DD, load the same image file and got my writer fired up without a problem. Unfortunately I can't provide a log yet, as this option wasn't checked although I thought it was, but I will do as soon as I have finished my observations. Best Regards ????

I am afraid I have the very same problem writing my discs with ImgBurn 1.1 by getting the I/O check condition error message. This must be related to ImgBurn (or something else is interfering) and not to the media or the writer itself because the very same writer (PX-716A) works very well with the very same discs (RICOHJPN R02-03) with the latest version of LUK!s famous & banned tool. But this does only apply to single layer DVDs, double layer discs are working fine for me. It doesn't matter which I/O I am using (ELBY or SPTI), ImgBurn still refuses to write these discs. So, it would be very appreciated if LUK! could find some time to investigate this problem. Thanks in advance. Best Regards ????