[mythtv] Proposed Change to MythMusic

Wed Jul 11 18:02:25 UTC 2007

One thing which may be worth adding to this discussion, in the context
of how you best manage large collections of individual track based
music. I've worked in the background music industry for the last five
years or so, developing systems which the likes of Hyatt, Marriott,
McDonalds, W Hotels, River Island, Next and MANY other businesses use.
Our systems have always been based on the idea of creating profiles,
which are then fitted to time of day slots. A profile is a combination
of an era filter, a tempo filter, and a genre filter ( with percentage
control ) and then playlists are autogenerated based on these
parameters. If the issue is how you deal with HUGE collections of
individual tracks, this is how it's done in the commercial world.
Obviously you also have someone human checking to make sure everything
is in order, but in general the system works quite well, PROVIDING your
categorisation/metadata is correct to start with. Most of  the time
personally, I know I want something with a certain FEEL, but I'm not
really bothered about what actually comes on, providing it fits my mood
( and I can always skip a track ). In my experience these parameters
give you the ability to control that.

On Thu, 2007-07-12 at 01:38 +1000, Roo wrote:
> On 11/07/07, Justin Hornsby <justin.hornsby at gmail.com> wrote:
> > It's not even as if you *can* use a mouse with mythmusic yet - none of
> > those buttons do anything when clicked.
> >
> > The one thing I think everybody agrees with is that mythmusic needs to
> > be improved.  The thing is, I've yet to see any positive input on
> > precisely how to improve it.  There's little use saying "oh it needs
> > to be more like X with a bit of Y" since not everybody is familiar
> > with X or Y.
> >
> > What we really need are mockups, functional descriptions & the like.
> > Anything a developer can really work towards.
> 
> +1
> 
> 
> > As far as I know there aren't too many existing apps which make it
> > easy to deal with large collections of music other than the now
> > ubiquitous albumart browser - but then those don't suit people whose
> > music collections aren't based entirely around albums.
> 
> Rockbox has a nice feature for metadata browsing, it allows the user
> to customise the tagnavi.cfg. Admittedly I haven't tried using this
> customisation feature (yet) but  is worth looking at. Rockbox has even
> less resources (memory, raw mips, display size, buttons etc) than
> Mythtv and their users probably have as varied ideas as to what is
> "right" as Mythtv users do.
> 
> I have two observations to make with regard to browsing music
> collections and creating playlists.
> 
> A/
> There is no universal navigation structure for all types of music
> collection for all users. Some users have a huge singles collection,
> others have a majority of albums. Others, I imagine, have a collection
> that are top/bottom heavy if sorted alphabetically (every album ever
> releaed of their favourite artist).
> 
> I think the best design would allow the user to configure the browsing
> to best suit their collection.
> 
> B/
> Rockbox allows the user to define the tag navigation menu, it uses a
> config file that the users can define the navigation tree, label each
> node and specify the filter for each node.
> 
> Maybe Mythmusic could adapt this idea for it's tag navigation
> (collection browsing) as needed for playlist editing etc. The exact
> format of the config file would need to be decided but I guess it
> would be something like:
> 
> TagNavi.conf - Query Section (Optional)
> =======================
> If this section is not be present the query strings would be specified
> directly in the tree section.
> 
>  If present it would allow the user to name and specify a query string
> for retrieving data from the the DB.
> * The query could be a "raw" sql query, or,
> * The query could be an abstracted mythmusic query syntax, asimplified
> query syntax would allow the DB Schema to change without breaking
> existing query definitions.
> * Defined queries will be named to be used later in the tree section
> 
> 
> TagNavi.conf - Sort Section (Optional)
> ================
> If this section is not present an alternative method of defining the
> sorting would need to be provided.
> * Alternatives could be to have a bunch of canned sort order keywords
> defined in myth that are recognised in the TagNavi.conf - Tree
> section.
> * Another option is to roll the sorting into the Query, a la "SELECT
> FROM music_table WHERE (query_string) ORDER BY (sort_string)"
> 
> If this section is present it would allow the user to define various
> sort orderings to be applied to a selection.
> * Mythmusic could implement a simple sort order syntax, again this
> decouples the DB schema but does limit it's flexibilty.
> * Defined sort orders will be named to be used later in the
> TagNavi.conf - Tree Section.
> 
> 
> TagNavi.conf - Tree Section (The Workhorse)
> ==========================
> This section would be mandatory, it allows the user to define the tree
> structure for the UI to render when collection browsing etc.
> The user can define a tree that has arbitrary labels where each node
> optionally has a query and sort filter specified as well as a
> mandatory label. I imagine that hierarchial nodes would apply their
> queries hierarchially.
> For example
> 
> <queries>
>   <query label="highly_rated" sql="SELECT ...FROM... WHERE..."/>
>   <query label="recently_added" sql="SELECT ...FROM... WHERE..."/>
> </queries>
> 
> <sorting>
>   <sort label="rating_decending" sql="SELECT * FROM
> $query_results...GROUP...ORDER"/>
>   <sort label="recently_added" sql="SELECT * FROM
> $query_results...GROUP...ORDER"/>
> </sorting>
> 
> <tree>
>   <node label="My Group Label">
>     <node label="Highly Rated" query="highly_rated" sort="rating_decending"/>
>     <node label="Recently Added Songs" query="recently_added" sort="random"/>
>   </node>
> </tree>
> 
> 
> 
> TagNavi.conf - Location
> ==============
> If a tagnavi.conf style config file was used we could install a
> default (as included in the source tree) into /usr/local/share/mythv/
> and override it with a per user customised file if it exists in
> ~/.mythtv/. This would protect the users customisations safe from
> upgrades.
> 
> 
> Tree Caching
> ========
> It is possible to create and cache the tree data when doing the "Scan
> for music", I guess this would be more responsive instead of
> rebuilding it each time it is used. Although a tree node may be
> dynamic (like smart playlists) if the query string or sort order uses
> things like "Last Played", "Rating", "Recently Added" or "Play Count"
> etc., you wouldn't cache these results as they could change each run.
> 
> 
> Attached is the Rockbox tagnavi.config.
> 
> > Ok, so say we do away with the music transport buttons & make viewing
> > them (on top of the UI, say) optional so that those with mice /
> > touchscreens can use them.  That'd be a start.  We'd still need a
> > button to make the controls visible/invisible - or maybe a 'kiosk
> > mode' where they'd always be visible.  That'd mean we can devote much
> > more screen space to the playlist & music tree.
> 
> If the transport buttons are removed from the standard layout they
> could be displayed for a short time (1-5secs) over the top of the main
> window when the user activates them. If the playback is paused, sticky
> ffwd or rwd etc maybe the OSD can remain displayed. If the transport
> display is semitransparent it might look ok.
> 
> I agree, as far as the transport and the other buttons currently used.
> An alternative layout selected in mythmusic setup that switches
> between two options, mouse/touchscreen compatible on or off.
> * When mouse/touch screen compatibility is enabled either:
>  - the transport etc buttons are permanently shown (selects the
> mouse/touchscreen layout/mini theme)
> - a hot spot is enabled, perhaps the top edge of screen, that displays
> the transport etc buttons when the cursor is in the area. The
> transport display/overlay would be the same as when the remote is
> used. (no need for a mini theme)
> - a button is displayed, that when pressed displays the transport
> buttons. This is similar to the mouse over above, except the button is
> not hidden and requires a button press instead of mouse over.
> 
> Maybe we don't even need the setup option to select between the two
> modes. If you don't use the mouse then the transport buttons don't
> need to be displayed for the user to activate them, they just use the
> play, pause etc on their remotes. And the transport overlay will be
> displayed when an action is selected, and remain displayed while
> paused etc.
> 
> 
> > Anyway, I've got some ideas I'm going to get down in the form of
> > still-frame mockups.  It'll at least be a *start*, and maybe I can tie
> > still frames together in video form to give an overall impression of
> > how the new stuff will work in context.
> 
> I look forward to seeing your mockups and any others that may also be
> put forward for that matter.
> 
> 
> Anyway these are some less than fully formed ideas, just thought I
> would put them out there.
> 
> 
> Cheers,
> 
> Roo.
> 
> 
> ______________________________________________        
> This email has been scanned by Netintelligence        
> http://www.netintelligence.com/email
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
> 
> ______________________________________________        
> This email has been scanned by Netintelligence        
> http://www.netintelligence.com/email

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.