DL Device Buffer Problem

[CrashedAgain]

I have been using DVD Decrypter and ImgBurn together now for awhile with DL disks and been getting excellent results, but recently i started to get odd results. When starting the burn the log is all normal and says filling buffers etc buffer under-run enabled etc, all good.

 

When starting the first layer though the main buffer filles to 100% but the device buffer stays empty, at the layer break when burning pauses the device buffer fills to 100% and burns on ok. Unfortunatly when i scan the discs with nero cd speed the first half of the disc is excellent but the 2nd half is really bad very high PI/PIF.

 

At first i thought it may be my burner as i had recently done a firmware upgrade, but i ruled this out as it did it with the previous firmware and my other burner (burner 1: LiteOn 851s@832s, burner 2: Nec ND-3550A) i have tried reinstalling imgburn, reinstalling windows and i still get the same problem.

 

The only thing i can think is i think i may have upgraded my mainboard drives between this happening but i cant remember (there was about a 4 week gap between last good burn and finding it had gone bad.) I have a nforce 4 amd motherboard and was wandering if the newer nvidia ide drivers could cause this? I have all ready wasted about ?6 worth of DL disks trying to fogure this out and dont want to waste any more if this cant possibly be connected. PS DVD+-R single layer work fine still.

 

So my big question could new nforce ide drivers do this?

 

Any help/comments much appreciated.

 

Cheers

[LIGHTNING UK!]

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!

[polopony]

You don't say which DL discs you are using ,Verbatim are the only dl's that work correctly all others suck

[CrashedAgain]

Am burning another disc now, will post graph data when done in about an hour.

 

Sorry, forgot to say they are Tuff Disc branded DVD+R DL disks i think they are ritek 02 or something like that, and i have always have good results( or disc's that worked at any rate) before.

[LIGHTNING UK!]

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

[CrashedAgain]

Finished burn and as before device buffer stayed empty for first layer(layer 0) then filled and worked as expected for next layer.

 

LOG::::

I 11:57:54 ImgBurn Version 1.3.0.0 started!

I 11:57:54 Microsoft Windows XP Professional x64 Edition (5.2, Build 3790 : Service Pack 1)

I 11:57:54 Initialising SPTI...

I 11:57:54 Searching for SCSI / ATAPI devices...

I 11:58:04 Found 2 DVD?RWs!

I 12:00:51 Operation Started!

I 12:00:51 Source File: E:\DVD_VIDEO2.MDS

I 12:00:51 Source File Sectors: 4,147,728 (MODE1/2048)

I 12:00:51 Source File Size: 8,494,546,944 bytes

I 12:00:51 Source File Volume Identifier: DVD_VIDEO

I 12:00:51 Source File Application Identifier: DVD Studio Pro:4.0.2, DSPInterface:371, DVDAuthoring:350, DVDBase:371(Encoder: 483), Oxygene:409

I 12:00:51 Source File Implementation Identifier: Apple Computer, Inc.

I 12:00:51 Source File UDF Revision: 1.02

I 12:00:51 Destination Device: [0:0:0] _NEC DVD_RW ND-3550A 1.06 (F:) (ATA)

I 12:00:51 Destination Media Type: DVD+R DL (Disc ID: RITEK-D01-01) (Speeds: 2.4x)

I 12:00:51 Destination Media Sectors: 4,173,824

I 12:00:51 Write Mode: DVD

I 12:00:51 Write Type: DAO

I 12:00:51 Write Speed: 2.4x

I 12:00:51 Link Size: Auto

I 12:00:51 Test Mode: No

I 12:00:51 BURN-Proof: Enabled

I 12:00:53 Optimal L0 Data Zone Capacity: 2,082,784

I 12:00:53 Optimal L0 Data Zone Method: Copied From Original Disc

I 12:01:19 Filling Buffer...

I 12:01:19 Writing LeadIn...

I 12:01:21 Writing Image...

I 12:01:21 Writing Layer 0... (LBA: 0 - 2082783)

I 12:22:13 Writing Layer 1... (LBA: 2082784 - 4147727)

I 12:43:24 Synchronising Cache...

I 12:43:25 Closing Track...

I 12:43:46 Finalising Disc...

I 12:45:17 Operation Successfully Completed! - Duration: 00:44:25

I 12:45:17 Average Write Rate: 3,289 KB/s (2.4x) - Maximum Write Rate: 3,543 KB/s (2.6x)

 

 

[Movie Junkie]

Am burning another disc now, will post graph data when done in about an hour.

 

Sorry, forgot to say they are Tuff Disc branded DVD+R DL disks i think they are ritek 02 or something like that, and i have always have good results( or disc's that worked at any rate) before.

As it states below, and I'm sure the others here will agree with me;

 

"Using dual-layer discs? Verbatim DVD+R DL discs are the only way to go."

[LIGHTNING UK!]

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.

[CrashedAgain]

Firmware was my first thought but the odd thing is i get the exact same result with both drives the liteon and the Nec.

[LIGHTNING UK!]

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.

[CrashedAgain]

----------------------------------------------------

Filter Driver Load Order http://www.bustrace.com

----------------------------------------------------

 

Upper Device Filter: redbook

Device Object: LITE-ON DVDRW SOHW-832S

Lower Class Filter: AnyDVD

Lower Device Filter: imapi

 

Driver Name: redbook.sys

File Location: c:\windows\system32\drivers

File Description: Redbook Audio Filter Driver

File Version: 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) [5.2.3790.1830]

Product Name: Microsoft? Windows? Operating System

Product Version: 5.2.3790.1830 [5.2.3790.1830]

Company Name: Microsoft Corporation

 

Driver Name: anydvd.sys

File Location: c:\windows\system32\drivers

File Description: AnyDVD Filter Driver

File Version: 6.0.1.1 [6.0.1.1]

Product Name: AnyDVD

Product Version: 6.0.1.1 [6.0.1.1]

Company Name: SlySoft, Inc.

 

Driver Name: imapi.sys

File Location: c:\windows\system32\drivers

File Description: IMAPI Kernel Driver

File Version: 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) [5.2.3790.1830]

Product Name: Microsoft? Windows? Operating System

Product Version: 5.2.3790.1830 [5.2.3790.1830]

Company Name: Microsoft Corporation

 

 

----------------------------------------------------

Filter Driver Load Order http://www.bustrace.com

----------------------------------------------------

 

Upper Device Filter: redbook

Device Object: _NEC DVD_RW ND-3550A

Lower Class Filter: AnyDVD

Lower Device Filter: imapi

 

Driver Name: redbook.sys

File Location: c:\windows\system32\drivers

File Description: Redbook Audio Filter Driver

File Version: 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) [5.2.3790.1830]

Product Name: Microsoft? Windows? Operating System

Product Version: 5.2.3790.1830 [5.2.3790.1830]

Company Name: Microsoft Corporation

 

Driver Name: anydvd.sys

File Location: c:\windows\system32\drivers

File Description: AnyDVD Filter Driver

File Version: 6.0.1.1 [6.0.1.1]

Product Name: AnyDVD

Product Version: 6.0.1.1 [6.0.1.1]

Company Name: SlySoft, Inc.

 

Driver Name: imapi.sys

File Location: c:\windows\system32\drivers

File Description: IMAPI Kernel Driver

File Version: 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) [5.2.3790.1830]

Product Name: Microsoft? Windows? Operating System

Product Version: 5.2.3790.1830 [5.2.3790.1830]

Company Name: Microsoft Corporation

[LIGHTNING UK!]

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.

[CrashedAgain]

Have tried going down a version to where it was before when it works and although the disc does appear a littl ebetter still get the same no device buffer information

[chewy]

So my big question could new nforce ide drivers do this?

roll back your ide drivers till you are using windows default

 

as i had recently done a firmware upgrade

 

and that's how you hose your firmware

 

flash again in safe mode

Edited July 22, 2006 by chewy

[CrashedAgain]

Went to roll back the ide channel drivers and it says its already using the Microsoft ones which seems a little odd unless it never installed the nvida ones, which it did for sata.

[chewy]

when I was using nvidia drivers on my ide, I got really screwy burn times with single layer media, an 8x burn would take 20 minutes

[CrashedAgain]

Im moving away from the idea its to do with the ide drivers as it doesnt seem to be using them and returning to the old ones i had before this problem didn't make any difference, plus my burn times dl & sl are all normal.

 

Unfortunatly im not sure what options that leaves me with as im pretty certain ive ruled everything else out.

 

Ideas anyone?

[LIGHTNING UK!]

Are your burns much different to this one I've just done?

 

http://forum.imgburn.com/index.php?s=&...ost&p=20280

[CrashedAgain]

These are th escans from a few burns ive done before and after the buffer problem. All burned on Nec 3550 and scanned with LiteOn 851s@832s.

 

Before:

 

Bad 1:

 

Bad 2: (Best of the bad burns)

[LIGHTNING UK!]

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.

[polopony]

You should really get a Verbatim disc and eliminate the Riteks being the problem .I dont think any of the Beta members use them but have done burns and scans just for testing purposes and they came up as crap .With the right burner and media most if not all here get quality burns over 90%. I use NEC drives myself and really like the results, all burns are on Verbs and Taiyo Yudens(SL's). I have a few GO5's discs that are a couple of years old and the stuff I burned to then is still OK but the consensus is that Ritek just isn't the company it used to be.

[CrashedAgain]

lol until these coasters that good one would have been what i called average for this media, i have at least 10 other disks as good if not better (my best has a score of about 95%). i did change the firmware but when it went bad i changed back but got the same results. the media was a box of 10 with cases and all thse scans came from the same box, though i am now leaning more to a bad batch of disks as the possible cause as its always the same layer thats bad.

 

just checked svp. wow there cheap, ive vever bought verbaitem before as the cheapest ive been able to find them in teh uk is ?17 for a box of 5 but 10 for ?14 is great i paid 15 for these dud ones 6 of which are now being used as coasters.

 

still no idea though why th ebuffer shows as empty for the first layer?, also just noticed the first layer seems to burn best but thsi is when the buffer is showing empty, and teh second layer is crap which is when everything loosk normal odddddd.?????

Edited July 22, 2006 by CrashedAgain

[LIGHTNING UK!]

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

[CrashedAgain]

if you know a spti trace program that will work with xp64 i have a few disks left and am willing to give it a try.

Edited July 22, 2006 by CrashedAgain

[LIGHTNING UK!]

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