search

exislow / tidal-dl-ng

TIDAL Media Downloader Next Generation! Up to HiRes Lossless / TIDAL MAX 24-bit, 192 kHz.
GNU Affero General Public License v3.0
396 stars 35 forks source link

[Feature] Do not add the 2-5 second pause until the next file if the current file is skipped #196

Open mjg2821 opened 1 month ago

mjg2821 commented 1 month ago

Current Situation

I have a playlist with 664 songs in it. If I add some new ones and want to download them, I have to wait for Tidal-DL to pause 2-5 seconds in between each one of the 664 songs I've already downloaded.

Suggestion / Feature Request

It should just skip quickly through those first 664 songs and start downloading at the first undownloaded song, and then enable the 2-5 second wait.

Plastermaster commented 2 weeks ago

I'm pretty sure this is to avoid getting banned from Tidal, just let it run in the background.

mjg2821 commented 2 weeks ago

I understand what the use case is, but I'm trying to keep a playlist over 600 tracks long synced, and if I add three or four tracks, it takes a very long time. What I was thinking of is that there's some way to parse the playlist and compare it to the contents of the destination directory and only add the tracks that aren't already downloaded to the queue for downloading.

Plastermaster commented 17 hours ago

I understand what the use case is, but I'm trying to keep a playlist over 600 tracks long synced, and if I add three or four tracks, it takes a very long time. What I was thinking of is that there's some way to parse the playlist and compare it to the contents of the destination directory and only add the tracks that aren't already downloaded to the queue for downloading.

I have come across this issue now, though I don't see a decent way of fixing this.

WIth the delay disabled, the API starts throwing errors eventually about the content not being available, very likely because of how quickly it is calling the API. So, assuming it would remove the delay if a file already exists, after some time it will continously throw errors and possibly also skip tracks that aren't archived yet.

Maybe an overhaul on the delay timer might be useful to improve the overall time required to process downloads though.

For example, once a download is started and the files are being checked, start a timer. If the file already exists and it stops the timer, the time spent is very likely less than 100ms. And so, if the counted time is too short, have it add a bit more time on top to reach the minimum random delay time. If the file doesn't exist, start the download and stop the timer once the download finishes. In most cases in my experience, once the download is done, the delay isn't really necessary anymore as it'll take more than 5 seconds. In case it does take much less time, add whatever time is needed on top of the already spent time for the download and delay by that amount.

Just throwing this idea out. I'd like to give it a try and made those changes but I'm drowning in projects as is, no promises.