Bug 3212 - List a count of the number of songs contained in each artist/album/genre when browsing or searching.
: List a count of the number of songs contained in each artist/album/genre when...
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Skins
: 6.5b1
: PC Debian Linux
: -- enhancement with 1 vote (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-27 11:59 UTC by Ted Cabeen
Modified: 2011-11-06 23:24 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ted Cabeen 2006-03-27 11:59:09 UTC
When browsing by artist, album or genre, it would be really nice to get the number of songs that there are for that particular item listed after the item.  Looking at the skin documentation, it looks like this isn't a supported field right now, so it would need to be added to the template variables and then added by skin writers.

It would also be nice to get a similar count for search results as well when a search matches an artist or album.
Comment 1 KDF 2006-03-27 13:21:17 UTC
some background info:

olson skin used to have this. it was ungodly slow to when gathering that extra info and went unused by anyone.  deleted from included skins some time ago. 

currently, many users are even removing the stats at the top of the home page due to complaints that just the one set of numbers is too slow.
Comment 2 Ted Cabeen 2006-03-27 13:26:14 UTC
Hmmm.  Interesting.  Doing it solely with skin operations would be tough.  I wonder if it would be faster if done in the backend.  Perhaps the data could only be provided when browsing, and not when searching?  Then the counts could be generated during a rescan and simply stored in the DB.
Comment 3 Blackketter Dean 2006-03-27 14:13:41 UTC
Subject: Re:  List a count of the number of songs contained in each artist/album/genre when browsing or searching.

That's good thinking.  For the 6.5 release we'll be moving to a MySQL  
backend that should be able to generate these stats much more  
efficiently and we may be able to re-enable the display.

Comment 4 KDF 2006-03-27 14:34:47 UTC
having it done by the split-scanner would help, since then we remove the pain and suffering caused by rescans (if the song  count for each artist, album, and genre is to be live, accurate, yet retrieved quickly...constant, low-grade, scanning is probably the only way)
Comment 5 Jim McAtee 2006-04-03 17:29:18 UTC
This information should be kept in the database for both artists (contributors), and for albums, as it shouldn't need to be generated dynamically.  I don't see a reason to constantly be scanning the library to keep the data accurate.  Any time a SlimServer process adds or removes a track, it should adjust the contributor and album counts.  This might be as simple as incrementing or decrementing a value in a column, or it could be done with a query that is run to update these counts (good candidate for using a trigger in MySQL) whenever a track is added, deleted, or updated.  In addition to track counts, keep album counts for artists/contributors and also keep total music duration.  For albums, keep a track count and duration.
Comment 6 Blackketter Dean 2006-04-22 19:50:27 UTC
hopefully we can turn this back on under mysql.  
Comment 7 Ted Cabeen 2006-04-24 10:25:13 UTC
If the data is generated, it would also be nice to be able to refine searches with it.  For example, excluding artists or albums from the display if they have less than 10 songs in the DB.
Comment 8 Dan Sully 2006-06-13 00:21:14 UTC
 6.5 is feature complete - pushing back
Comment 9 Alan Young 2011-11-06 23:24:46 UTC
Unassigned bugs cannot have a priority.