-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] (Dev Branch) Forbidden Access errors thrown on deezer playlists cause FileNotFound / Mutagen errors down the line #701
Comments
Temporary solution as of writing: Remove or download individually any track giving an error so it gets added to the database and will be skipped upon downloading the playlist |
Can you show the full traceback with |
Should be reproducible anywhere with the provided example playlist. Basically these tracks should be skipped I guess, by capturing 403. It's weird, I saw a fix with (Don't mind the
|
More info: btw, you can check the track links and other info using API link like this: https://api.deezer.com/playlist/12798749361/tracks Somewhere in the issues here or in another project I saw someone mentioned that Deezer changes track IDs frequently and it brakes the funcionality of course. So download errorred tracks separately is not a workaround basically, it's a solution for broken links in playlists. |
So if you publish the debug log for 1 of those invalid tracks it would be a bit shorter that for the whole playlist. |
I also switched over to the dev branch due to this error. However, I'm finding that streamrip is seeing the individually downloaded track (ie. the link copied when clicking to the song outside of my playlist) as different to what's in the playlist - despite same track being played. To note, the track that downloads from the direct link copied outside the playlist works yet not in the intended playlist's directory of course. In addition to the different iD issue, it seems to have a different name when trying (well, failing) via the usual playlist link vs via streamrip search and direct track link, both working fine. Nevertheless, I can't seem to make streamrip skip the errored playlist track after successfully running streamrip for the URL or its search command. Could the different track names being picked-up be why the suggested workaround isn't working? I hope I missed something obvious! I neither could find anything in the manpage regarding editing the downloads and failed databases via streamrip. |
Describe the bug
This is a followup to BUG #677 w.r.t. the fix for it on the dev branch
For unknown reasons certain tracks in my public deezer playlists throw
403: Forbidden
errors upon attempting to download them (first attempting to decrypt). This issue presents itself on all playlists I've tried so far, although I was able to download some albums without issue. Furthermore, downloading the problem song singular via search also works!My understanding is that after skipping the download of a forbidden song, its reference is not removed/hidden from the list of tracks in the playlist used later on in the process to delete temporary files. Causing an initial
FileNotFoundError
which then cascades to sometimes mutagen file manipulation errors or something else (coroutine never awaited).This error always occurs when
Removing dirs set()
is called withinartwork.py:19
, even if having disabelled the embedding of art in the config fileCommand Used
rip url "https://www.deezer.com/en/playlist/[public playlist]"
Debug Traceback
Config File
Operating System
Windows 11
streamrip version
2.0.5
Screenshots and recordings
No response
Additional context
Example playlist which throws error: "https://www.deezer.com/en/playlist/12798749361"
I transferred all my playlists yesterday from spotify to deezer with their transfer tool.
I'm not too familiar with the codebase, but going based off the errors and a quick perusal of some of the code. I assume the error handling of a forbidden track needs to pass/alter the state of expected tracks on which later functions rely
The text was updated successfully, but these errors were encountered: