Skip to content
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

Closed
Swiftb0y opened this issue Sep 29, 2023 · 14 comments
Closed

library.timesplayed lost for entire database after upgrade #12046

Swiftb0y opened this issue Sep 29, 2023 · 14 comments

Comments

@Swiftb0y
Copy link
Member

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 (as SELECT 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

@ronso0
Copy link
Member

ronso0 commented Sep 29, 2023

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).
Couldn't reproduce again, though maybe it's related.

@Swiftb0y
Copy link
Member Author

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.

@Swiftb0y
Copy link
Member Author

this looks related to #10617 but the build contains the fix, so I'm unsure what caused this.

@Swiftb0y
Copy link
Member Author

also, make sure you have at least sqlite version 3.33 installed in order to test the same codepath as me.

@uklotzde
Copy link
Contributor

Confirmed, but didn't notice because I don't use this column. Updating timesplayed using the SQL statement increases the counts considerably. The values are either not updated as expected or are reset at some point.

@Swiftb0y
Copy link
Member Author

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.

@Swiftb0y Swiftb0y added this to the 2.4.0 milestone Sep 30, 2023
@uklotzde
Copy link
Contributor

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.

@Swiftb0y
Copy link
Member Author

I pretty certain that no Qt6 build has touched the database in question, so I doubt that's the culprit.

@daschuer
Copy link
Member

@Swiftb0y Can we move this form the 2.4.1 milestone, because it is not reproducible?

@Swiftb0y
Copy link
Member Author

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...

@daschuer
Copy link
Member

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?

@Swiftb0y
Copy link
Member Author

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.

@Swiftb0y
Copy link
Member Author

Swiftb0y commented Nov 4, 2023

Described in more detail with a way of reproducing it in #12046. Closing in favor of that.

@Swiftb0y Swiftb0y closed this as completed Nov 4, 2023
@Swiftb0y Swiftb0y reopened this Nov 4, 2023
@Swiftb0y Swiftb0y closed this as not planned Won't fix, can't repro, duplicate, stale Nov 4, 2023
@fwcd
Copy link
Member

fwcd commented Nov 4, 2023

I think you've linked this issue itself

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants