[GH-ISSUE #39] Inverted download order of playlists et al. #32

New issue

Closed

opened 2026-02-27 04:57:11 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 04:57:11 +03:00

Owner

Originally created by @chr15t0ph on GitHub (Jul 30, 2025).
Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/39

Ideal Solution
I would like to have command line parameter that inverts the order in which the playlist is downloaded.

Additional context
My motivation is that by rate limiting reasons the overall downloads fail at some point, as it is well known. Thus, the download must be rerun. We could get faster completeness of the playlist, when a rerun could be started from the other end.

Originally created by @chr15t0ph on GitHub (Jul 30, 2025). Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/39 **Ideal Solution** I would like to have command line parameter that inverts the order in which the playlist is downloaded. **Additional context** My motivation is that by rate limiting reasons the overall downloads fail at some point, as it is well known. Thus, the download must be rerun. We could get faster completeness of the playlist, when a rerun could be started from the other end.

kerem

2026-02-27 04:57:11 +03:00

closed this issue
added the
enhancement

considering
labels

kerem commented

2026-02-27 04:57:12 +03:00

Author

Owner

@Googolplexed0 commented on GitHub (Aug 1, 2025):

Playlists are already downloaded in reverse order when not creating an m3u8 playlist file. I am working on another idea to help reduce/remove rate limit constraints, see #41.

@Googolplexed0 commented on GitHub (Aug 1, 2025): Playlists are already downloaded in reverse order when not creating an m3u8 playlist file. I am working on another idea to help reduce/remove rate limit constraints, see #41.

kerem commented

2026-02-27 04:57:12 +03:00

Author

Owner

@chr15t0ph commented on GitHub (Aug 1, 2025):

Yes, exactly. Most (all?) playlists are spotify-ordered from, e.g., 100 down to 1. Thus, in case of failed downloads, mostly several songs in the number area 01-20 are missing. I hope this case represents the usual use case for most users.

The skipping of the existing files (e.g., 80 of them) takes significant time (e.g., 80 to 160 seconds). I am not sure why. I reduced some delay parameters to 0, in the hope that this is caused by explicit delays, but it seems not the case. (Is there for each file a metadata lookup with the SpotifyAPI?) If it would be possible to reduce the skipping time for existing files to milliseconds, this would render the idea about --reverse obsolete. However:

In the assumption that the skipping time for existing files to milliseconds is NOT easy. And hoping that the "reverse" order option could be implemented far more easily / without much effort, it would be a major first-aid-improvement. Again my example/thoughts, just put aloud for final clarifications:

In the example above, reversing would then start from 1 and start downloads nearly immediately in the context of the missing ones, without the skipping phase. In my opinion, three runs usually gives a complete list: 1) fast (i.e, non-realtime) normal-order, 2) fast reverse-order, 3) real-time normal-order (for any arbitrary missing gaps in the downloaded list). This method seems much faster than using real-time option for the complete list!

@chr15t0ph commented on GitHub (Aug 1, 2025): Yes, exactly. Most (all?) playlists are spotify-ordered from, e.g., 100 down to 1. Thus, in case of failed downloads, mostly several songs in the number area 01-20 are missing. I hope this case represents the usual use case for most users. The skipping of the existing files (e.g., 80 of them) takes significant time (e.g., 80 to 160 seconds). I am not sure why. I reduced some delay parameters to 0, in the hope that this is caused by explicit delays, but it seems not the case. (Is there for each file a metadata lookup with the SpotifyAPI?) If it would be possible to reduce the skipping time for existing files to milliseconds, this would render the idea about --reverse obsolete. However: In the assumption that the skipping time for existing files to milliseconds is NOT easy. And hoping that the "reverse" order option could be implemented far more easily / without much effort, it would be a major first-aid-improvement. Again my example/thoughts, just put aloud for final clarifications: In the example above, reversing would then start from 1 and start downloads nearly immediately in the context of the missing ones, without the skipping phase. In my opinion, three runs usually gives a complete list: 1) fast (i.e, non-realtime) normal-order, 2) fast reverse-order, 3) real-time normal-order (for any arbitrary missing gaps in the downloaded list). This method seems much faster than using real-time option for the complete list!

kerem commented

2026-02-27 04:57:12 +03:00

Author

Owner

@Googolplexed0 commented on GitHub (Aug 14, 2025):

No longer considering, new efficient-api backend (even in alpha) skips redundant tracks significantly faster. Willing to come back to this if desperately wanted on its own merits (rather than a stop-gap for slow skip times).

@Googolplexed0 commented on GitHub (Aug 14, 2025): No longer considering, new efficient-api backend (even in alpha) skips redundant tracks significantly faster. Willing to come back to this if desperately wanted on its own merits (rather than a stop-gap for slow skip times).