whipper cd rip results in error reading TOC
#531
Comments
|
I got this again on https://musicbrainz.org/release/d5584f09-5c97-46e6-82ab-49782fac1d90, but ran it again with debug and then it worked. That makes it seem less input based. |
|
A third time on https://musicbrainz.org/release/f5526c13-4a30-47ce-9f3c-b5d1c085b71c Hm! |
|
Finally got one to fail while debug was on This is now reproduced on the latest Arch release of whipper, 0.9.0-2. I would not oppose hearing this is a device fault as it's so sporadic, but next is to look into the code. |
|
It could either be a bug in whipper's code (race condition, for example), a transient failure of cdrdao (which, I guess, sporadically fails to rip that CD) or a device fault. sudo umount /dev/sr1
cdrdao disk-info --device /dev/sr1 > cdrdao_disk-info.log 2>&1
cdrdao read-toc --device /dev/sr1 --fast-toc cdrdao_fast.toc > cdrdao_read-toc_fast.log 2>&1
cdrdao read-toc --device /dev/sr1 cdrdao_slow.toc > cdrdao_read-toc_slow.log 2>&1If cdrdao does fail, please attach the following files: |
|
Can do! |
|
I've run it a couple times and based on how it has behaved over hundreds of imports through whipper and other programs where the drive is very stable and returning Accurate Rips, I'd put my vote on race condition or device fault here. I am leaning towards race condition with that tmp file. |
JoeLametta
added
Bug
|
Hello, I seem to be able to reproduce this problem. I am also on Arch Linux, with kernel 5.12.10-zen1-1-zen x86_64 and have tried both whipper 0.10.0 and whipper-git 0.10.1.dev8+g09f6bf1-1 About half of my CDs will rip successfully every time I try, while others fail in a strange way every time. (Edit: Upon setting the correct offset, now all CDs that would have worked before will fail to read the last track, but that's a separate issue due to upstream libcdio/libcdio-paranoia#14. Some still fail to read TOC.) For the CDs that fail, whipper hangs for several minutes at reading the TOC, and doesn't appear to succeed in doing so. It then eventually returns the MusicBrainz info, and attempting to confirm it results in whipper incorrectly claiming the CD is a CD-R: At this moment, the CD drive shuts off and becomes unresponsive. Attempting to run the command again results in If I run it with the While this occurs, Based on the suggestion from this article, I tried unplugging my computer and all its devices overnight in case it was some weird power supply issue, but that didn't make a difference. I have attached the whipper debug log and cdrdao logs listed by Joe. |
|
i actually had this error when trying to read the wrong disk in a stack of CDRs. the error from cdrdao was the very helpful: it might have been nice to answer that instead of throwing an exception. ;) |
|
I got the same exception but cdrdao fails with In this case, everything worked again after ejecting and reinserting the disc. |
Steps to Reproduce
Expected Results
CD whips
Actual
Throws a stack trace in my one drive, not in my other. Very strange
Stack trace
Reproducibility
This happened twice on the same CD and not before it.
The next CD in my library read the TOC fine.
Environment & Drive info
OS: Arch Linux
Kernel: Linux 5.11.7-arch1-1 #1 SMP PREEMPT Wed, 17 Mar 2021 16:59:58 +0000 x86_64 GNU/Linux
Build: whipper-git 0.9.1.dev109+g87f3d00-1
Bad Drive
Good drive
The text was updated successfully, but these errors were encountered: