PasTim wrote: > I would really appreciate it if someone could point me to a description > of how the content and function of the three "tracks_...." sqlite > database tables, and their relationship to custom scan. > > The wiki at http://wiki.slimdevices.com/index.php/TrackStat_plugin > briefly describes tracks_history and tracks_statistics, but I believe > the description may be out of date, and tracks_persistent is not > mentioned at all. It is also not clear to me what happens to ratings > when custom_scan is run with the ratings module. > > If possible I'd also like some clue as to how the ratings in these > tables relates to the LMS ratings. > The table ownerships: * tracks_persistent: Owned by SBS/LMS * track_statistics: Owned by TrackStat * customscan_track_attributes: Owned by Custom Scan
The relations I try to use are: * tracks_persistent.url=tracks.url * track_statistics.url=tracks.url * customscan_track_attributes.track=tracks.id * customscan_album_attributes.album=albums.id * customscan_contributor_attributes.contributor=contributors.id In the Custom Scan tables, there are also an unoptimized relation: * customscan_track_attributes.url=tracks.url (But this shouldn't be used unless you have a very specific need where the track/id relation mentioned above doesn't work) Then there are some shortcuts which are available if you are using SBS 7.6 or later: * tracks_persistent.urlmd5=tracks.urlmd5 (Reason for this relation is that it uses shorter texts than the *.url relation and due to this can be faster if you have performance issues, but there are bugs related to it, for example for cue sheets it currently doesn't work correctly) And another shortcut if you are using TrackStat 3.0 or later: * tracks_statistics.urlmd5=tracks.urlmd5 (Reason for this relation is also performance issues, it's only available in TrackStat 3.0 and later versions, main reason to use it is when you join both track_statistics, tracks and tracks_persistent in a single query) Regarding ratings they are stored as follows: * track_statistics.rating: TrackStat rating storage, should newer be overwritten by incorrect logic in SBS/LMS scanner * tracks_persistent.rating: SBS/LMS scanner rating, this is always overwritten with RATING tags in the music files or iTunes library (if using iTunes scanner). Not that this will ALWAYS be overwritten with information the scanner finds, so if you change the rating through TrackStat and then do a rescan it will be overwritten by the scanner. The track_statistics.rating will survive this and TrackStat provided iTunes importer will have some smart logic that only overwrite if the rating in iTunes is later then the one in SBS/LMS. * customscan_track_attributes.value: When customscan_track_attributes.attr='RATING' the value colum will contain the value scanned by the Custom Scan "Rating Tag" scanning module. However, note that "Rating Tag" module will also write to the above tables if you have enabled the "Write ratings to Squeezebox Server" option in the Rating Tag settings page. Most of the menus and playlists I've made and provided templates for uses the track_statistics.rating value because that's the only one I trust. The tracks_persistent table will survive a full rescan, it's problem is that it will always be overwritten with what the scanner finds in RATING tags, so basically it can be used in two scenarios: * If your master rating storage is RATING tags and you always change the tag when you change a rating * If you are sure you don't have any RATING tags in your music file and you aren't using the iTunes integration when scanning. When changing a rating with TrackStat it will be written to both track_statistics.rating and tracks_persistent.rating. ------------------------------------------------------------------------ erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=49483 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
