George Austin

The default Windows did the trick and I've been burning like a champ for weeks! Thanks for the help!

My quest to eliminate variables has begun! So, burning with mkisofs.exe through DVDStyler exhibits the same behavior as burning with ImgBurn 2.4.1.0 Burning Disc size: 4482 MB ISO Size: 1990 MB Executing 'C:\Program Files (x86)\DVDStyler\dvdauthor\mkisofs.exe -V DVD -dvd-video C:\Documents and Settings\George Austin\My Documents\dvd\dvd | builtin_dd of=\\.\E: obs=32k seek=0' 0.49% done, estimate finish Wed Apr 16 21:24:19 2008 5.40% done, estimate finish Wed Apr 16 21:44:43 2008 10.30% done, estimate finish Wed Apr 16 21:40:50 2008 15.21% done, estimate finish Wed Apr 16 21:35:31 2008 20.11% done, estimate finish Wed Apr 16 21:32:42 2008 25.02% done, estimate finish Wed Apr 16 21:31:00 2008 30.41% done, estimate finish Wed Apr 16 21:29:42 2008 35.32% done, estimate finish Wed Apr 16 21:28:55 2008 40.22% done, estimate finish Wed Apr 16 21:28:19 2008 45.13% done, estimate finish Wed Apr 16 21:27:51 2008 50.03% done, estimate finish Wed Apr 16 21:27:30 2008 55.43% done, estimate finish Wed Apr 16 21:27:10 2008 60.34% done, estimate finish Wed Apr 16 21:26:56 2008 65.24% done, estimate finish Wed Apr 16 21:26:43 2008 70.15% done, estimate finish Wed Apr 16 21:26:31 2008 75.05% done, estimate finish Wed Apr 16 21:26:21 2008 80.45% done, estimate finish Wed Apr 16 21:26:12 2008 85.35% done, estimate finish Wed Apr 16 21:26:04 2008 90.26% done, estimate finish Wed Apr 16 21:25:58 2008 95.16% done, estimate finish Wed Apr 16 21:25:52 2008 Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 4248 Path table size(bytes): 42 Max brk space used 0 1019297 extents written (1990 Mb) builtin_dd: 1019312*2KB out @ average 2.8x1385KBps \\.\E:: "Current Write Speed" is 4.1x1385KBps. \\.\E:: flushing cache \\.\E:: closing track \\.\E:: closing disc You can see that the ETA jumps 20 minutes after once it realizes how slow its burning. The ETA slowly approaches the original time once I start messing with windows and the burn goes faster. So it seems my computer forgets to talk with my optical drive when left to its own devices . I wish I thought to load up Sysinternals Process Explorer sooner, since I don't think taskmgr reports hardware interrupts, So, the first thing I'm going to change is SATA controller drivers. Bye bye nVidia, hello whatever the Found New Hardware Wizard gives me. Any other suggestions would be great! -George *EDIT* So this and this from CD Freaks make me think that I should disable SATA-RAID in the bios first before messing with drivers. *EDIT 2* Bios tweaking was a bust (RAID was already disabled, there was no AHCI option), but further reading on CD Freaks seems to indicate the nVidia's IDE drivers are the likely culprit, so I've uninstalled them in favor of Microsoft's drivers. Wish me luck with future burning!

DFI LANPARTY UT nF4 SLI-DR. This: from here makes me think that I won't find any such bios option, but I'll look anyways. nVidia's NF4 serial ATA controller drivers haven't been a problem with previous versions of ImgBurn, but I'll try removing my controllers in device manager and have Windows install generic drivers after a reboot. My search-fu is weak - I only turned up the relatively recent http://forum.imgburn.com/index.php?showtopic=6188 when I was looking before I posted last night, but I'll try again and see if I can't find that guy's thread. I don't remember, but I think that "shaking" ImgBurn's window (instead of Task Manager's) also caused my burn speed to jump up. I thought of two other things to add to my list of things to try: Using DVDStyler's included burning program to see if the problem is limited to IMGBurn Uninstalling and re-installing AMD's dual-core optimizer. Or, since everything behaves when I'm freshly booted, I could just employ the less labor-intensive "reboot before burning" work-around instead of the "shake a window for 5 minutes or more" work-around . Thanks for the help so far! -George

Yes, but it's not pushing ImgBurn when it is the active window, either.

It's not DMA. My drive is working in SATA mode, not PIO, and reads are fast in other applications. I haven't tried writing using anything but ImgBurn yet. This is the log of the burn where I discovered that ImgBurn.exe would not use CPU cycles and send instructions to my burner at anything other than a leisurely pace unless explorer.exe (or taskmgr.exe) were loading the processor as well. ; //****************************************\\; ImgBurn Version 2.4.1.0 - Log ; Wednesday, 16 April 2008, 01:07:05 ; \\****************************************// ; ; I 00:47:57 ImgBurn Version 2.4.1.0 started! I 00:47:57 Microsoft Windows XP Professional x64 Edition (5.2, Build 3790 : Service Pack 2) I 00:47:57 Total Physical Memory: 2,095,428 KB - Available: 1,326,560 KB I 00:47:57 Initialising SPTI... I 00:47:57 Searching for SCSI / ATAPI devices... I 00:48:04 Found 1 DVD

That's not applicable to SATA drives, is it not? Edit: Confirmed. Although it is possible to run SATA devices in PIO mode. Not that that's my problem, just an FYI.

I'm using Windows XP Pro x64 edition with ImgBurn 2.4.1.0. My drive is a Lite-On LH-20A1s with firmware 9L08. This error has occurred with three different DVD+R 1x-4x blanks by Verbatim (all MCC-002-00), as well as one Fujifilm 1x-16x DVD+R (PRODISC-R05-01). So I tried to burn a DVD from an image file named DVD.iso using ImgBurn last night. My average burn speed was something ridiculous - around 0.3x. After a few minutes, I aborted the burn and tried a new disc - same problem. I aborted, and tried a Fujifilm disc and got the same result. I thought to myself, "My friend Jon is paranoid about Nero's stuff - maybe he's right, even though I've never had a problem. Nero 6 OEM is messing with something!" I proceeded to remove the only Ahead software I had on my system: Nero Vision Express and Nero Showtime. They don't have anything to do with burning, but it can't hurt, right? I rebooted my computer, returned ImgBurn to all of its default settings, popped in another MCC-002-00 blank, and it worked like a champ. So today, I wanted to make another copy of this DVD, and when I fired up ImgBurn with a MCC-002-00 in the tray, it started burning at 0.2x-0.4x again. Rather than get mad and have another coaster, I killed Folding at Home SMP and NOD32's real-time protection. ImgBurn jumped to 1.8x while NOD32's window was loading, but then dropped again. I opened up Task Manager, and saw that ImgBurn was using 0 CPU time. However, while Task Manager was loading, I noticed that my burn rate had jumped again. I was curious, so I started dragging the Task Manager window around, shaking it back and forth and making explorer.exe (and taskmgr.exe) load the processor a bit. ImgBurn.exe also started using CPU cycles, and my burn speed eventually climbed to 4x - the maximum speed for my discs. "Hooray," I thought, "I'm cured!" I stopped dragging Task Manager around only to watch my burn speed plummet again. I repeated the "shake a window and then stop" process half a dozen times to convince myself that this wasn't coincidence. The read speed during verification was similarly slow, and shaking a window fixed this problem as well. What's happening here!? I've used earlier versions of ImgBurn with no issue. Both my chipset drivers (nForce4) and burner firmware have stayed constant since the time that I used both ImgBurn 2.4.0.0 and whatever older version comes with DVDFlick 1.2.2.1. Other than Windows updates, it seems like the only relevant thing that's changed is ImgBurn's version. I still have ImgBurn 2.4.0.0 on my computer (in DVDFlick 1.3 Beta's sub-directory), but I'd like to see if anyone knows what's up before I do any more experiments. Just in case, I'll include some more information about my system: AMD X2 3800+ dual core @ 2700MHz 2x1024MB Patriot PC3500LLK @ DDR491 DFI LANPARTY UT nF4 SLI-DR So in addition to using 2.4.0, here are some other things I can try: *Edit: added bullet points to this list* Running my processor and ram at stock speeds Playing with ImgBurn.exe's priority Using something besides SPTI Any other ideas? Thanks so much for your help (and for making a wonderful application!) -George