QSuite & Taiyo Yuden T03

vbimport

#1

Does anybody know why QSuite would show two different writing strategies under the ‘Solidburn’ tab for T03 media ?

The only media used that could effect this are Verbatim discs (batches TH001333 & TH000021) and Plextor discs (batch TH000015) - no other T03 discs have been used. (all batches show on the information tab as ‘Manufacture ID’ as YUDEN000 and ‘Media Type ID’ as T03


#2

Iteresting keyap !

I have example : The only Plextror T03 that I have of batch 021 has two entries

  • one with only “Yuden”
  • the other with the full "Yuden0000T03

The next question is whether

  • there are 2 revisions of the media
  • or the strings stored in the firmware are mixed up

Hope that the strategies are not mixed up :wink:



#3

I don’t know the answer to that, but on a related note my Verbatim branded TYG03 discs showed up only as “TY” on the QSuite SolidBurn tab for my BenQ 1655 BCHB drive. I then cleaned the table and burned another TYG03, and this time it was correctly listed as “TYG03”.

I have only a single batch of this media.

I suspect the same mechanism is at work here, but I don’t know if it’s a firmware or QSuite problem. :confused:


#4

One more thing from my above pic :

My drive has learned “0 pcs” for all the discs I have burned with all the media codes retained.
Weird !


#5

I noticed this problem quite some time ago with several MID’s like TYG02 and more. :confused: this drive is a 1655 cross flashed to a 1650, and I have a real 1650 but it has no EEPROM issue. No problems with a 1655 either.


#6

Well it looks like QSuite we have 2-3 different Firmwares posted


#7

I have had this happen before what I did to fix was turn SB off and on and clear EEPROM even though it shows nothing and the problem was fixed :confused: :confused:


#8

Quite an acute observation you made there !

As to the “0 pcs” learned, I must add that I only have used Solidburn on a "Temporal " basis, not “Permanent”.
The counter is not incremented in this case ??


#9

My drive has learned “0 pcs” for all the discs I have burned with all the media codes retained.
nVidia m/boards with Windows IDE drivers sometimes have this problems. (there are some older threads somewhere :iagree: )

Nothing to worrry about though as Solidburn is still working OK.

If this is your problems and you wish to resolve you can install nvidia IDE drivers, but there seems to be a few threads quoting the pros and cons of this.

Personally I use the nvidia drivers with a MSI K7N2 Delta board and can see no difference. (other than I get a ‘media count’)

Sorry if it’s a bit off topic guys :o


#10

For the records, keyap, I use neither Nvidia, nor Via, not even Intel :wink:
It’s an MSI based on the ATI Express 200 chipset. In fact, Compaq renames it “Amethyst” mobo.

Back to topic, I didn’t seem to suffer from problems with burning either.


#11

Not necessarily. :disagree:

SolidBurn in all those firmwares probably use the same code base, so it still might be a general problem in the firmware.


#12

Interesting questions indeed guys… But to pin down the problem we have to be more precise.

First of all SolidBurn strategies are not stored in firmware, they are stored in drives eeprom.
Second, what kind of problem in firmware do we have in mind, because firmware per definition can’t cause this behavior.

To get somehow near the cause for this anomalies, we have to learn more about what’s stored in drive. This link might give some hints.
It’s rather late here now so I won’t be able to participate but please post your findings and we’ll all be back tomorrow.

[I]Somewhat off topic[/I]

Don’t know about 165* drives, but on 1640 it “learns” and counts, no matter if setting is permanent or temporarily.
But then, we even had this counting problem with some 1640 drives… Crap QSuite can’t even count to six. :smiley:


#13

Huh? Are you serious?

The SolidBurn strategies are created and used by the drive itself without QSuite taking any active part, and I find it very unlikely that the workings of SolidBurn is hard-wired into the drive instead of being part of the drive’s firmware.

So even though the SolidBurn data is not stored in the firmware, the SolidBurn code is most probably part of the firmware.

So it is quite likely that such behaviour is caused by a programming bug in the SolidBurn part of the firmware!

It’s definitely also possible that QSuite is simply displaying the wrong information, however.

I think it’s very hard to get beyond these speculations about whether the problem is caused by firmware or QSuite bugs, but perhaps someone has a brilliant idea or insight?


#14

Yeah, “huh” DrageMester, believe it or not I’m very serious about this, simply because I, like you and all the rest, just wanna know more about what causes all this… :smiley:

It’s obvious, for SolidBurn to function at all it needs “data”, anything else is out of question. And if you read again, you’ll see that I said; “firmware per definition can’t cause this behavior”. Maybe not clear enough, but my though behind that was; if firmware would cause all this, we all would have the same, or almost the same problem as desribed by TP.
This also answers your “programming bug” part.

QSuite? We can’t answer this until we had a look in eeprom.

Speculations? By using TraceSPTI we can overrule some of speculations. But sofar not that many had a deeper look in that tool from what I can see here.
(Maybe I’ll make a guide when I have more time.)


#15

I can confirm my nforce2 mobo using MS ide driver will not increment the counter either.

One day after work I stuck that same burner into an old P2 system and the counter incremented. I put that same burner back into my nforce 2 mobo and the counter is back to zero again :smiley:


#16

@ max_clif

I can confirm my nforce2 mobo using MS ide driver will not increment the counter either
Hi max_cliff, I’m not sure if I explained it too well above, but my MSI m/board is also nforce2.

Here’s the link to the Nvidia Unified 822 driver bundle. Once you download and run simply install the NVIDIA storage driver (deselect the rest). After a reboot this will replace the windows IDE driver and, fingers crossed :smiley: , the counter will work.


#17

To be more specific I have (3) 165* drives only 1 has the counter problem, with 1650 FW or 1655 FW all versions. Also IDE interface, USB or 1394 it makes no difference


#18

@ DrageMester, jamescooley1, keyap, max_clif and zebadee, please check your PM’s.

:wink:


#19

@ pinto2

Hope this is what you need :flower:

TRACESPTI - Log - 180506.txt (43.5 KB)


#20

Hi all :wink:

After sending a few PMs to pinto2 we may have found the ‘trigger’ for the double entry:-

Last night I ‘cleaned’ the learned discs in an attempt to reproduce the two entries for T03 media (initially without success). Even after burning about 10 ish discs (both Verb and Plextor) only one entry showing YUDEN000T03 was seen. :doh:

Without burning any further discs when the comp. was turned off and back on the entry had changed to YUD T03, although previous restarts had not caused any change :confused: :confused:

A further T03 was then burnt creating a new entry of YUDEN000T03.

Anybody got any ideas why a restart would sometimes cause this?

Time to start scratching heads :iagree: