Due to this bug https://bugs.kde.org/show_bug.cgi?id=298275 my collection keeps losing its stats. That's EXTREMELY annoying as the stats are the reason I use amarok. Also, it makes certain types of playlists not work correctly. One thing that has saved my sanity with all these collection losses is that a while back you guys implemented saving the stats to the file. So the auto-score, five star score, and number of plays saves to the file. Otherwise I would have stopped using amarok a long time ago as I like to make playlists based on songs I like - the ones with the highest star scores, plays, or auto-scores. So could you PLEASE PLEASE PLEASE also make it save the first and last played stats to the files? I'd love to make auto-playlists based on those stats. Also, the way the auto-playlists work if I put it to pick songs that haven't been played in X days, the songs that have been played never don't show up. So it sucks that the last played date keeps getting lost. Reproducible: Always Steps to Reproduce: 1. Play a song 2. When stats get written to the file, it also writes the first and last played stats to the file 3. I am happy because when my collection dies I don't lose the first/last played stats Actual Results: Nothing yet since this is a feature request Expected Results: Save this metadata to the file This should be trivial considering the other stats are already saved to the file. Please implement this! It would also be great for if I had to reinstall or move to another distro - I wouldn't lose the first/last played data for the file. Thanks!
Hi, this all boils down to support first/last played fields in various tag readers/writers in shared/tag_helpers, as TagLib doesn't provide universal methods to read/write these fields. The tag writers there are: APE, ASF, ID3v2, MP4, VorbisComment. You can help this feature being implemented by looking up standards for above tag formats and pointing us to fields that can be used to store the first/last played information. Also note that bug 298275 has been fixed in Amarok 2.6, so this is not that urgent now.
(In reply to comment #1) > You can help this feature being implemented by looking up standards for > above tag formats and pointing us to fields that can be used to store the > first/last played information. Waiting for the information. BTW, this is not related to Statistics Synchronization framework code-wise, rather with tag reading support. (perhaps we should have a category for general tag reading and writing? this is shared by all collections)
There are no available tags for id3v2 and vorbiscomment at least. You could define your own special tags for those but I haven't started down that path yet. I kind of like keeping to the standards. However, if enough users want this, then it's an easy thing to do. Might even be a junior job. I propose to vote for this feature if you like it.
(In reply to comment #3) > There are no available tags for id3v2 and vorbiscomment at least. > You could define your own special tags for those but I haven't started down > that path yet. I kind of like keeping to the standards. > > However, if enough users want this, then it's an easy thing to do. Might > even be a junior job. > I propose to vote for this feature if you like it. how would I do that? (vote)
The "vote" option is right above the "Target Milestone" filed, click on it. You can give up to 20 voting points for one project, but you have only 100 points for voting in total.
Below the "importance" fields (on top of this page) there is a small "vote" link. Click on that. You can give more than one point for this bug and others.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Changing status, sorry, this slipped from attention