the real fix should be made in the code, meaning under the hood of LMS. 
the problem is that LMS evolved over a long period of time when tagging
standards and so on were also evolving and being written.  now that all
the de facto standards are basically set in stone, its easier to fix.

i think the following things would fix LMS under the hood:

PHASE A:

1. make LMS VA detection optional.  meaning, in cases where tags aren't
explicit, and/or missing, let the user decide if LMS should "detect"
comp status or not.

http://bugs.slimdevices.com/show_bug.cgi?id=8324

such a toggle would make LMS behave strictly on what it does, or does
not, find in the tags/folders/filenames.  while the default should be
"on" i would turn it off and i think it would have performance benefits
as well as perceptional benefits, meaning there would be no "fog" as to
users guessing as to why something might be happening.  a user would
know that whatever LMS is showing them, its based strictly on what it
found, and nothing more; as opposed to additional logic, or what LMS is
interpreting something to mean.

it would be interesting to get this part done first as a standalone
piece, and just play with it for a while to see how it shakes out,
before attempting the next phase.  it looks like there is already a
patch submitted by Erland, although by now it may require some
tweaking?

PHASE B:

these steps are about disentangling comp status from list creation, and
also about properly separating comp status (under the hood), from how
comps are denoted (displayed).

2. there should be no "special category" for comps at all IN given
lists.  artist lists, be they artists, album artists, composers, some
combo of, or whatever they may be, should be based on their respective
tags (and/or folders/filenames) alone, meaning comp status or comp tags
would have *nothing* to do with making such lists.  if something is or
isn't a comp, it shouldn't matter when making those lists.

there is one exception:

3. you would have an actual list of only compilations, meaning those
things LMS has detected as comps, be it via its own guessing logic or
explicit tags.  this list could be "hardlinked" from within other lists,
if so desired.  (and that hardlink should be user nameable via an
option)

it would also be allowed to be referenced when making custom browse
modes, such as:

Compilations
Compilations > Artists
Years > Compilations > Artists

or whatever you can think of.

4. there should be a strict delineation between what word[s] LMS uses to
mean Compilations under the hood, and how compilations are
denoted/displayed in LMS.

right now, LMS conflates one setting to mean both things, with "Various
Artists" as the default string.  that causes problems right out of the
box.  in addition, it also uses the word "Compilations" to mean the same
thing as a browse mode.

that's all kind of ridiculous, in that its confusing and conflated.  i
would suggest that under the hood, LMS use a very unlikely to appear in
one's tags string to classify something as a comp to LMS.  something
like "VariCompLMS7"

i would then suggest that there be an option to let the user use
whatever string they want to denote such things in the display / UI,
with "Various Artists" being the default.  because to LMS those things
are really "VariCompLMS7" under the hood, there should no longer be the
"masking" issue as described in bug 9523.

this is further discussed in bug 15604 which imo was improperly closed:

http://bugs.slimdevices.com/show_bug.cgi?id=15604

i think there should also be discussion about why, or if, there should
be two terms used by default in LMS, namely "Compilations" and "Various
Artists" but that's the kind of thing that really could be addressed
later.

another thing that shouldn't get lost in the shuffle here, is that there
are lots of performance gains to be had in creating lists and browsing
and so on if comp status is no longer queried when making such lists, as
it wouldn't be most of the time.  the only time it would be, is in only
those specific browsing cases where comp status is specifically called
upon.  so for typical browsing cases, like:

Artist > Year > Album
or 
Genre > Artist

etc, you would have no concern if something was or wasn't a comp, and
that should improve performance.  (or so i think)

i think LMS has come a long way from say 10 years ago, when TPE2
couldn't even be recognized as meaning Album Artist, but i think the
changes have been done without addressing the root causes underneath,
more as workarounds rather than properly solving the issue.  if LMS is
still being developed, I'd love to see the above addressed.



Using:  Win7 64 and LMS 7.8 & Duet with ipads and 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=103701

_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to