I had downloaded all tracks using ‘All Music’ playlist. Decided I didn’t need it all, so I created a bespoke playlist. Put albums in there and set it to download.
I then removed the ‘All Music’ from Downloads.
It appears to have not cross referenced the other playlist as it removed all the tracks and needs to download them again.
Thanks
what OS? and please always post logs with reports.
sorry iOS 27 rc
Logs attached, also after then re-downloading it’s stuck with 410 left. They all downloaded before.
Plexamp-Logs-2026-09-10-1.zip (888.1 KB)
Had a dig into this. Downloads share their files, and removing one download is supposed to keep anything another download still holds, so what you describe shouldn’t happen. I wrote tests for exactly your case and both pass: a playlist and an album sharing tracks, remove the playlist, and only the tracks nothing else holds get deleted. Same result when the album hasn’t finished downloading yet.
There is one gap that would produce what you saw. A download only stakes its claim on the tracks once we’ve fetched its contents from the server, which is a moment or two after you tap download. If the old download went away inside that window, nothing was holding the shared tracks yet, so they got cleaned up and the new playlist had to fetch them again.
So one question: when you removed ‘All Music’, had the new playlist already shown its track count, or was it still working that out? If it was still spinning up, that’s the gap and I know what to fix. If it had settled and showed its tracks, then something else is wrong and I’d like the logs.
Either way it should be holding on to those tracks earlier than it does, so thanks for the report.
Yeah it could well be in that window.
I created the playlist, hit download and then went to the Downloads area and removed the ‘All Music’ playlist.
Thanks
Logs confirm it, and it’s the gap I described. Seventeen seconds:
08:55:19 Adding 10 items to download queue <- your new albums
08:55:36 Removing item with 9483 tracks <- All Music
08:55:36 Deleting tracks, 9464 <- only 19 spared
08:55:42 Unlinked 7970 media files
When you removed All Music we had only worked out the contents of a handful of those ten albums, so only 19 tracks were being held by anything else. Everything else genuinely had no other owner at that instant, so it went. The sharing works, it just hadn’t been told about your new albums yet.
That’s ours to fix: we should claim the tracks the moment you tap download, not once we’ve fetched each album’s contents from the server. Doing that would have saved the lot. I’m on it.
Separately, the stuck-at-410. I can’t tell from this log, because it ends before the stall settles in, and it’s a different problem from the deletion. If it’s still stuck, could you grab logs while it’s sitting there? Your download is 730 tracks and we queue them in rounds of 200, so if a round is failing quietly the remainder would just sit, which would match what you’re seeing.
Following up on the 410. Your logs suggest it may not actually be stuck.
Before you restarted, the counter was wedged: it sat at 412 and wouldn’t move, even while tracks were finishing. After the restart it recalculated from scratch and started coming down again, 412 then 410, which is where you looked. Earlier in the same session it was clearing two or three tracks a second, so 410 should be a few minutes of work rather than a wall.
The log ends a few minutes after that restart, so I can’t tell whether it kept going.
So: is it still 410 now? If it is, that’s a real problem and a fresh set of logs taken while it’s sitting there would show me why. If it has come down or finished, then the only bug here was the counter getting stuck before the restart, which is worth fixing on its own.
Don’t do a top-level refresh on it in the meantime. On a download that size it walks the whole thing again and would bury the evidence I need.
Sorry I did a reinstall and lost that. Will get logs if happens again.
