chaug wrote: > > As regards the first point, I would like to understand what the root of > the problem is. Unfortunately, I have not the slightest clue. > It's probably easiest if you shutdown LMS and send me a zip with the library.db and persist.db files from your setup, you will find them in the LMS cache directory. This way it's possible for me to look at your database and see if I can see what's going on.
Alternatively, you could install the free "Database Query" plugin and run its "TrackStat inconsistency/problems" report and post the result. I'm just a bit afraid that it can cause more problems, because it can take a while to run and I know some user managed to corrupt their whole LMS database by aborting it in the middle of the run. If you try it, please make sure you have shutdown LMS and taken a copy of the library.db and persist.db files before, so you can restore them if something goes wrong. chaug wrote: > > As regards the second point, I can at least make a suggestion for an > alternative way of getting rid of the duplicates: I guess I need to find > a way to merge (rather than delete) the remaining duplicates in my > backup file, i.e. to tell Excel that it should keep the latest "played" > date, the highest "rating", and add up all the playcounts, or something > like that. Or can Trackstat do that? > The restore operation itself will never remove data. Currently the restore operation always overwrites the information, I'll consider adding a features in the future that can pick the entry with latest played date, highest rating, but it will probably not be added in the next couple of weeks. Also, please note that the TrackStat backup entries contains two type of elements: - <track> : Which represent the current play count, added time, rating - <historyentry> : Which represent all previous times when a track has changed rating or been played The <track> entry should have a single occurrence for each track. The <historyentry> should have an occurrence for each time a track has been played and it's normal that a track have multiple <historyentry> elements but they should have different values in their <played> or <rating> sub elements. It's possible to disable the history logging which cause the historyentry elements if you like, this is done through the "History" option in TrackStat setting page. Disabling it won't delete the history, but you can clear all TrackStat data and restore the backup and then the restore process should only restore the <track> elements and not the <historyentry> elements from the backup file. chaug wrote: > > P.S. One quick comment on the "'Issues with duplicate musicbrainz tags' > (http://wiki.slimdevices.com/index.php/TrackStat_plugin#Issues_with_duplicate_musicbrainz_tags)": > why is this an issue anyway? As far as I understood things, the > Musicbrainz policy is that "duplicate" IDs will only be given to > identical -recordings-. Which makes sense, because it simply is a > duplicate and I thought the whole point of enabling Musicbraniz tags in > Trackstat was that it will make Trackstat recognize these duplicates as > such and treat the same song as the same, even when it exists in two > files, e.g. one on the original album, and another one in some > compilation so that if I rate the track on the original album, the same > rating will be applied to the same song in the compilation. I'd consider > this a feature, not a bug, as they say. > It's a feature on musicbrainz side and it's the right way for them to handle it. The problem for TrackStat is that it assumed that it would identify a track uniquely (which it did a couple of years ago), but TrackStat can't presume musicbrainz tags exists since only some users have musicbrainz tags, so TrackStat database is based on the file path and it just use musicbrainz tags (if they exist). Due to this TrackStat will have two entries if you have two tracks in your library that represents the same recording. Normally this wouldn't be a problem but due to how TrackStat refresh operation is implemented the tracks with same musicbrainz id will be duplicated each time the TrackStat refresh operation runs. It would be possible to fix this but it would significantly increase the scanning time so I've avoided it so far. Erland Isaksson ('My homepage' (http://erland.isaksson.info)) (Developer of 'many plugins/applets (both free and commercial)' (http://wiki.slimdevices.com/index.php/User:Erland). If you like to encourage future presence on this forum and/or third party plugin/applet development, 'consider purchasing some plugins' (http://license.isaksson.info)) *Interested in the future of music streaming ? 'ickStream - A world of music at your fingertips' (http://forums.slimdevices.com/showthread.php?98467-Pre-Announcement-ickStream&p=743516)*. ------------------------------------------------------------------------ erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=102245 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
