My guess is no major overhaul will be done to the system to fix the many
systemic issues, but if there was going to be such an attempt, it would
be wise to rethink servers whole approach, which is completely bizarre
and odd and not similar to any other software.
For instance, tags have albumartists and artists, there is no tag
trackartist, it shouldn't be invented as a db kludge to serve supposed
database needs. That shouldn't exist in server. The mere presence of
an albumartist tag shouldn't mean something is a comp or not, and
shouldn't mask files with which it has a string conflict for naming
Queries should ignore comp status altogether unless comp status is the
point of the query, (or at least part of the explicit overall point)
Perhaps most importantly, the whole browsing system is whacky and it
shouldn't be home > artists or home > albums or home > genres or
whatever, with limitations and so on for each. For instance, art should
be a toggle u can turn off or on from any browsing mode. U should be
able to name any results set u define, and create or delete any mode or
breadcrumb like list, and define it as deep as u like. U should be able
to include, or suppress, artists from comps in a given result set.
So I should be able to create a view called G1 and G2 just as two
example. G1 would be everything listed by Genre, then albumartists. G2
would be Comps, then genre. For these or others art could be toggled on
or off. Now imagine naming other views, and using years, composers,
artists, genres, etc, in whatever combo u want, as deep as u want, with
or without art.
So much of what is whacky in server is bc of legacy thinking, instead of
a fresh, common sense approach that would be much more intuitive and
also make more sense under the hood of server, making scans and queries
faster and more reliable.
using: win7 64 + lms 7.9 & duet & ipads w/the logitech app, and ipeng
on an ipod
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