cd-paranoia fails to model drive's cache correctly

[copyread]

Hello. I'm trying to configure my CD drive correctly for the use with whipper. When configuring, whipper couldn't defeat the audio cache. @JoeLametta instructed me to check out the output of cd-paranoia -A. The command failed at 'analyzing cache behavior'. I attach cdparanoia.log below.
cdparanoia.log

(not that relevant, but the CD that was in the drive was Slaves and Masters by Deep Purple. after that I managed to get a perfect rip with whipper (with defeat audio cache disabled))
Deep Purple - Slaves and Masters.log

[rocky]

For what it is worth, the log just says basically what whipper said: that cd-paranoia doesn't know how to disable to defeat audio caching. It is possible/likely that cd-paranoia isn't needed then here and this is basically what you did.

In the slim chance that someone is interested in investigating further and fixing, the rip log seems to indicate you have

Drive: HL-DT-STDVDRAM GP57EB40  (revision PF01)

which internet searching seems to indicate is a Hitachi-LG Slim Portable DVD-Writer GP57

[BezPowell]

I seem to have encountered the exact same issue, also first noticed by trying to setup whipper and pointed to libcdio-paranoid by @JoeLametta. In my case my drive is an ASUS BW-16D1HT.

[remjg]

@BezPowell Same drive as you (ASUS BW-16D1HT) and same issue with Whipper (stuck at Testing cache transfer speed..o).

After waiting a while (maybe an hour, I don't know), the command completed:

$ cd-paranoia -A -d /dev/sr0
(...)
Using cdda library version: 10.2+2.0.0 x86_64-redhat-linux-gnu
Using paranoia library version: 10.2+2.0.0 x86_64-redhat-linux-gnu
Checking /dev/sr0 for cdrom...
	    CDROM sensed: ASUS     BW-16D1HT        3.10 SCSI CD-ROM

Verifying drive can read CDDA...
    Expected command set reads OK.

Attempting to determine drive endianness from data.......
    Data appears to be coming back Little Endian.
    certainty: 100%

Attempting to set cdrom to full speed... 
    drive returned OK.

=================== Checking drive cache/timing behavior ===================

Seek/read timing:
    [60:22.52]:   46ms seek, 1.60ms/sec read [8.3x]                 
    [60:00.00]:   42ms seek, 1.60ms/sec read [8.3x]                 
    [50:00.00]:   50ms seek, 1.72ms/sec read [7.7x]                 
    [40:00.00]:   58ms seek, 1.88ms/sec read [7.1x]                 
    [30:00.00]:   50ms seek, 2.07ms/sec read [6.4x]                 
    [20:00.00]:   57ms seek, 2.35ms/sec read [5.7x]                 
    [10:00.00]:   69ms seek, 2.77ms/sec read [4.8x]                 
    [00:00.00]:   94ms seek, 3.56ms/sec read [3.7x]                 

Analyzing cache behavior...
    Approximate random access cache size: 32 sector(s)               
    Drive cache tests as contiguous                           
    Drive readahead past read cursor: 1030 sector(s)                
    Cache tail cursor tied to read cursor                      
    Cache tail granularity: 1 sector(s)                      
            Cache read speed: 0.00ms/sector [219244x]
            Access speed after backseek: 3.57ms/sector [3x]
    Backseek flushes the cache as expected

Drive tests OK with Paranoia.

[rocky]

Whiile I guess it is good that here we are gathering data of drives that disabling caching is not working, it doesn't feel as such this is working toward a solution.

One idea from a long time ago is to collect a list of drives that don't work such as initially the above, and then have cd-paranoia skip those.

Any volunteers for this?

[Bujiraso]

Hi all,

I'd like to counter-weigh in quickly that my ASUS BW-16D1HT (release = 1.01) did have a cache that was disabled.

@rocky , is the solution being proposed to simply not provide cd-paranoia functionality on drives that fit a certain naming spec?

If so, we'd need to dig deeper than perhaps make and model. What's the release revisions here, @BezPowell , @remjg ?

Furthermore, I have a HL-DT-ST DVDRAM GH24NS90 (release = IN01) which the cache cannot be disabled and I'm receiving Accurate Rip reports happily, so I don't think it would be as easy as no disable cache -> no cd-paranoia functionality

[rocky]

the solution being proposed to simply not provide cd-paranoia functionality on drives that fit a certain naming spec?

From my standpoint, propose any reasonable solution and implement it.

A low-tech solution to get started might be for example to be add a wiki to this project and people can note features and flags and cd-paranoia options that seem to work. I just added https://github.com/rocky/libcdio-paranoia/wiki/Model-information,-features-and-preferred-cd-paranoia-options for this purpose.

@Bujiraso - feel free to add whatever information you have to this.

[Bujiraso]

Information collection definitely seems like a step in the right direction.
I've added some of my initial analysis, per your request, @rocky !

[the-confessor]

Hm interesting. I just got a brand new ASUS BW-16D1HT (release = 3.10) and cdparanoia cannot model the cache correctly.

Prior to this I tried the LG BD-RE WH14NS40 (release = 1.05) and had the same issue.

Based on @Bujiraso comment above I am wondering if the firmware version is making a difference, or if I am just doing something wrong.

I could also try getting another drive but that'd be my third time flying blind. They have flexible return policies, but it seems wasteful, not to mention slow, to just keep buying new drives to see.

Log from BW-16D1HT / 3.10:

$ libcdio-paranoia -A -d /dev/sr0
cdparanoia III release 10.2 libcdio 2.1.0 x86_64-pc-linux-gnu
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <rocky@gnu.org>
(C) 2014 Robert Kausch <robert.kausch@freac.org>

Report bugs to bug-libcdio@gnu.org

Using cdda library version: 10.2+2.0.1 x86_64-pc-linux-gnu
Using paranoia library version: 10.2+2.0.1 x86_64-pc-linux-gnu
Checking /dev/sr0 for cdrom...
		CDROM sensed: ASUS     BW-16D1HT        3.10 SCSI CD-ROM

Verifying drive can read CDDA...
	Expected command set reads OK.

Attempting to determine drive endianness from data.......
	Data appears to be coming back Little Endian.
	certainty: 100%

Attempting to set cdrom to full speed... 
	drive returned OK.

=================== Checking drive cache/timing behavior ===================

Seek/read timing:
	[52:07.09]:   17ms seek, 0.39ms/sec read [33.9x]                 
	[50:00.00]:   18ms seek, 0.40ms/sec read [33.5x]                 
	[40:00.00]:   19ms seek, 0.44ms/sec read [30.5x]                 
	[30:00.00]:   22ms seek, 0.48ms/sec read [27.8x]                 
	[20:00.00]:   21ms seek, 0.54ms/sec read [24.5x]                 
	[10:00.00]:   18ms seek, 0.64ms/sec read [20.8x]                 
	[00:00.00]:   25ms seek, 0.84ms/sec read [15.9x]                 

Analyzing cache behavior...
	Approximate random access cache size: 32 sector(s)               
	Drive cache tests as contiguous                           
	Drive readahead past read cursor: 1030 sector(s)                
	Cache tail cursor tied to read cursor                      
	Cache tail granularity: 1 sector(s)                      
	        Cache read speed: 0.00ms/sector [26548x]
	        Access speed after backseek: 0.88ms/sector [15x]
	WARNING: Read timing after backseek faster than expected!
	         It's possible/likely that this drive is not
	         flushing the readahead cache on backward seeks!


WARNING! PARANOIA MAY NOT BE TRUSTWORTHY WITH THIS DRIVE!

The Paranoia library may not model this CDROM drive's cache
correctly according to this analysis run. Analysis is not
always accurate (it can be fooled by machine load or random
kernel latencies), but if a failed result happens more often
than one time in twenty on an unloaded machine, please mail
the cdparanoia.log file produced by this failed analysis to
paranoia-dev@xiph.org to assist developers in extending
Paranoia to handle this CDROM properly.

[the-confessor]

well, here is some good news. weird, but good.

I read some reports on the dbpoweramp forum where people re-flashed the firmware on this drive.

so I downloaded version 3.10 of the firmware from Asus' website, updated the drive with it, and boom. now cdparanoia can model the cache.

$ libcdio-paranoia -A -d /dev/sr0
cdparanoia III release 10.2 libcdio 2.1.0 x86_64-pc-linux-gnu
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <rocky@gnu.org>
(C) 2014 Robert Kausch <robert.kausch@freac.org>

Report bugs to bug-libcdio@gnu.org

Using cdda library version: 10.2+2.0.1 x86_64-pc-linux-gnu
Using paranoia library version: 10.2+2.0.1 x86_64-pc-linux-gnu
Checking /dev/sr0 for cdrom...
		CDROM sensed: ASUS     BW-16D1HT        3.10 SCSI CD-ROM

Verifying drive can read CDDA...
	Expected command set reads OK.

Attempting to determine drive endianness from data.......
	Data appears to be coming back Little Endian.
	certainty: 100%

Attempting to set cdrom to full speed... 
	drive returned OK.

=================== Checking drive cache/timing behavior ===================

Seek/read timing:
	[52:07.20]:   44ms seek, 1.68ms/sec read [7.9x]                 
	[50:00.00]:   48ms seek, 1.72ms/sec read [7.8x]                 
	[40:00.00]:   50ms seek, 1.88ms/sec read [7.1x]                 
	[30:00.00]:   66ms seek, 2.08ms/sec read [6.4x]                 
	[20:00.00]:   60ms seek, 2.36ms/sec read [5.6x]                 
	[10:00.00]:   77ms seek, 2.84ms/sec read [4.7x]                 
	[00:00.00]:   79ms seek, 3.71ms/sec read [3.6x]                 

Analyzing cache behavior...
	Approximate random access cache size: 32 sector(s)               
	Drive cache tests as contiguous                           
	Drive readahead past read cursor: 1030 sector(s)                
	Cache tail cursor tied to read cursor                      
	Cache tail granularity: 1 sector(s)                      
	        Cache read speed: 0.00ms/sector [41457x]
	        Access speed after backseek: 3.72ms/sector [3x]
	Backseek flushes the cache as expected

Drive tests OK with Paranoia.

[Bujiraso]

After some 500+ CDs whipped, the motor in my ASUS drive set into a horrific screech as it finally burnt itself out, so I won't be able to check any details on my side, but that sounds like a fix perhaps.

Could the firmware be read and a notice given to the user if they are on known faulty firmware? Maintaining such a list would be fairly straight-forward -- just wait for GitHub issues, ask for them to check their firmware, see if it goes away, and log it if so.

Alternately, we could put a tip in the README that all users should update firmware before logging issues.

[rocky]

After some 500+ CDs whipped, the motor in my ASUS drive set into a horrific screech as it finally burnt itself out, so I won't be able to check any details on my side, but that sounds like a fix perhaps.

Could the firmware be read and a notice given to the user if they are on known faulty firmware? Maintaining such a list would be fairly straight-forward -- just wait for GitHub issues, ask for them to check their firmware, see if it goes away, and log it if so.

Alternately, we could put a tip in the README that all users should update firmware before logging issues.

Anything is possible if someone is willing to do the work. Hey, how about you?

[Bujiraso]

Anything is possible if someone is willing to do the work. Hey, how about you?

I've pitched in previously and now again with https://github.com/rocky/libcdio-paranoia/wiki/Model-information,-features-and-preferred-cd-paranoia-options
Documentation is a suitable solution to me, but I don't presume to speak for everyone.

[rocky]

I've pitched in too, so we are equal there :-) Leaving this as is a solution to me - there are your comments in the github issue, and if someone wants to add stuff to the wiki - go at it!. But I don't presume to speak for anyone but myself.

[zephryn]

I also seem to be having this same issue on an HL-DT-ST BD-RE WH14NS40 1.05 SCSI CD-ROM (branded as LG WH14NS40, factory firmware 1.05).

Interestingly, it seemed to stop trying to gauge the cache read speed and returned 0.00ms/sector like shown in other logs very soon after I ran a different command which wanted to use the disc drive in another TTY at the same time the cache modeling was still running (in this case whipper offset find).

This specific drive was already mentioned above but I figured I'd chime in.