If you have a large collection of tracks displayed or a large number displayed due a filter and select 'Edit Track Details' it may take a little time for the dialog to appear - if a track completes while that's about to happen the last played time of that track is not updated. I'd expect the track info update to be queued until amarok is not quite so busy! Reproducible: Always
And why is this a bug? The process can only display what is available at the time you make the request, if the data changed after that request I don't see how it could update it, as it probably already loaded the data in the cache. Reload the dialog and the data should also be updated. That is pretty much valid for all similar requests, e.g. if you make a filter in Dolphin and there are changes happening after the filter request was sent, it will not be taken into account. We would need to add a refresh button to the dialog, which is an unnecessary complexity to add, as this is really a corner-case and would bloat the UI
Sorry my report seems to be unclear. The bug is seen when you close the dialog with lots of tracks and *then* open the edit track details for the track, which completed whilst amarok was assembling the data for the display of the previous dialog, then you will see that the last played time has still not been updated. So: - track 't1' playing - open 'edit track details' dialog with lots of tracks (which may or may not include track 't1'), before that dialog appears, track 't1' finishes - close dialog - open 'edit track details' for track 't1' - track 't1's last played time has not been updated I guess that the failure to update in the db may happen if you're viewing the track details dialogs with a sensible number of tracks but it's harder to replicate!
oh, interesting. I didn't try yet, will need to find a minute to replicate this, but I am changing this back to bug instead of wishlist. Maybe the devs have an idea....
For me, this looks like an unimplemented feature. We have facilities to watch a track for changes, which would improve the behaviour robert reports, but it seems that TagDialog simply doesn't use it [I haven't checked the code]. If it is the case, adding such support could be a nice junior job. (care needs to be taken to unwatch (unsubscribe from) track in all possible cases, I suggest introducing a RAII class for that)
Though doesn't Matěj's conment apply to what Miriam originally thought my bug report was saying. The problem (I think!) is that the last played time is never updated to reflect that particular listen to the track which finishes when the dialog is being prepared.
(In reply to comment #5) > Though doesn't Matěj's conment apply to what Miriam originally thought my > bug report was saying. The problem (I think!) is that the last played time > is never updated to reflect that particular listen to the track which > finishes when the dialog is being prepared. I don't understand you - do you mean the last played track is *never* updated, even if you close and reopen the dialog? I think the behaviour you describe is simply that values in the dialog are simply not updated if they change after the dialog has been created. As I said above, it would be possible to implement that. On the other hand, this would be tricky - for example when you are editing a title (of a song that just plays), then the track is updated in the background you do *not* want the title to be reset back! Therefore I assign a low priority because it would be quite a deal of for for a little gain.
Your first statement is correct, the last played time is never updated (if amarok is trying to create the 'edit tracks details' for maybe other tracks when that track finished) if you afterwards open the dialog for that recently completed track. I've just replicated the problem again, while a track was playing - Set the local collection filter to lastplay:>6m (that's just over 1000 tracks for me) - 10 seconds before the current playing track completes, right click collection for edit track details - track completes around the time the play moves to the next track in the play list - close edit track details dialog - open edit track details for the just played track and verify that the last played time is not today (which is wrong and is the bug) I guess the delay between when you start opening the first dialog (the one with lots of tracks!) to the end of the current track will depend upon the speed of your machine. I initially noticed the problem when I had no filter on the local collection and accidentally selected 'Edit track details'