Ability to search again and download from other user after download fails on the 1st time

[andredatele]

I have a pretty high error rate with slskd, with only about 60% of the songs being downloaded (from the playlists generated by Listenbrainz).
Probably there is something to be tuned in slskd (though I already have port forwarding on, so don't know really what to change next), but it would be great that explo could re-trigger a download from another user, if the first download fails the first time around. And perhaps let the user specify how many times should explo retry the download from other peers.

[timkeefer1]

Agree with @andredatele - having better handling with slskd would be really beneficial. I've moved over from YouTube to slskd and it's not handling failures well. I get a bunch of "Completed. Errored" that should just get retried from another user.

I'm actually curious how its picking from who to download - sometimes files are "locked" - I'm kinda new to slskd, but I doubt these should be picked from available options (not sure if it ignores these or not).

[LumePart]

Explo retries downloads 3 times (by default) when a track cannot be queued, which usually happens when a user rejects the request straight away.

Once a track has been added to the queue, Explo does not perform checks for errors. Part of the challenge is that these errors are not well documented, which makes it difficult to determine why a download failed (for example, whether it's possible to just retry the same download).

I agree that a similar retry could be added for tracks that are in the queue.

Track filtering is fairly straightforward. Explo filters out locked files and users with full queues. It then discards files that don't match the filter options in Explo (keywords, bit depth, bitrate, and preferred formats).

[andredatele]

While I agree that retrying items already in the queue is added value, my initial question was whether it would be possible to re-search items which are on the queue and which have failed, and add them to the queue from another source/user.
I have monitored slskd as explo was running and most of my failed downloads were failed items in queue but for which I couldn't retry. Almost as if the user on the other side rejected my download?

[timkeefer1]

@LumePart
'errors are not well documented, which makes it difficult to determine why a download failed'

Agree - unless I'm missing something by being a slskd newb, it's almost funny how opaque the failure results are.

My idea would be zero retries. If it fails just give up, kill and remove the DL, and move on to another user. I wouldn't try and be too cute about it :)

[andredatele]

In the meantime I have discovered slskdn which is a fork of slskd which has a feature (among many others) that auto-replaces stuck downloads.
I'll give it a try for this coming week's playlist.

[timkeefer1]

In the meantime I have discovered slskdn which is a fork of slskd which has a feature (among many others) that auto-replaces stuck downloads.
I'll give it a try for this coming week's playlist.

Took a look at this last week, didn't implement as the AI usage declaration at the end seemed ... weird? Like even the declaration was written by AI. Maybe I'll give it a shot if you have good experience with it but it feels like AI slop and likely to break in the long term and full of CVEs.