Bug 2808 - Provide function to browse the music folder without the performance impact of cache bypass
: Provide function to browse the music folder without the performance impact of...
Status: RESOLVED WORKSFORME
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: 6.2.2
: All All
: P2 normal with 8 votes (vote)
: Future
Assigned To: Unassigned bug - please assign me!
http://forums.slimdevices.com/showthr...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-10 18:39 UTC by Michael Wagner
Modified: 2008-06-03 15:16 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Wagner 2006-01-10 18:39:22 UTC
When a user sees the option Browse Music Folder, that seems like the most obvious thing to use to look for music. This is especially true when first playing with either the web or the device interface, or for people coming from other players where browsing the music folder is *the* way to find and play music. 

However, this feature is only implemented together with the (usually unintended) side effect of bypassing the database and cache speed improvements of the last several versions of the server.

This enhancement request asks

(a) for a high performance browse of the music folder using the path and other information from the database, cache, etc and

(b) that for as long as the Browse-Music-Folder-Slowly-Because-Scanning-Is-Even-Slower option needs to be kept available, it be more properly labelled as the slow route, put lower down in the default hierarchy of menus, etc. Hopefully this will not be for too much longer, as the performance issues are swatted away.

I believe this addresses a misunderstanding many new users have about the functioning of the program, one which causes much disappointment.

In the attached thread, see the postings from Rick's Cafe.
Comment 1 KDF 2006-01-10 22:58:52 UTC
ah, seems some discussions never die :)
http://forums.slimdevices.com/showthread.php?t=14689
Comment 2 Michael Wagner 2006-01-11 06:45:49 UTC
(In reply to comment #1)
> ah, seems some discussions never die :)

Yeah, but I couldn't find anyone who had actually filed an enhancement request for this ... of course, the web site kept going down last night, so I gave up in frustration at some point. If someone can point out a dup of this that I missed, I'll close it.

Comment 3 KDF 2006-01-11 08:14:29 UTC
It's not a dupe, but it was supposed to be a done issue. I just couldn't find the other threads that actually use the word "done".  no matter.  enhancement request is still here for the voting.
Comment 4 Richard Fraser 2006-01-12 08:42:36 UTC
(In reply to comment #3)
> It's not a dupe, but it was supposed to be a done issue. I just couldn't find
> the other threads that actually use the word "done".  no matter.  enhancement
> request is still here for the voting.
> 

this is my first involvement in a bug report .. so not entrely sure if what I am doing is correct.. I have for what it is worth voted for the enhancement... as I do like to use the BMF option as a way to look and keep track of my music.. I find this route more precise, as I simply have a better grasp of where my music is and what I want to listen to that way .. as opposed to doing general searches by genere etc...  as far as I am concerned any way of speeding up the BMF option seems to be to be a good thing.. or is there a reason not to have that added functionality???.. - KDF I have read the posting from June last year and not entirely sure if I followed all the details of it .. what was the result of the end of those discussions anyway?
Comment 5 KDF 2006-01-12 09:12:15 UTC
The result is what you see now. it is a raw filesystem listing, no metadata or database reading, all for speed. The only thing added in is a time check to trigger scans for new data.
Comment 6 Michael Wagner 2006-01-19 18:31:07 UTC
(In reply to comment #5)
> The result is what you see now. it is a raw filesystem listing, no metadata or
> database reading, all for speed. The only thing added in is a time check to
> trigger scans for new data.

It would be faster if it were cached. The "no metadata" version should be somewhere further down under "diagnostic aids" or something.
Comment 7 Blackketter Dean 2006-04-22 19:24:50 UTC
Since this is an enhancement request, it's going to need to be moved to 6.5.
Comment 8 Jeff Perkins 2006-05-14 17:40:39 UTC
I concur with this request, but wish to clarify.

I wish to access my music playlists thru Browse Music Folder, because I have 1000+ intelligently organized playlists in a hierarchical directory structure different than what is available thru SS album / artist / genre / playlist interface.

I just installed 6.2.2 production release (Mac OS-X installer date 4/25/06).

For my first time ever, Browse Music Folders is delightfully fast (still not as fast as Finder can list the same files - but MUCHHH faster than previous SS). Yeahh!!! Thanks! Keep bringing on the speed.

However, when I see a playlist (.m3u) thru the BMF interface (and I always see all of them reliably), SS will no longer Play the playlist from BMF unless the playlist has been loaded in the db - the playlist shows Empty (Play used to work under 6.1.1 on my XP machine, with no songs loaded in the music library db). To compound this problem, only occasionally does Rescan successfully load my playlists into the DB (Songs always load successfully - playlists only about 30% of times I've tried it since 6.2.2 install).

I am working thru the "bug" in 6.2.2 thru help ticket TMD:3194 with Daniel Evans - but we haven't solved anything yet. looks like bug 3201 might have been relevant - but it seems to have been reported as fixed prior to 6.2.2 production release.

I vote for this enhancement to 6.5 as a more robust, targeted, and permanent solution.

Best o fluck - and let me know how i can help. Thanks
Comment 9 Chris Owens 2008-06-03 14:40:01 UTC
Are there any current issues with browse music folder speed?  Much work has been done on this.  Please re-open if there's still an issue.
Comment 10 KDF 2008-06-03 15:16:17 UTC
assume chris meant to close this. marking as a worksforme as Chris seems to expect happiness with current performance.