Unable to download albums past 50 tracks

[alextarrell]

When downloading large albums, tracks past 50 will be detected as already existing and not download them. It looks like it's looping around back to the first track instead of continuing with track 51.

% ./tdl get https://listen.tidal.com/album/201482078
Getting Track Info for: [1] <Track 1 name>
Submitting Track to Download Queue: [1] <Track 1 name>
Download Complete | [1] <Track 1 name>
...
Getting Track Info for: [50] <Track 50 name>
Submitting Track to Download Queue: [50] <Track 50 name>
Download Complete | [50] <Track 50 name>
Getting Track Info for: [1] <Track name 1>
Submitting Track to Download Queue: [1] <Track name 1>
File Exists | [1] <Track name 1>
...
Getting Track Info for: [35] <Track 35 name>
Submitting Track to Download Queue: [35] <Track 35 name>
File Exists | [35] <Track 35 name>

(lines omitted/altered for brevity)

Subsequent attempts on the same albums will encounter the same error on the same tracks. This will also affect downloading by artist once it reaches the same album. Changing the number of workers/downloads does not have an affect on the issue, though I was seeing EOF while parsing a value at line 1 column 0 errors.

If one were to download all the tracks individually they will work just fine, so this is likely the workaround.

% tdl get https://listen.tidal.com/browse/track/201482079
...
% tdl get https://listen.tidal.com/browse/track/201482163

[MinisculeGirraffe]

The behavior is 100% caused by a bug in this function.

I'll work on a fix and author a new version with it patched in a couple hours.

[MinisculeGirraffe]

Got the fix in place (#18).

The Tidal API only lets you get up to 50 items of an album/playlist/artist as a time, and I forgot to re-calculate the offset per loop 😅.

Easy fix, Appreciate you bringing it up.

I authored v0.2.5 with this in place. The CI should have the binaries built in a few minutes.

[MinisculeGirraffe]

That's a separate error, the Tidal API returned a null value in an unexpected place. There's still a few edge cases of that laying around since there's not any formal documentation laying around. An easy fix, just need to know where the null value showed up to update that type to be nullable. Can you open an issue about it? You can enable debug logging with the RUST_LOG=debug environment variable, and include the output, which will show the JSON of the request before the parsing error occurred. Example Command: RUST_LOG=debug tdl get <playlist_link>

…

On Sun, Aug 7, 2022 at 9:48 PM Phil Kauffman ***@***.***> wrote: Downloading playlists is now broken. invalid type: null, expected a string at line 1 column 21924 — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMCLQ7C6QL4PFLYTYBJADS3VYBYQPANCNFSM553BZHQQ> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[deimidis]

Hi, sorry to bring this again, but trying to get a 100 tracks album, just get 51. Should I paste debug info right here?

[deimidis]

I just ran it with DEBUG option. It generates both download commands (i see a JSON with the first 50 and another with the rest) but only downloads the first one (maybe Tidal limit). Is there an easy way to add the offset on the command to download?