ceejay Wrote: > ... > > > (4) it all has to go in the database somewhere, you risk making lots of > empty columns which hardly anyone is using > > (5) you need UI code to do something with it which needs to be written > and maintained > > Ceejay
A couple of comments based on my current understanding of how Slimserver stores and uses tag values. That understanding is based on experimenting with Slimserver and with reading the source code. On (4): Putting each tag into a separate column is not the only way to organize things. I don't think it is the right way if you want to broiwse and search on all the tags the user has placed in his music files. The straightforward way to support a wide variety of tags is to store the tag values in a single track_tag table with a simple layout: a primary key column, a foreign key reference back to the table that stores track information, the name of a tag and the value of that tag for the track referenced. When Slimserver reads a music file for a track, it can collect all the tracks and add them to the track_tag table. At that time, ID3 tag names can be replaced by corresponding English names. When there are conflicts between ID3v1, ID3v2 , and OGG Vorbis tags, Slimserver can use the same sort of logic it uses now. I'd guess that Slimserver probably replaces ID3v1 tags by equivalent ID3v2 tags when both are present and replaces either IDv1 or IDv2 tags by Ogg Vorbis tags when there is a conflict. (Would there ever be a conflict between ID3v1 and Ogg Vorbis.) This sort of approach allows for browsing or searching on whatever tags the user has placed in the files. It also allows for a very database driven UI implemented by a pretty small amount of code. What's wrong with this approach? Why would we not do things this way? The current database has one or more tables for each of the tags that are central to Slimserver's operation: track, album and artist and genre. Tags are used to define entities such as Artist, Genre and most importantly, albums. So the most common tags are treated in a special way. Changing things might be too much to ask right now. Some additional tags are stored in the artist table (Composer, Band, Conductor) and at present, they can be added to the Artist value and browsed or searched as additional artist values. On (5): As I stated above, if the database stores all tag values for a track in a single track_tag table, the UI code can be pretty easy to test and maintain and not large in size. I backed off on asking for a really general treatment of tags right now after getting a somewhat negative reaction for you and from Pat Farrell and after looking at the current database definitions. The enhancement requests you made ask for changes to function and do not specify anything about implementation. I do not want to lose sight of the possibility of quite general handling of tags in Slimserver though. Bill -- Listener ------------------------------------------------------------------------ Listener's Profile: http://forums.slimdevices.com/member.php?userid=2508 View this thread: http://forums.slimdevices.com/showthread.php?t=18946 _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
