Philip Meyer;423437 Wrote: > > >current bugs, of which there are many > Such as? There aren't many scanning bugs.
i named two i think are fairly serious, so you have your "such as." but there are others, bugzilla has them as you know, you can find them yourself. Philip Meyer;423437 Wrote: > > >full rescans should NOT be required to pick up tag changes. > I agree with you on that one though ;-) and it has festered for YEARS. Philip Meyer;423437 Wrote: > > >SC imo needs to rethink from scratch how it is going to catalogue and > >store ones collection in a DB. the logics are faulty, presumptuous, > >non-intuitive and cause problems, and don't respect the de facto > >marketplace standards that are in place and bigger than SC, right or > >wrong. > > > Rubbish. fantastic argument. i stand by what i said. there are BETTER ways for SC to do what it does, and there's no excuse for what it currently does to not at least be optional. how many times phil, do you need to see examples like this thread in the forums to sow you that people do NOT intuitively understand what SC is doing? i think that should be an OBVIOUS design goal. Philip Meyer;423437 Wrote: > > >issue: album artist tags should not have any impact on if something > is > >a comp or not. > > > The compilation tag definitively indicates whether an album is a > compilation or not. Why don't you use that? Then the album artist tag > is irrelevant to whether the album is a compilation or not. i turn that around on you... why not make VA detection optional, give no comp meaning one way or the other to albumartist tags, and then all a user would have to do is use comp=1 tags to let SC know something is a comp. thats one way SC could be informed thats flawless. directory location (user defined) is another. user submitted string recognition is another. all would be an improvement over the current system which is not compatible with many auto-taggers or varied user tagging styles. and i'm just saying make it OPTIONAL, it doesn't have to be removed. the fact that in some cases SC NEEDS comp=0 to work right is ridiculous. Philip Meyer;423437 Wrote: > > >issue: comps should not be FORCED to be "auto" detected. > > > Yes they should, for the majority of people will not have comp tags, > and would have a multiple single-song albums if they were not joined up > in some way. and again, i am saying not be FORCED, but ALLOWED to be OPTIONAL. let people choose! it should be a slam dunk. i would also point out that the whole browsing system is silly, home -> artists, home -> albums, etc... some allow art, some don't, etc... its stupid. there has to be smarter ways to handle these issues. Philip Meyer;423437 Wrote: > > >issue: no string in a tag, especially one as common as "Various > >Artists" should cause the music to NOT be listed. > > > True, but this is not a scanner issue, more of a browsing issue, but > mainly due to incomplete tagging (from SC's perspective). Remove the > albumartist="Various Artists", or add a compilation tag. and this is why you are in the first camp. and btw, i don't know that adding a comp tag over-rides that bug, (i haven't tested it). but again, i think SC should be more intuitive, and less demanding. i'm not saying garbage tagging should be allowed or accommodated, but just that i think better methods could be derived. Philip Meyer;423437 Wrote: > > >issue: regardless of how you feel about the above, its ridiculous to > >stick any and everything that SC determines is a comp into ONE HUGE > COMP > >category. > > > Not absolutely sure what you mean, but I'm guessing you mean that you > don't think that albums classified as compilations should not be listed > together under Browse Artists > Various Artists? Don't know why you > don't think that's a good idea. yes; i thought that was pretty clear? as to why... b/c putting hundreds to maybe thousands of albums, that SC thinks are comps, into one jumbled mammoth category is SILLY. i have many, many comps. i also have things SC would INCORRECTLY call comps IF i didn't use an album artist tag. the only way to get them where i want, is to use album artist tags. (and i NEVER plan to use artist sort tags, its simply too much trouble). i put TV stuff under "Soundtracks" movie stuff under "Original Soundtracks" multiple artist music cds under "Various Artists" and so on... this allows me to get things to file where i want them to be found. this of course means SC doesn't think i have any comps. i'm not sure where the would sort if i added a comp=1 tag, but again, seems like something that could be done better. meaning, why not let me choose what to sort by? Philip Meyer;423437 Wrote: > I'd prefer it if Various Artists was not listed in Browse Artists, and > instead there were a dedicated "Browse Compilations" menu, but it's > certainly not ridiculous. i'm not sure that would be much of an improvement and i still think its ridiculous. Philip Meyer;423437 Wrote: > > >issue: why do we need "track artists"? each track can have an album > >artist role, and an artist role, why do we also need a "track artist" > >role which is not a 1 to 1 match with an equivalent corresponding > tag? > > > Track Artists is an interesting one. I think it must have been added > as an attempt to make it easier to change settings for browsing the > music collection, but hasn't been fully implemented/maintained. I > believe the concept was that "Artists" always appear in Browse Artists > list, whereas "Track Artists" can be hidden from the list (if they are > guests on an album, only the album artist will be listed in the Browse > Artists list). However, compilation albums work differently, not sure > why. > > Largely irrelevant - it's how the SC internals work (although for some > reason they are displayed as "Artist:" or "Track Artist:" labels when > you browse song info). it ends up being confusing and probably unnecessary. what seems inarguable, is that its very unclear, and that gets back to the point that SC/slim has no documentation saying "given this set of data, this is the expected behavior" Philip Meyer;423437 Wrote: > > >i hope the new schema will bring new ways to approach how the DB / > >scanner / interface work, b/c i think there are ways to do everything > >that would make BOTH camps happy. > The new schema will not change any of that. Schema is just how stuff > is stored in the DB; changing the schema may help or hinder performance, > and maybe expand to allow more information to be stored. > The data that is currently stored in the current schema is fine; it has > the ability to represent a music collection how you want it. It's how > the data is collected (scanner) to be stored in the DB, or how it is > retrieved to be used by the app that you want to get changed. i don't want to split hairs on this, the point is its all connected, and changes to the way they do the schema MAY bring new ways of how its handled. one of the design goals i believe is to not require rescans just b/c options are changed. i think that alone would help make what i'm proposing more realizable. -- MrSinatra www.lion-radio.org using: sb2 & sbc (my home) / sbr (parent's home) - w/sc 7.3.3b - win xp pro sp3 ie8 - 3.2ghz / 2gig ram - 1tb wd usb2 raid1 - d-link dir-655 ------------------------------------------------------------------------ MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336 View this thread: http://forums.slimdevices.com/showthread.php?t=57922 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
