Rip fails with: whipper.command.cd:got exception OSError(22, 'Invalid argument') on try 1

[gstpsk]

Trying to rip a CD, whipper fails to read the first track on the disc 5 times and aborts. Looking at the debug output we see a line like this

DEBUG:whipper.command.cd:got exception OSError(22, 'Invalid argument') on try 1

which is immediately followed by try 2, which also fails in the same manner.

Ripping the disc with cdparanoia works fine with no errors. The disc looks quite good and should definitely not have issues with reading.

The only oddity about it is that the CD is quite old. Made in 1986, perhaps the age comes with its quirks?

Attached below the log of the rip command with WHIPPER_DEBUG=DEBUG.

whipper.log

Thank you for your time, feel free to ask any other questions which may aid the process of resolving this.

EDIT: Skipping the first track using --keep-going rips the next track fine

[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.

[gstpsk]

gzipped version of the log

whipper.log.gz

[gstpsk]

I have potentially identified the issue, the first song, which fails to rip, has the following name

01. Wham! - Wham Rap! (Enjoy What You Do?).flac

When trying to fix the rip manually, I tried to rename the rip of the first track to this filename which failed with an error message saying:

mv: cannot move 'track01.flac' to a subdirectory of itself, '01. Wham! - Wham Rap! (Enjoy What You Do?).flac'

And then I realised, the question mark (?) in the title is probably interpreted wrongly somewhere in the code. I will try to look through the code tomorrow and see if I can spot the issue. There should probably be some sanitization on the MusicBrainz data that gets pulled.

EDIT: My music directory is located on an NTFS drive... this makes a lot more sense now, would this still qualify as a bug in whipper or is this something out of scope?

[snorfalorpagus]

If you set path_filter_vfat = True in the configuration file the problematic characters will be replaced with _.

https://github.com/whipper-team/whipper?tab=readme-ov-file#configuration-file-documentation

I came across this same problem when trying to transfer files to my NAS over SMB.