Tracks that fail to download are not skipped (hangs)

[teticio]

Hi

Thanks for such a fantastic job with this repo and particularly for fixing the auth recently.

When downloading a playlist, I find it gets stuck on a few tracks and then says

ERROR librespot_playback::player: Skipping to next track, unable to load track <SpotifyId("spotify:track:6LaIwvv6n101g4JNcRCaSm")>: ()

but it doesn't skip, it just hangs at 0% downloaded. Would it be possible to make it skip those tracks? This is an example of one that doesn't download for whatever reason, but I suppose it may depend on the region you are in. If you are able to fix the download for these cases, even better.

The full log is:

⠲ Itadi - Ibakubuele [00:00:00] [-------------------------] 0 B/86.47 MiB (0.0s)2025-07-08T14:13:15.193083Z ERROR librespot_core::audio_key: error audio key 0 2    
⠚ Itadi - Ibakubuele [00:00:03] [-------------------------] 0 B/86.47 MiB (0.0s)2025-07-08T14:13:17.569790Z ERROR librespot_playback::player: Unable to read audio file: Symphonia Decoder Error: end of stream    
2025-07-08T14:13:17.569900Z ERROR librespot_playback::player: Skipping to next track, unable to load track <SpotifyId("spotify:track:6LaIwvv6n101g4JNcRCaSm")>: ()    
⠲ Itadi - Ibakubuele [00:00:29] [-------------------------] 0 B/86.47 MiB (0.0s)

[GuillemCastro]

I will try to reproduce it and implement a fix 👍. You are probably getting rate limited, you could try reducing parallelism to just 1 download --parallel 1.

[michaeljohnbennett]

I think this is partly rate limiting but also something happens with the decoding on larger playlists.

I find that the 1st 1/3 might work successfully then the rest are 1kb FLAC files as they crash but the downloader looks like its working.

I have to delete all the 1kb files and retry. Because we have the file exists code in there already it just skips the ones it has.

A smarter way would be to check the file size and if its say <3kb it redownloads it again.

[teticio]

Thanks @GuillemCastro. I found it would always get stuck on the same few tracks: if I removed them from the playlist it would happily continue until running into another similar case. I can't see what is special about those tracks though. Hope this helps.

[GuillemCastro]

Can you provide an example on which tracks it always happens for you? Does it also happen if you try to download them independently?

[teticio]

Hmmm, maybe you are right, there is some rate limit. The thing I found weird is, even if I restart the playlist download and it skips all the ones I have already downloaded, it chokes on the first one. However, if I grab that id and download the track individually, it works. I haven't dug into the code, but perhaps it is always making the call to Spotify that triggers the rate limit, even when the track has already been downloaded. To reproduce, you can try with my playlist:

spotify-dl https://open.spotify.com/playlist/47FgSbGfgEOBhjS8DHnKDi?si=20baab5dde1d4f81 -t 1

For now, I will just do it semi-manually. Would be very cool if it could handle playlists a bit more smoothly (like it used to).

[GuillemCastro]

It seems that Spotify is applying some sort of rate-limiting after ~30 tracks. It even happens on the official app if you skip the songs very quickly. It does not seem to be super consistent, since some tracks trigger it quicker than others 😕.

I'm adding better failure management and some retries when tracks fail to be loaded here https://github.com/GuillemCastro/spotify-dl/pull/36. Once that is released, spotify-dl will attempt to load a track up to 4 times and, if all attempts fail, it will continue to the next track.

[teticio]

That sounds great, but if you are right about the 30 tracks rate limit, will it not just get stuck on the next one? Although I think it would be good if it actually skipped tracks when it says it is going to, perhaps what is called for is a command line parameter to throttle the requests, like --delay <seconds> between track downloads. WDYT?