and slowly the tide turns... :) this is what i was saying from the start. if we take a fresh approach and consider these higher level questions, we can come up with a better, more logical system based on common use scenarios than what we have now, both in terms of scanning, and presentation (UI). these aren't merely academic points, they would result in under the hood efficiencies, that would result in faster, more reliable scans, and faster more reliable queries, as well as more dynamic user made (and named) views that had no arbitrary restrictions based on the "home > whatever" structure server uses now.
it would be great if someone like Erland were still around, so we could fork 7.9.1 into a project that attempted to bring these changes about, without messing up those who have gotten used to how server currently is, and hopefully merge them eventually. first, its pretty obvious that everyone is going to have their own ideas about what is, and is not a comp. what is perfectly clear, is that currently server determines this in a rather arbitrary way, which might work for some, but should be opt in at best. implement Erlands patch, and make the default that only comp=1 tagged files will be seen as comps to server. comp status is merely another file property, like an album tag, or title tag. second, comps shouldn't exist in server as a special kinda separate category. its a property of a file, like any other file property. it may, like albumartist tags, impact on grouping tracks together, but its not more important than another tag. it might also be useful in certain queries, like those that want to include, or exclude comps in a given queries results set. but its not some kind of actual thing, which is the way server treats it (and conflates it) now. finally, server should come with a few default "views" that the user can add to, delete from, and or edit. the views should all be custom nameable. the queries used to create the views should all be user definable, and include factors beyond tag values, such as folder location (like winamp smartviews, using infinite and/or statements). the behavior of the views, such as with or without artwork, suppressing or including artists from comps, etc, should again be up to the user, and switchable on the fly. i'm not fully fleshing it out here, but those would be some of the broad goals of a forked project. b/c of the current way server does queries, where it conflates for example comp status, comp names, and tag values, under the hood queries will be more efficient. i fully support adding the fields for classical, like "works" and so on, and managing classical libraries would be part of the goal. using: win7 64 + lms 7.9 & duet & ipads w/the logitech app, and ipeng on an ipod http://wiki.slimdevices.com/index.php/various_artists_logic & http://wiki.slimdevices.com/index.php/compilations ------------------------------------------------------------------------ BJW's Profile: http://forums.slimdevices.com/member.php?userid=58242 View this thread: http://forums.slimdevices.com/showthread.php?t=106970 _______________________________________________ ripping mailing list ripping@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/ripping
