Strawberry creating duplicate tracks when using "move to collection" #1341
Comments
manofsticks
changed the title
|
After making this report, I've actually hit an instance where a "less than 10" track has this issue, so I guess disregard that detail. |
|
I can't reproduce this but check if 1ff2bfd fixes it. |
|
EDIT: Original debugging I did I was too tired and using production version. Deleted all that, making a new comment with new notes now. |
|
This did not fix it completely, but looks like it made a big improvement; I notice when importing new tracks that I've never had this issue on before, I am not able to reproduce the bug. However on some tracks I've had in Strawberry before (such as the examples I've been using, where I'm deleting them out of Strawberry and moving them back in repeatedly) it still happens. Video below, shows the console output too. This also shows the issue where "Organize" will not consistently fix it, so not sure if that's related to the change, or just a coincidence. Steps I followed in case I did something wrong in my testing: Compiled from source, verified the change from 1ff2bfd was included (looks like it's already in the master branch, so I didn't make any changes after the git clone). Only make warning I got was Which I assume won't impact testing. md5sum of the end build: dd15038563b33cd2fb341bb640ba5f7d Console log from a "Move to Collection" (not the same one as the video, but from another test)
Screenshots for readability: It looks like it first reads the tags
Then it performs "Processing"
Then it checks valid file
But I'm not seeing anything with duplication in the logs there, it looks like it should be processing each file once in each step. With this build, it looks like it's more consistently duplicating every track though, not just after track 10. |
|
As far as I can tell from your logs, there is no indication that anything is updated or added to the database, which is really strange considering that you are getting all those duplicates, is this the complete logs? I also notice that you are moving files from /media/MyMedia/music to /media/MyMedia/MUSIC, is /media/MyMedia/music a completely different path not part of the collection in any way through symlinks? If anything is updated in the database, it would log something like this prefixed with CollectionWatcher.:
But the only thing I see from your logs related to CollectionWatcher is.: So when it's not logging anything more after "Checking for valid file", it means the mtime matches so there is no need to update the database. There is only one other place where the song can be added/updated and that's the organize feature itself, but after my fix it should only update a song if the song that is organized already is a collection song, which it shouldn't be. |
|
The "from" path is "/media/MyMedia/music to add/!UPGRADE" in this instance, a completely separate path. Not sure if it's an issue with the logs, or my terminal emulator that's removing the escape character before a space. But there is no "media/MyMedia/music" I believe I posted the logs from the moment I hit "move to collection" until completion, apologies if you needed any startup logs (or if I messed up). Please see the below logs from a new run, everything from start, verifying the tracks are not there, "Move to Collection", then checking and seeing the duplicates. As part of this log I am not performing "organize files" after I move to the collection. With this instance, I saw 2 instances of each track in the Collection.
|
|
Sorry, I misread the source path, now I see that it is "/media/MyMedia/music to add/!UPGRADE". I see now that there is a case where nothing is logged, that's when the song already exists in the DB but is marked unavailable and rediscovered. So if you are testing with the same songs and the same paths, there are probably still duplicates in the DB except the songs are marked unavailable so they do not appear in the collection, so even if I fixed the bug the duplicates can reappear when you organize, so you need to clear all the duplicates in the database. The easiest is just to clear all unavailable songs, which are not useful anyway unless you actually have a path/disk that is currently unavailable and you plan to restore the same songs on the same paths. Make a copy of ~/.local/share/strawberry/strawberry/strawberry.db just in case. You can list the unavailable song with: If the songs listed there are safe to remove from the database, you can delete all unavailable songs with the following SQL queries: Recreate FTS table: |
|
That looks like it fixed it! Awesome, thank you very much! That problem makes sense, as my typical "workflow" was to delete the folder from the filesystem via a file browser, not from Strawberry. I had an enormous amount of "Unavailable" tracks in there. The "Recreate FTS table" SQL you provided was slightly off with a typo (mostly commenting this in case anyone comes across this and is trying to copy the fix). The SQL I used was: Also I've used Terminator for my emulator; will make sure I get newline working before future bug reports. |
|
I've just run into this issue again with Strawberry 1.1.1. First time hitting this issue and been using it since release. Not sure how much this helps, but checking the songs database shows 2 records, neither are "unavailable", and both point to the same file (I can play either one from the GUI). Same thing for track 2.
Here's regular log
For some reason I still can't get line breaks to work right in copying terminal entries, so here's a screenshot.
I was able to fix it (after taking those screenshots) by removing the album from the folder, deleting all "unavailable" songs from the DB (they showed up as unavailable after removing it) and then re-adding it. Now it's fine, but something still caused it to duplicate at one point. |
|
I to have the similar issue on ubuntu 24.04 STD repo release. Even when I do delete the DB, remove the source, and re add it, all songs are duplicated in the collection tree, This goes for all medias. (flack, m4a mostly)
Update: Installed from your stable PPA, ( |
This appears to be the same error as seen in issue 902, but that one's closed and I have a lot more details, so I opened this new ticket. If you'd prefer to re-open that issue and have me move this information in, let me know.
-In short: When I hit "move to collection" some tracks appear duplicated in the "Collection" tab. Goes away after I "organize" the album.
I made a youtube video showing the error in realtime if that's easier.
https://www.youtube.com/watch?v=CQlU7elMxTE
Details:
-Fully updated Arch Linux
-Strawberry 1.0.22 (although it's been happening for a while for me, last few versions)
-Happens with .opus and .ogg files at minimum, I believe it's happened with MP3 in the past as well
-If it happens to one track, will happen to all subsequent tracks in the album
-Anecdotally seems to usually happen starting at track 10 or 11. Sometimes later,
but don't believe I've ever seen it earlier than track 10, making me think something about the double digit renaming causes it.-Happens almost every album for me, so I'm guessing it's related to something in my workflow/auto track renaming.
-Hitting "organize" will usually fix it, but not always. I've even seen it duplicate the files again, causing 4 instances of the same track, but that is rarer and I cannot consistently reproduce it.
The text was updated successfully, but these errors were encountered: