PDA

View Full Version : Browse Music Folders -- intentionally uglified for 6.1?



mkozlows
2005-07-12, 21:14
I just installed 6.1b2, and I'm not sure if this is a bug or a "feature": When you Browse Music Folder, and get to a level that shows music files, old SlimServer would show text like:

1. End of Summer - Capriccio from The End of Summer by Rorem, Ned

Which looked really nice, and had handy little hyperlinks for the album and the artist.

In 6.1b2, it shows just the flat filename:

01 End of Summer - Capriccio.wma

This is much, much less attractive, and I'm hoping it's not by design. Please tell me it's a bug and will be fixed!

mherger
2005-07-12, 22:50
> This is much, much less attractive, and I'm hoping it's not by design.

It's by design. And attractiveness is a question of personal preference:
too many users were complaining about bad performance in Browse Music
Folders. As this performance hit was due to the visually more attractive
presentation, that functionality was stripped down to greatly improve
performance.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

mkozlows
2005-07-13, 06:03
Oh, that's horrible. I've always used Browse Music Folders, but now it's so incredibly ugly (the .wma even appears on the Squeezebox itself!) that Browse Music Folders feels like a second-class way of using the system. I spent a lot of time entering metadata, and I don't want all that ignored just because I prefer a customized system of navigating to my music.

Performance is great and all, but if making it fast means making it bad, then don't.

mherger
2005-07-13, 06:20
> Oh, that's horrible. I've always used Browse Music Folders, but now
> it's so incredibly ugly (the .wma even appears on the Squeezebox
> itself!) that Browse Music Folders feels like a second-class way of
> using the system. I spent a lot of time entering metadata, and I don't
> want all that ignored just because I prefer a customized system of
> navigating to my music.

But why don't you use the other browse modes? What's wrong with them?

> Performance is great and all, but if making it fast means making it
> bad, then don't.

Let's stick to ugly, not bad. But there's no need to argue here: those
with bigger collections prefer speed, others nice layout.

There was a poll about this, btw. Not a very popular one, but it was 1:7
for "keep it" vs. "no metadata".

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

mkozlows
2005-07-13, 06:45
>
But why don't you use the other browse modes? What's wrong with them?


Well, I might HAVE to, but they don't work as nicely. My wife and I
keep our music in separate folders and there's no "Whose music is
this?" browse mode...



There was a poll about this, btw. Not a very popular one, but it was 1:7
for "keep it" vs. "no metadata".


I submit that the people who follow dev polls like that are those who have a problem they want fixed, and that when this goes to the release version, many more people will want the good behavior than the fast behavior. (But surely there's a way to use the metadata and still boost performance...)

Philip Meyer
2005-07-13, 14:53
What about adding a preference option in Server Settings -> Performance, or a Browse Music Folder format option in Server Settings -> Formatting? Eg. allow a title format of "Raw filesystem".

I can see good reasons for both the old and new style of browsing the music folder.

In the new style, I think at least the known extension types can be stripped off for display. Eg, I have a symbolic links "Alex's Music" and "Phil's Music", which actually appear as "Alex's Music.lnk" and "Phil's Music.lnk" (shortcuts in Windows).

Phil

mherger
2005-07-13, 14:59
> In the new style, I think at least the known extension types can be
> stripped off for display. Eg, I have a symbolic links "Alex's Music"
> and "Phil's Music", which actually appear as "Alex's Music.lnk" and
> "Phil's Music.lnk" (shortcuts in Windows).

Do you know whether perl treats shortcuts on Windows like symlinks on
linux/unix? I opened a bug with a possible fix earlier today:
http://bugs.slimdevices.com/show_bug.cgi?id=1810

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

Philip Meyer
2005-07-13, 15:14
>Do you know whether perl treats shortcuts on Windows like symlinks on
>linux/unix? I opened a bug with a possible fix earlier today:
>http://bugs.slimdevices.com/show_bug.cgi?id=1810
>
Sorry, I don't know. But I would hedge a guess that they would not be treated like links in unix. Eg. in a cmd shell, I can't go to my root slimserver music folder and then CD "Phil's Music" or CD "Phil's Music.lnk".

Phil

mkozlows
2005-07-13, 15:27
What about adding a preference option in Server Settings -> Performance, or a Browse Music Folder format option in Server Settings -> Formatting? Eg. allow a title format of "Raw filesystem".

That would, of course, satisfy me, but probably not a great idea. Maintaining two separate codepaths would be a pain, and probably lead to even more subtle and irritating bugs later on.



I can see good reasons for both the old and new style of browsing the music folder.


The only reason I see for the bare filesystem view is speed, but it seems unlikely to me that you couldn't get the speed improvements with a better UI. It might be HARDER to do that way, but I really think it's worth the effort: Having your songs display inconsistently depending on how you browsed to them is an ugly bit of UI that violates user expectations and is uglier to boot.


In the new style, I think at least the known extension types can be stripped off for display. Eg, I have a symbolic links "Alex's Music" and "Phil's Music", which actually appear as "Alex's Music.lnk" and "Phil's Music.lnk" (shortcuts in Windows).

Taking the ".wma" off the files would be better than nothing, but it's still suboptimal.

radish
2005-07-13, 17:04
The only reason I see for the bare filesystem view is speed, but it seems unlikely to me that you couldn't get the speed improvements with a better UI. It might be HARDER to do that way, but I really think it's worth the effort

Careful. You're getting very close to calling the (largely volunteer) developers lazy, which they patently are not. I'd take the time to read up on the prior discussion of this issue. From what I understand the slow down is ENTIRELY due to having to look up meta data for each file, so the only way to speed things up is to not do the lookup. Of course, as usual, if I'm wrong feel free to submit a patch :)



Having your songs display inconsistently depending on how you browsed to them is an ugly bit of UI that violates user expectations and is uglier to boot.


To be fair, you're browsing two seperate things. In one case you're browsing the database of known tracks, in the other you are (quite literally) browsing the music folder. One of the past problems with browse music folder was that it wouldn't pick up new files that weren't in the db yet, for obvious reasons. This is now fixed (at least I think it is) and I, for one, prefer it this way. When I resort to looking in the folder I want to see what is really there, not what's in the db. There are countless other ways to do that.

If I were you, I would focus on your key problem - that the existing By Artist, By Title, By Album, etc, don't fit your needs. Given that all meta data is now in a db it should be possible to allow users to define their own browse criteria. I have used a HTPC frontend app called Meedio which allows just that, and it's a truly excellent idea. By writing simple queries I can configure exactly how the songs should be arranged & filtered, and I can have as many different views as I like. I think something like that would be great in SlimServer, and should avoid the need for you (or 99% of other users) to go into Browse Folder at all.

mkozlows
2005-07-13, 17:29
Careful. You're getting very close to calling the (largely volunteer) developers lazy, which they patently are not.


I'm not calling anyone lazy. I'm saying that, yes, doing a more thorough implementation of a feature can be significantly more resource and time intensive than doing a fairly basic implementation, and it's not always worth it -- but in this case, I think it is worth it. (Yes, I'm highly biased, in that it's someone else's time and my usage that we're talking about, but I think this is more generally true.)



I'd take the time to read up on the prior discussion of this issue. From what I understand the slow down is ENTIRELY due to having to look up meta data for each file, so the only way to speed things up is to not do the lookup. Of course, as usual, if I'm wrong feel free to submit a patch :)


Yes, I see the smiley, but I do want to point out that I'm not writing as a developer here, I'm writing as somebody who's paid $500 for various Squeezeboxen and is seeing a useful feature that I depend upon being weakened.

(As a developer, I'd say: You've got a database, so this should be possible. If you create a special table to hold metadata when browsing folders, indexed on the folder name, just do one single query to retrieve all the metadata for all the files in that directory, and put it into a hash; then when looping over the items for display, pull the array of metadata out of the hash for the item you're displaying. If you have no hash, fall back to the generic file display. The hash lookup should have minimal performance impact, the single query per page load shouldn't be a major performance problem, and there's no loss of visibility, in terms of not seeing un-indexed files in the folder. But I have no idea how SlimServer is working underneath -- and no real time to find out -- so this may be impossible for a zillion reasons)


If I were you, I would focus on your key problem - that the existing By Artist, By Title, By Album, etc, don't fit your needs. Given that all meta data is now in a db it should be possible to allow users to define their own browse criteria.

I don't think that'd work, though. I don't have any metadata in the files listing whose music is whose -- that's just in the folder structure. Plus, I like to use conditional styles of browsing: For classical or pop music, I want Genre/Artist/Album, but for soundtracks, I want Genre/Album. I've got my folders set up that way, but I can't imagine how you'd special case a regular browse to treat some genres differently than others.

If I'd never had Browse Folder available, I'd probably have set things up differently so that the other browse modes would work (abuse the Genre tag to have "Pop: Me" and "Pop: Wife"; set the Artist on all soundtracks to "Original Soundtrack" so there's no artist browsing necessary for them), but I did have it, and it's nice, and I don't want to lose it.

JJZolx
2005-07-13, 17:58
I think you have a very valid point.

To segment different users' music by structuring it by folder makes a lot of sense.

/Music
../Bob
../Sue
../Jeff

In the current SlimServer, without individual user settings and music folders, that's probably the best approach. Then using Browse Music Folders is just about the only way to see the organization. In any other browse mode it all gets glommed together.

I'd say a system preference would be best. Or else go back to the prettified output. Just goes to show that there's very little that's obvious when it comes to changing the software's behavior. You're almost bound to cross someone up and mess with their normal way of doing things.

All the data that you see is coming from the database - Browse Music Folder is a sort of 'fake' file system view, so the change to using the old output probably isn't a major one.

Dan Sully
2005-07-13, 18:23
* JJZolx shaped the electrons to say...

>All the data that you see is coming from the database - Browse Music
>Folder is a sort of 'fake' file system view, so the change to using the
>old output probably isn't a major one.

It is actually - because then we have to start dealing with infoFormat, which
is _very heavyweight_.

I'm sorry, but we can't be everything to everyone. We already have too many
options and configurations. You are free to patch your own version, which I
realize isn't the best answer, but it's a lot more than most other vendors.

SlimServer has reached a point where it's quite good for 98% of the user base
- everything else starts to become feature creep. Why do we have xPL support?
I don't even know what that is.. but someone added it, and it's hard to
remove it now. I'm becoming very strict on what I let into the server at this
point. If it only benefits one user, it likely won't be added.

Jim - BMF is now much closer to being a real file system view - it's not fake
anymore. A readdir() is actually called at each level the items are displayed
at. Special handling is called for skipping container formats (CUE sheets),
and removing non-music/directory or playlist items from the view. See
Slim::Web::Pages::browsetree() if you're interested in the implementation.

A lot of people have been filing complaints over the past few days - "My
wingbat stopped working! My foozle isn't displayed properly!". I know we've
had some regressions in some areas - but we've had vast improvements in
others. SlimServer is now reaching a point where stability is the number one
issue. No crashers. All music is found. We still have a little ways to go.
Unicode support is *HARD* - cross platform, cross network shares, random user
data, character sets being changed out from underneath us.

Integration is also *HARD* - MusicMagic, iTunes, etc - again, cross platform
- there is different behavior between the Linux version of MMM and Windows,
especially regarding character sets. Then we have Patrick (Hi Patrick! :) who
is running SlimServer on a Linux box, pointing at an iTunes XML file that was
generated on his Windows box. No offense, but this just makes me want to tear
my hair out. What is the right behavior here? What is the right character
set? Is Samba working properly? Argh!

We're seeing a lot of "X Doesn't work on my system.", and we can't reproduce
X. It's a really hard thing to fix when you don't know what's wrong in the
first place. And then all of the above applies.

Michael - Going back to BMF and meta data display - Robert Moser will be
checking in a reworked infoFormat() routine after the 6.1 release - it's too
major of a change for 6.1 itself, but will hopefully address the performance
issues. At that point, we can consider adding an option.

To be honest, at this point, both myself and Vidur are completely exhausted.
We still have a lot of ideas though - and after 6.1 is released and branched,
we're going to update the software roadmap. There have been some large
architecture changes bandied around, including moving to MySQL to allow DB
concurrency, and using Apache as the 'server' - integrating into APR. This
would solve our "threaded/forking" problem. (Thanks for the idea, Robin).

One of the things we desperately need is a test suite / harness / framework.
Currently we have no way to check for regressions or bug fixes, other than
manually, which is error prone. It's on our todo list. Interested? Start
looking at Devel::Cover & WWW::Mechanize.

Also - because of the nature of this project - if you want to fix the
behavior - you have the power to. I encourage you to get to know the code
base. Ask questions. Post patches. I'm going to try and schedule some time to
update the Wiki with more information. If you see tidbits of information on
this list - feel free to post to the wiki yourself.

Finally - I'm going to be out of town for the next few days - back on Monday
evening. I'll be writing code and checking email though, hopefully a cross
country plane trip will afford me some thinking time.

-D
--
Indifference will certainly be the downfall of mankind, but who cares?

radish
2005-07-13, 19:39
I don't think that'd work, though. I don't have any metadata in the files listing whose music is whose -- that's just in the folder structure. Plus, I like to use conditional styles of browsing: For classical or pop music, I want Genre/Artist/Album, but for soundtracks, I want Genre/Album. I've got my folders set up that way, but I can't imagine how you'd special case a regular browse to treat some genres differently than others.


In Meedio you're not stuck with the meta data in the ID3 tags, you can add whatever you want. You can even include expressions. So I have exactly what you want, and it works just fine. For example, I might have at the top level:

Browse Artist Albums
Browse Compilations

Artist albums goes Artist/Album Name/Track, Compilations go straight to Album Name. When you set up the views you tell it that if all the track artist fields are the same for a given album, it goes under Artist Albums, otherwise Compilations. Setting up views based on substrings of the file path would be trivial also, so you could divide up how you like. Its flexible and it allows you to set things up just how you like.

Philip Meyer
2005-07-14, 01:18
>From what I understand the
>slow down is ENTIRELY due to having to look up meta data for each file,
>so the only way to speed things up is to not do the lookup.
>
I got the impression it was scanning the files for the meta data. Isn't the meta data already available in the database? I would have thought that any scanned tags could be taken from there.

Where a new file has been added since the last rescan, then browse music folder could decide to either scan the files for tags (might as well add them to the DB at this point too), or display the filename if this is the speed issue.

Phil

Philip Meyer
2005-07-14, 01:28
>I got the impression it was scanning the files for the meta data.
Whoops, sorry - just saw Dan's reply. Ignore me!

Philip Meyer
2005-07-14, 01:43
I think what people are really asking for are two browse methods:

1. Directly access folders from the file system displaying the raw filenames for performance.
2. Browse the DB meta data by drilling down in the structure they are stored on the file system rather than by artist/album/genre, and display the chosen info format for music files.

Is the folder path for each music file stored in the database? If so perhaps a new "Browse by Heirarchy" item could be added? Is this possible through a pluggin, like the radio station plugins add browse methods?

There are some outstanding enhancement requests for grouping music collections, which might solve some peoples requirements for "Browse by Heirarchy", but perhaps not all.

For example, my wife is not very good with technical things. As 95% of the music in the DB is mine, she found BMF a bit easier to cope with, as she could easily find her 5% through BMF -> "Alex's Music". However, she hasn't set up tags on her music, so I think she will struggle a bit again now. Implementing the personal music collection enhancement requests would probably be a good solution for the majority that might find BMF to not do what they want.

Phil