-
-
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: Add last_played_at column #3140
Conversation
TODO: Store the time stamp in the database instead of the useless boolean flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. Some comments.
src/library/dao/trackdao.cpp
Outdated
|
||
bool setTrackArtist(const QSqlRecord& record, const int column, | ||
TrackPointer pTrack) { | ||
bool setTrackArtist(const QSqlRecord& record, const int column, TrackPointer pTrack) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accordeing to the iso cpp guide these functions should use a plain pointer because they do not store it.
Not sure if this is a topic for this PR but it pops up during the mass reformat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, unrelated
Because my patch relies on the history playlists, it's possible to delete a history playlist and the last-played time automatically updates. Is that possible with this approach? |
Yes: Rerun the migration query for all tracks in the playlist after it has been deleted. The last_played_at column is just a cached value. Even with the new indexes the migration might take a few seconds, it is a heavy-weight operation. The join required for the temporary view adds additional costs. Therefore I suggest to cache this value permanently in this new column instead of in a temporary view that needs to be recreated on startup. The play count is also affected by deleting history playlists and would need to be updated if you want to implement such a feature consistently. |
in my version, I hook in to the playlist deletion signals to trigger the updates to the table. This should be easy to reimplement here if you reference my code. This is a pretty important facet of this particular feature for me so I'd appreciate if it could be included. |
@daschuer I have force pushed after reverting all unintended changes. All additional changes will follow as separate commits. VSCode is configured to only reformat changed parts and works as expected. The reformatting has probably been caused by the pre-commit hook, because I usually review all changes before creating a commit. If the pre-commit hook complains then I simply stash all additional changes created by the hook without further review. Will keep an eye on this in the future. |
I have moved the creation of indexes into a separate schema migration step. Not only for playlists but also for crates. |
@ywwg Automatic updates implemented |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you.
QString::number(PlaylistDAO::PLHT_SET_LOG))); | ||
VERIFY_OR_DEBUG_ASSERT(!query.hasError()) { | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need also consider the played flag.
Maybe we can dispose it internally by comparing the current play count with the value the session starts. That sounds less redundant.
I did not have a look, but we have also a feature to join two set logs, the played flag needs to be considered than as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The played flag should not be a property of the (persistent) track object. The set of tracks that are considered as (manually) played during a session should be managed separately. The complicated and inconsistent logic in the PlayCounter
is already screaming out loud. I refuse to add more magic to it that fits some use cases but induces unexpected behavior for others. If the user decides to rewrite history they could be bothered with updating the played flag manually. It will be reset anyway at some time.
For my aoide view I don't have a played flag and already use the logic you proposed for an implicit played flag. This could be overridden with a session played flag, once Mixxx supports this concept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the played flag is a slightly different idea and should remain separate. (Also note that Played status is maintained across crashes so the user doesn't lose state :))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mangling the played flag as a column of the Track entity table was a bad idea. Instead the set of played tracks must be stored separately by introducing the concept of a Session entity. Out of scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some small nits and notes. thanks for doing this!
@@ -15,6 +15,11 @@ | |||
#include "mixer/playerinfo.h" | |||
#include "mixer/playermanager.h" | |||
|
|||
#if !defined(VERBOSE_DEBUG_LOG) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please don't invent a new log level. "debug" is our verbose level, just use that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need this to prevent log spam. DEBUG is currently used as INFO. Explained here #2782. Otherwise I would have to delete all those extra logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that we don't have a good story for Info vs Debug. But this feels like a one-off change that will increase tech debt. If you are going to do this, please create a bug and assign it to yourself to remove this special casing once we have better logging code.
When this is merged, we can implement proper waveform cache cleanup based on LRU |
How can we make progress here?? |
what's the sticking point for this? |
We need to verify if the merge history and updating of the played flag still works. This applies if the user restarts Mixxx during a gig for some reasons. |
build fails now:
|
Since #2670 is closed now, we need to add the column addition here. |
The play flag handling still works as expected and the code looks good so far. |
I can rework my change to go from this PR instead. I'd prefer to get this db change in now and do the UI in a separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, than LGTM.
Thanks for taking over! |
UI: #3457 |
I need this property to complete the aoide integration in #2282.
PlayCounter
After this permanent addition, #2670 should become much simpler. I have reused the database query for the migration.
Note: The first 2 commits contain a temporary, transient approach before I decided to make this property persistent. Included for the sake of completeness and to document the development process.