Bug 276172

Summary: Tracks I've listened to eventually reappear as never played
Product: [Applications] amarok Reporter: robert marshall <robert>
Component: Playlists/Automated Playlist GeneratorAssignee: Amarok Developers <amarok-bugs-dist>
Status: RESOLVED FIXED    
Severity: major CC: kde-bugzilla, ralf-engels, stharward
Priority: NOR Keywords: release_blocker
Version: 2.4.1   
Target Milestone: 2.4.2   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In: 2.4.2
Sentry Crash Report:

Description robert marshall 2011-06-21 09:05:55 UTC 
Version:           2.4.1 (using KDE 4.6.2) 
OS:                Linux

I'm finding that tracks to which I have listened are reappearing in my AGP playlist which has a playcount = 0 condition set - and viewing the track details also confirms a last played of Never.
Once the track has played the track details are updated but eventually it will reappear in the AGP list with again a last played of Never. 
There are some tracks in the database for which there is a last played date (and to which I have listened).
When I'm playing these 'never' played tracks some of the longer tracks have a bookmark virtually at the end of the track - current one - bookmark at around 31:04 track length 31:17.
These tracks (which re-appear as Never) have been listened to pretty recently sometimes in the past week and since any update to amarok. I'm closing down amarok in a controlled manner - so it's not a losing data when crashing issue..

Reproducible: Sometimes



Expected Results:  
I'd expect the Last Played to only be never if I've never listened to the track
Comment 1 Benedikt Waldvogel 2011-06-25 14:18:21 UTC 
This also happens for me and I can finally reproduce it.

1) Rate a track. FMPS tag is store (see #274923)
2) Rescan the collection
3) Playcount of that track becomes 0 but rating and last_played stays the same.
Comment 2 Sven Krohlas 2011-06-25 14:23:57 UTC 
Confirmed by several reports. This is a dataloss bug. :(
Comment 3 Ralf Engels 2011-07-03 19:58:19 UTC 
Is that a "full rescan"?

The following is probably happening:
1. rating a track will write a POPM id3 file.
2. a POPM tag includes the rating and a playcount
3. a full rescan will read the tracks as present on the disk
4. As the track on the disk has a playcount at the time of rating, that one will be restored.

It's probably not what we want, but a full-rescan that only restores half of the tags is inconsistent.

Please advice how you want to have this fixed.
Comment 4 Benedikt Waldvogel 2011-07-03 21:57:02 UTC 
It’s a "full rescan", yes.
It doesn’t only affect MP3 files but FLAC files too. So not sure about the POPM id3 thing.

Furthermore, how does it help to restore the playcount of the time when the file was last rated? That information is probably very old and almost as wrong as playcount=0. IMO there’s even an advantage of having playcount=0 because you know that the information is not there. Wrong information is always worse than no information.
Comment 5 Ralf Engels 2011-07-04 15:42:48 UTC 
Actually the full rescan restores the information in the database from the files.
If there is a playcount information present, then it will be set.

However that shouldn't happen with FLAC files as the rating is not coupled there.

For now I would change it so that it uses the highest number from the file or database.
Comment 6 Ralf Engels 2011-07-04 19:02:51 UTC 
Git commit cf25d80897da1363ab63009fefb336351ca14dde by Ralf Engels.
Committed on 04/07/2011 at 17:46.
Pushed by rengels into branch 'master'.

Full scan should not decrease playcount

BUG:276172

M  +1    -2    src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp     

http://commits.kde.org/amarok/cf25d80897da1363ab63009fefb336351ca14dde