mirror of
https://github.com/Googolplexed0/zotify.git
synced 2026-04-25 06:15:55 +03:00
[GH-ISSUE #112] [Bug Report] Duplicate Downloads on Playlists (efficient-api branch) #99
Labels
No labels
bug
considering
discussion
documentation
enhancement
enhancement
good first issue
help wanted
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/zotify#99
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @on3iro on GitHub (Nov 11, 2025).
Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/112
Originally assigned to: @Googolplexed0 on GitHub.
Zotify Version
v0.10.26
Bug Description
I just installed zotify from the efficient api branch, since I also got the
alternative trackissue.Before I could simply download a playlist of songs and it would have downloaded them one by one beginning at the bottom of the list. The command I used was the following:
However since switching to the
efficient-apibranch songs aresong.oggandsong_1.ogg(or maybe they are not cleaned up properly after conversion?)Bug Triggering Command
Config File
config.json
@Googolplexed0 commented on GitHub (Nov 12, 2025):
I'm actually glad to have another person report this issue. After investigating #104, I was unable to recreate it on my system. Thought it might have been a config/installation/system issue for that user, but this shows there is an error in the code. If you can run again in
--debugmode and attach the log that would be extremely helpful.Does this behavior occur for any playlist or only a specific playlist? Does this playlist have duplicate song entries, especially songs with the same name (i.e. rereleases)? It might be easier to create a new public test playlist with as few songs as necessary to recreate the issue, and share that here to allow me to debug and test.
Does this occur if you attempt to download a track multiple times in one query, or the same song repeatedly across multiple queries?
@on3iro commented on GitHub (Nov 12, 2025):
i'll check this evening, try to create a small debugging example and report back :)
@on3iro commented on GitHub (Nov 12, 2025):
So here's what I found:
I tested with the following command:
The playlist is public and contains a single album.
Here's some of stdout zotify produced (I cancelled the download after I checked that I reproduced the issue):
Here's the debug-log:
zotify_DEBUG_2025-11-12_22-27-01.log
This is the filesystem of the downloaded playlist:
As you can see after a single run of zotify, each of the files that was downloaded, before I cancelled, has a duplicate entry.
The playlist does not contain any tracks with the same title.
I also tested other playlists - all with the same result.
Also when running the same command again afterwards, this is what happens:
and the filesystem:
As you can see zotify correctly identified the songs to skip, but still created additional copies of those files. It did not look like it downloaded them again, though - more like it copied them.
zotify_DEBUG_2025-11-12_22-36-11.log
Hope that helps
@Googolplexed0 commented on GitHub (Nov 14, 2025):
Very helpful!
Still extremely strange behavior, but I have an idea of what subroutine might be causing it. I'll do some digging and hopefully will have a fix in the next few days.
@DerKO9 commented on GitHub (Nov 21, 2025):
I have noticed this behavior as well. For a track I will see "Track already exists" but then it will create another duplicate with "_#" appended to name of the duplicate. I also saw no actual downloading happen.
I added that specific track to its own separate playlist and tried downloading it again. I saw "Track already exists" but this time it did NOT create a duplicate.
Currently trying to figure out consistent replication steps
@Googolplexed0 commented on GitHub (Nov 22, 2025):
I am still unable to recreate the bug on my system, even after copying your config.
Something must be calling
check_path_dupes()when it shouldn't. This is only called when handling siblings (same track being called from multiple places, like from an album and a playlist in the sameQuery, so shouldn't be relevant here) or when preparing a download andif not self._in_dir_archive and not Zotify.CONFIG.get_disable_directory_archives()is True.@on3iro @DerKO9, I added a few new debug prints to try and see if either of these cases is being called for you who are experiencing the bug. Please update to v0.10.27 and send another DEBUG.log!
@on3iro commented on GitHub (Nov 24, 2025):
@Googolplexed0 here's the debug log :)
And also the output when running the command:
@morgil commented on GitHub (Nov 26, 2025):
I have the same issue, but I would like to add that on my machine Zotify also often crashes on such a duplicate file (usually after having downloaded a few files from a given playlist). The stack trace then looks like this:
I could not (yet?) get crashes when appending the debug flag, so maybe there is some kind of race condition?
When running with --debug, the logs look similar to the ones above.
@Googolplexed0 commented on GitHub (Nov 29, 2025):
Found a way to replicate the error on my machine. Both of the areas I suspected were causing an issue were running when they should not. First one is an easy fix, since
check_path_dupes()was being run prior to download, it did nothing. The second had to do withMD_DISC_TRACK_TOTALSand improper sibling handling. Should be fixed withgithub.com/Googolplexed0/zotify@ee7e3647a3v0.10.28. I didn't see any side effects, but look out for any new/unexpected behavior, since I made some pretty major changes to how parents/children/siblings are organized and handled.@DerKO9 commented on GitHub (Dec 10, 2025):
I have updated to the latest version and I am not getting the duplicate songs like I did before. Thanks!!
@on3iro commented on GitHub (Dec 10, 2025):
Same here