[mythtv] Proposed Change to MythMusic

Wed Jul 11 18:19:58 UTC 2007

On 7/11/07, Matt Jarvis <matt at mattandkirsty.org.uk> wrote:
> 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.
> >

So basically Smart Playlists.

> 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.
>

So basically Smart Playlists.

Of course, all this is dependent on proper tagging and full db support
for all the id3v2.x fields.

-- 
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette