spotify-downloader: BUG: Mutagen ID3 No header error

Hello, just so you know, you’re not alone. Just installed the latest release and I’m experiencing exactly the same issue (with an album) on Debian 10 Buster stable on a fresh new VPS.

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.98. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

Reviewing the code in download.py also reveals a failure to check returns codes from the spawned ffmpeg process, and that’s the root cause of the problem I’ve encountered. If ffmpeg fails for any reason, the spotDL code will keep on working. If the output file isn’t written, it ends up hanging with 100% CPU usage due the loop I quoted above.

For me, the issue is that I’ve got ffmpeg version 7:4.1.6-1 installed. This is the newest official version for the Raspberry Pi:

$ sudo apt install ffmpeg
Reading package lists... Done
Building dependency tree
Reading state information... Done
ffmpeg is already the newest version (7:4.1.6-1~deb10u1+rpt1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

However, that version doesn’t support the pad_dur option for the apad filter. spotDL passes this filter in the chian (as apad=pad_dur=2). ffmpeg fails, that failure isn’t detected; ffmpeg writes a zero-byte output file, spotDL doesn’t care to check, and crashes.

Getting a newer version of ffmpeg from snap exchanges this problem for another issue:

$ sudo snap install ffmpeg --classic
2021-01-25T15:54:27-08:00 INFO Waiting for restart...
ffmpeg N-76538-gb83c849 from Snapcrafters installed
Channel latest/stable for ffmpeg is closed; temporarily forwarding to stable.

because that version doesn’t support the -abr option. I’ll hve to find a way to get a version compatible with spotDL.

Until then, a raw Python stack dump is pretty harrowing for most users. Maybe the spotDL developers will consider any of these suggestions to improve matters for their users:

• Document the required version of ffmpeg as 4.2 or newer (when pad_dur support was added)
• Check the ffmpeg version at startup; if older, omit the pad_dur parameter; perhaps with a warning message
• add code that checks the process.returncode in download.py to see if the spawned process failed or worked; if it fails, do something sensible instead of trying to process a broken output file
• catch the piped output from the process to develop a clear error message. ffmpeg shows the user an actionable error message
• add a --debug option to the script to share more output

Reinstalling Python, as recommended above, won’t fix this issue.

Point taken.

Can we close this off? I don’t believe it is an issue with SpotDL to begin with.

@mikeblas There’s no need to be rude and speak down upon the developers who have put hundreds of hours of time into spotDL.

• There was a discussion about a FFmpeg version on our discord - Have a look there.

We have had multiple developers look at this issue, as evident by the replies. I implore you to show respect for the work we put in.

For me, the issue is that I’ve got ffmpeg version 7:4.1.6-1 installed. This is the newest official version for the Raspberry Pi:

I have the same issue and is caused by the same ffmpeg version on Debian 10.

Thanks @mikeblas for the great input. I think that we can apply your suggestions, but that can take some time.

The await process.communicate() waits for the process to finish, it doesn’t matter that the streams are not piped, this code doesn’t care about them as the output is assigned to _. The only purpose of this code is to hold the execution until the process finish. The communicate() method is better than wait() as the later deadlocks when streams are piped. I prefer to always use communicate() to avoid weird problems in the future if someone will pipe any stream.
The while loop, however, is weird. I’ve also got bitten by it - when ffmpeg didn’t create a file for any reason, the application got stuck. I’m pretty sure we shouldn’t enter this part if ffmpeg exits with non-zero code.

I don’t know anything about ffmpeg, but your suggestion to adjust the pad_dur parameter makes sense - I’ll let other folks, who know ffmpeg better decide here.

I like the idea of adding --debug switch, as it may be very useful in the future.

No developer has been able to reproduce this error in recent versions of spotDL.

• Try again to uninstall spotDL & all dependencies, then install with --no-cache-dir flag
• Reinstall python - Something is clearly not working for you, since it works for the majority of other users.

Could you open an issue at quodlibet/mutagen? They’re more well versed with the library. It’d be much more simpler that me relaying info b/w you and them