-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
library.timesplayed
lost for entire database after upgrade
#12046
Comments
Can't check atm, but I saw 'Played' being checked for quite a few tracks right after start a few months back (could have been tracks played in the previous session). |
I doubt it. I think that could probably explained by mixxx crashing on shutdown before it could run the update query that resets the played status. The only additional context I have to share is that I recently deleted a crate and I used the "Join with previous" functionality of history crates. But I'm not sure whether either those caused the issue. |
this looks related to #10617 but the build contains the fix, so I'm unsure what caused this. |
also, make sure you have at least sqlite version 3.33 installed in order to test the same codepath as me. |
Confirmed, but didn't notice because I don't use this column. Updating |
Thank you for confirming. Neither do I really, so its not a big deal personally, but it should be in general. I'm pretty sure they're reset at some point, but I have not been able to determine/reproduce the circumstances. |
Could also have happened while testing the Qt6 builds for a while that always crashed when closing Mixxx. Currently Mixxx doesn't even start (#12014) , so I switched back to Qt5. |
I pretty certain that no Qt6 build has touched the database in question, so I doubt that's the culprit. |
@Swiftb0y Can we move this form the 2.4.1 milestone, because it is not reproducible? |
idk. It's definitely still happening, but I haven't been able to figure out the pattern. I'm conflicted on this since it's medium-severe case of data loss so I'd qualify it as a blocker, but on the other hand I'm not able to properly debug this... I'm not able to judge the severity of this bug and thus I don't know if I'm okay with releasing the next stable version with it... |
Can you remember if this has happened only once or more often? Is it a 2.4-beta issue or is it also happening with 2.3? |
definitely 2.4 and also definitely more than once. But only over the course of the first couple sessions. I need to find some more time to test if I can reproduce with old DB backups. |
Described in more detail with a way of reproducing it in #12046. Closing in favor of that. |
I think you've linked this issue itself |
Bug Description
I'm not sure in what commit exactly (I don't have the time to bisect right now), but somewhere the
timesplayed
for all tracks in my 6K track library have been nuked. Not a huge issue for me as I have backups as well, but not something that can stay in 2.4 in the release. I have confirmed that the issue affects the DB and not the hardware (asSELECT COUNT(*) FROM library where timesplayed > 0
is only the dozen or so played recently. I'm not sure what action caused, nor do I think I have the log from when this happened as I only realized it after the fact.Can anybody reproduce?
I'll tag this as critical for now as this counts as data loss imo.
Version
2.4-beta-163-g420b678c5e-modified (fix/gh11923)
OS
Fedora Linux 38
The text was updated successfully, but these errors were encountered: