How to deal stalled/stuck Slskd downloads?

[krisbalintona]

Hello,

I would like to know how best to deal with cases wherein an Slskd download is initiated by DeepCrate but ends up stalled (started, but doesn't progress). I'm not sure if that's the "official" term for it, so apologize if it goes by something else.

From DeepCrate's end it just reports the download as in-progress. I haven't watched DeepCrate long enough to see if something does happen after some long period of being stalled. I'm also not sure what happens if I end up deleting the download on Slskd: is DeepCrate "smart" enough to know I deleted it and mark it as failed?

If DeepCrate doesn't handle such cases gracefully, then I suppose my request, then, would be for it to do so. In my ideal world, I would have DeepCrate periodically tell Slskd to retry until it's stalled e.g. 3 times already, at which point DeepCrate would have Slskd delete the download and queue up that release again, prompting the user to try downloading from someone else. But I don't know how feasible that is.

[jordojordo]

Great question, and your instinct is right, DeepCrate is not currently smart enough to detect either a stalled or deletion (from the slskd side) case. Here's what happens:

DeepCrate polls slskd's /api/v0/transfers/downloads endpoint and maps each file's slskd state to one of queued, downloading, completed, or failed. The only way to get a failed state is by slskd itself reporting errored, cancelled, or timedout.

So this leaves us with two areas I haven't accounted for:

• Stalled transfers: if slskd reports the file as InProgress but it's not actually doing anything, DeepCrate will keep showing it as downloading.
• Deleted within slskd: if you remove the download from the slskd UI, the file disappears from slskd's response. DeepCrate will think there is no matching transfer and skips the task without changing the status. So yes, it gets stuck.

To workaround this for now, delete the task from DeepCrate's downloads page, not from slskd. When this happens it will call slskd to cancel and remove the transfer and will remove the task and the wishlist entry.

Afterwards you can either re-add the release manually or it will likely be re-discovered on the next ListenBrainz job run.

---

What you're describing is a reasonable enhancement and most of the model is already there. DeepCrate just needs:

• A stall detector
• Slskd deletion detection
• Auto retry

In my ideal world, I would have DeepCrate periodically tell Slskd to retry until it's stalled e.g. 3 times already, at which point DeepCrate would have Slskd delete the download and queue up that release again, prompting the user to try downloading from someone else.

This is certainly doable, there is a retryCount for searching wishlist items, this could be extended to downloads.