whipper drive analyze appears to be stuck

[BezPowell]

I've just installed whipper and am currently trying to set it up. Unfortunately, the whipper drive analyze command never seems to complete, it's been running for about 15 minutes so far and is still showing 0%.

System is Fedora 30, using the whipper 0.9.0 package from the official repos. I've tried manually applying the patch from 29ee670, but the issue still persists.
whipper.log.gz

EDIT:L The CD I'm using to test is: https://www.discogs.com/Pink-Floyd-The-Dark-Side-Of-The-Moon/release/8557307 which has worked previously through EAC in Wine. Drive as shown by whipper is: drive: /dev/cdrom, vendor: ASUS , model: BW-16D1HT , release: 3.03

[github-actions]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing instructions.

[JoeLametta]

Hi, what's the output of the following command (same CD, same disc drive)?

cd-paranoia -A -d /dev/sr0

[BezPowell]

I've tried running the command now, it seems to be doing the same thing as whipper, progresses and then gets stuck. Output is below:

cdparanoia III release 10.2 libcdio 2.0.0
(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.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.03 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:
	[42:44.20]:   51ms seek, 1.92ms/sec read [6.9x]                 
	[40:00.00]:   67ms seek, 1.96ms/sec read [6.8x]                 
	[30:00.00]:   51ms seek, 2.16ms/sec read [6.2x]                 
	[20:00.00]:   80ms seek, 2.44ms/sec read [5.5x]                 
	[10:00.00]:   81ms seek, 2.88ms/sec read [4.6x]                 
	[00:00.00]:   93ms seek, 3.69ms/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)                      
	Testing cache transfer speed..o

It gets stuck on the resting cache transfer speed step. Again left for about 15 minutes without any progress.

[JoeLametta]

All right, as I expected this seems to be an upstream bug so I suggest reporting it here.

[BezPowell]

@JoeLametta Thanks for the quick response on this. It seems there's already an upstream issue open for it which I've chimed in on.

[JoeLametta]

I'm closing this ticket because it has been confirmed as an upstream issue in cd-paranoia and there's nothing we can do about it in whipper right now.