LIGHTNING UK!

only capturing 16 commands in a go, I did say it would be hard to get it to see a 'read buffer capacity' command being sent! The device buffer level is only checked every so often so don't expect to see 1 per every 'write' command or anything like that. As I said before, once the device buffer thread is running, it runs until the burn finishes. There's no way it could just capture data during the 2nd layer.... so as you know layer 2 works ok (buffer wise), the command MUST be being sent during the 1st layer too. As as side note, it seems to cutting off some of the extra data I need when you save it. You may need to increase the 'max record' length to something higher - incase it defaults to 8 ? 16 should be enough (can't remember if the demo lets you do that or not). Try dragging out (resizing) the 'data' column too because it's doing some weird things with word wrapping that makes it hard to read!

No idea then I'm afraid. The drive is not supposed to become 'un-ready' during a burn like that. It's not a generic Plextor thing as mine certainly doesn't do it.

That's weird, BusHound specifically states it WILL run on Windows x64 - unless with all these weird naming schemes that's not the same as XP64. Your IBG does indeed show the buffer always on 0.00 until the layerbreak sectors. I've reported (again) the problem with cpu % usage not being displayed in the graph when the buffer is at 0 and vice versa to the dvdinfopro people. Hopefully they'll sort it. Without bushound working, we're stuck. Don't have a spare partition you could stick normal XP on do you?!

Shit, I just noticed something! Not only does your graph show there's no device buffer line, but there's also no CPU activity for the first layer. There's actually a bug (or that's what I'm calling it) in DVDInfoPro where it doesn't seem to plot the buffer level if there's no CPU data. Any chance you could post up the IBG file that goes with the graph data screenshot you posted earlier? If you didn't export it manually (i.e. you did 'display graph data...'), it may still be in your temp folder - called ImgBurn.ibg

Nothing we can do really I'm afraid. If the drive won't initialise the media then you're stuck. Although you say you're using the same media as always, did you just switch to a new spindle? Even same brand/style/look discs can have different dye types and it's the dye that's important, not whose name is stamped on them. So the normal problem solving methods apply here: 1. Update your drives firmware 2. Try different discs (with different 'better' dye) - i.e. MCC (verbatim) or Taiyo Yuden. 3. Clean drive's laser 4. Get new drive

The only (free) one I really know of is this one... http://home.koping.net/u3980a/cdfreaks/TraceSpti/index.htm No idea if it will install / run on xp64 though. Failing that, this one does work on xp64 http://www.bushound.com/bushound/index.htm The demo might be all you need if you manage to hit 'start' at the right time! (it only captures so much data before stopping). So long as you manage to capture a 'read buffer' command being sent, that's all I'll need

You wouldn't experience it, you're the user, not the programmer. Take it from me, DVD+RW has to be sent the 'format' command before a 'Write' command will be accepted. You only have to look at the little info panel on the right and read the 'Formatted:' status bit. ImgBurn does not accept 'Yes (Started)' as a valid response and will attempt a full format again - after which it will just read 'Yes'. Once it just says 'Yes', ImgBurn WILL NOT ask you to format it again. You will then just see the 'Overwrite' prompt you're used to seeing in DVD Dec. DVD Dec did not care about the 'Formatted:' line, so long as it didn't say 'No' (in which case the 'Write' command would fail). Both DVD Dec and ImgBurn will format the media if it does say 'No'. That only happens on brand spanking new media that you've just unwrapped from the case.

I'd love to know why it thinks the device buffer is on 0 all the time but I've no way of figuring it out Normally I'd just get a user to turn debug logging on, but none of the commands like that (sent frequently) during the burn get logged (for performance reasons). The only way to do it would be to get an spti trace program. That might be a bit overkill for you

No matter what, the burn quality really shouldn't differ that much unless it's hardware / firmware / media related. They're the only things that should have a significant baring on the write quality, nothing else. To be honest, the 2nd + 3rd scans look more normal (for Ritek DL media) to me than the 1st! lol Are you sure you didn't swap to a new spindle or discs, or update the firmware between the good / bad ones? Before you mess around too much more you should at least try 1 verbatim disc - just to rule out the whole 'crap media' thing. They're about ?14 for 10 at www.svp.co.uk If you still get bad scans, something else must be a miss and I haven't a clue what.

You have to format DVD+RW, there's no 2 ways about it. Formatting may reduce the size of the disc when you're talking about hdds or anything else that allows the OS to access it directly, but not about DVD+RW. DVD Dec was no different from ImgBurn in that it would still format a disc if it really needed to, but it would allow you to do direct overwrite on a disc where it's format status was in limbo. That's what ImgBurn wont do (yes, there is an option in v2 to get around that). I already fully understood what the original poster was talking about and it's nothing to do with what you've just said. Their drive had/has problems with the media, nothing more.

Can't really tell anything from the graph, you have to look at the raw data. I suspect your machine just has inaccurate timings and so where it's supposed to wait 100ms, some of them are a fair amount above that. That will have the effect of some samples showing a low transfer rate and and others a very high one. DVDInfoPro also averages the raw data out. Flick to the 'Sampled' mode (by clicking on the 'Averaged' button) and you can move the slider to see all the differences. There should certainly be no difference between the graphs depending on if it's the first / second / third burn etc.

Are your burns much different to this one I've just done? http://forum.imgburn.com/index.php?s=&...ost&p=20280

lol well that's that idea out of the window! Your system is about as clean as it could possibly be. If you're worried about the nvidia drivers messing things up (there doesn't seem like it could be anything else!), uninstall them + reinstall again. When it prompts to install the ide driver just click No. At least then you'll know for sure.

Can you please post up your filter driver info. To do that you'll need to download a little util from http://www.bustrace.com/downloads/free_utilities.htm It's the 'Filter Driver Load Order' one. You run it, select your burner in the list, then click the 'Clipboard' button to copy the details to the clipboard. You can then just paste the info into your reply. There is no possible way for the program to somehow not be collecting the buffer info duing the burning of the first layer some something else must be blocking it or reporting false info. You already said the buffer issue is the same on LiteOn + NEC so I guess that does indeed rule out a firmware glitch.

_NEC DVD_RW ND-4550A 1.08 (ATA) Media Information: _NEC DVD_RW ND-4550A 1.08 (ATA) Current Profile: DVD+R DL Disc Information: Status: Empty Erasable: No Free Sectors: 4,173,824 Free Space: 8,547,991,552 bytes Free Time: 927:32:74 (MM:SS:FF) Supported Write Speeds: 2.4x DVD?R DL Boundary Information: L0 Data Zone Capacity: 2,086,912 Changeable: Yes Physical Format Information (ADIP): Disc ID: RITEK-D01-01 Book Type: DVD+R DL Part Version: 1 Disc Size: 120mm Maximum Read Rate: Not Specified Number of Layers: 2 Track Path: Opposite Track Path (OTP) Linear Density: 0.293 um/bit Track Density: 0.74 um/track First Physical Sector of Data Area: 196,608 Last Physical Sector of Data Area: 16,580,607 Last Physical Sector in Layer 0: 2,283,519 Results: I 13:39:39 ImgBurn Version 1.3.0.24 Beta started! I 13:39:39 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2) I 13:39:39 Initialising SPTI... I 13:39:40 Searching for SCSI / ATAPI devices... I 13:39:40 Found 3 DVD-ROMs, 1 DVD?RW and 3 DVD?RW/RAMs! I 13:39:53 Operation Started! I 13:39:53 Source File: -==/\/[DISCOVERY IMAGE]\/\==- I 13:39:53 Source File Sectors: 4,173,824 (MODE1/2048) I 13:39:53 Source File Size: 8,547,991,552 bytes I 13:39:53 Source File Volume Identifier: DISCOVERY_IMAGE I 13:39:53 Source File File System(s): None I 13:39:53 Destination Device: [0:1:0] _NEC DVD_RW ND-4550A 1.08 (H:) (ATA) I 13:39:53 Destination Media Type: DVD+R DL (Disc ID: RITEK-D01-01) (Speeds: 2.4x) I 13:39:53 Destination Media Sectors: 4,173,824 I 13:39:53 Write Mode: DVD I 13:39:53 Write Type: DAO I 13:39:53 Write Speed: MAX I 13:39:53 Link Size: Auto I 13:39:53 Test Mode: No I 13:39:53 BURN-Proof: Enabled I 13:39:53 Optimal L0 Data Zone Capacity: 2,086,912 I 13:39:53 Optimal L0 Data Zone Method: ECC Block Boundary I 13:40:19 Filling Buffer... I 13:40:19 Writing LeadIn... I 13:40:21 Writing Image... I 13:40:21 Writing Layer 0... (LBA: 0 - 2086911) I 14:01:12 Writing Layer 1... (LBA: 2086912 - 4173823) I 14:22:34 Synchronising Cache... I 14:22:35 Closing Track... I 14:22:57 Finalising Disc... I 14:23:50 Exporting Graph Data... I 14:23:50 Graph Data File: C:\IBG\_NEC_DVD_RW_ND-4550A_1.08_22-JULY-2006_13-39_RITEK-D01-01_MAX.ibg I 14:23:50 Export Successfully Completed! I 14:23:50 Operation Successfully Completed! - Duration: 00:43:57 I 14:23:50 Average Write Rate: 3,296 KB/s (2.4x) - Maximum Write Rate: 3,621 KB/s (2.6x) I 14:23:50 Cycling Tray before Verify... I 14:24:16 Device Ready! I 14:24:16 Operation Started! I 14:24:16 Source Device: [0:1:0] _NEC DVD_RW ND-4550A 1.08 (H:) (ATA) I 14:24:16 Source Media Type: DVD+R DL (Book Type: DVD-ROM) (Disc ID: RITEK-D01-01) (Speeds: 2.4x) I 14:24:16 Image File: -==/\/[DISCOVERY IMAGE]\/\==- I 14:24:16 Image File Sectors: 4,173,824 (MODE1/2048) I 14:24:16 Image File Size: 8,547,991,552 bytes I 14:24:16 Image File Volume Identifier: DISCOVERY_IMAGE I 14:24:16 Image File File System(s): None I 14:24:17 Verifying Sectors... I 14:44:06 Exporting Graph Data... I 14:44:06 Graph Data File: C:\IBG\_NEC_DVD_RW_ND-4550A_1.08_22-JULY-2006_13-39_RITEK-D01-01_MAX.ibg I 14:44:06 Export Successfully Completed! I 14:44:06 Operation Successfully Completed! - Duration: 00:19:49 I 14:44:06 Average Verify Rate: 7,020 KB/s (5.1x) - Maximum Verify Rate: 10,187 KB/s (7.4x)

Media: Datasafe 2.4x DVD+R DL [RITEK-D01-01] Burnt With: _NEC DVD_RW ND-4550A 1.08 (ATA) Scanned With: BENQ DVD DD DW1640 BSRB (ATA)

Hmm a very odd problem you have there. There isn't anything done with the device buffer stuff from the moment it start burning, until it finishes. It just queries the drive over and over again for the buffer status/details. At this stage, I'd have to actually call it a bug in the firmware that it's not returning the info. If the buffer really was on 0, there's no way you'd get such a smooth write speed graph. So ignoring the buffer stuff, the next problem is the burn quality of those discs. As I said before, I never expect good things from anything but Verbatim DL media. You can see from this thread that our results weren't all that good either with the Riteks. http://forum.imgburn.com/index.php?showtopic=693 I may dig out my 3550 (If I have one!) and see how it burns with the latest firmware.

While you're at it, post the full log too please!

The Device buffer should only really start filling once the 'Writing Image' entry has been added to the log. Are you saying it's on 0% for the entire first layer? I have the latest nforce 4 drivers installed on a pc (including the IDE driver) and haven't seen any problems. There is certainly no reason for them to JUST cause a problem burning DL. The problem would either be there all the time or not at all. If / when you burn another disc, export the graph data (via the File menu) and load it up in DVDInfoPro (or just use the 'Display Graph Data' option. Save a screenshot and post it up. It'll tell use what the buffers etc were doing during the burn. Oh and you are using Verbatim DL media yeah? I'd almost expect high PIE/PIF scores on the others!

ImgBurn doesn't make MDS files (or at least not in version 1.3.0.0) - unless you secifically use the 'Create DVD MDS File' option in the Tools menu. That option would create the same MDS file that very same function in DVD Decrypter would do. If you already have an MDS, there is no need to use ImgBurn to create another one. The MDS files created via that 'Create DVD MDS File' method DO NOT contain layerbreak information and so are worse than any that are created automatically by any other means.

That message is from something deeper in the I/O subsystem. It's not a drive error message (so to speak), it's coming from the DeviceIoControl API call. Once submitted, all of this I/O stuff is out of my control.

I wouldn't go that far, I just see no point in rushing things. After all, we can already use all the new features so it makes no different to me if I release it or not

The drive can drop the speed if it finds the one you were burning at is not satisfactory. It's not my job to control the speed, it's totally down to the drive. If the buffers are full, it's being supplied with enough data to burn at whatever speed is currently selected.

The drive must have been 'ready' at some point or it wouldn't have moved onto the next image. For some reason, your drive is becoming 'not ready' - and that's not a good thing, it should not happen. Once you exhaust the 20 retries (as above), wait 30 seconds and then hit retry manually. Does it continue? If not, what error do you get then? We've done hundreds of queue burns and I've yet to see this problem.

I'd already seen this over at cdfreaks actually - I didn't really have anything to say on the matter when it was over there! Something about drive just doesn't like the media. The media might be fine, it could be that the drive is faulty.... or it could be the other way around. It really is anyones guess! Either way, there is nothing I can do about I'm afraid, the ball it most certainly in your own court. Perhaps one of the newer 'test' firmware will do a better job? You can find those back at cdfreaks.