[mythtv] patch: playlist updates
ijr at po.cwru.edu
Mon Feb 24 18:07:27 EST 2003
On Monday 24 February 2003 05:41 pm, Andy Davidoff wrote:
> #if Isaac Richards /* Feb 24, 11:31 */
> > Existing playlists are just what's been saved when the user exits
> > mythmusic -- they're easily recreatable. I don't really care if the
> > single automatically generated playlist in the db gets blown away.
> fixschema was for mdz, not you. :-)
He just said that if it were to be done that way, that'd be how to do it.
> > Other stuff: The default playlist is _always_ going to get saved and
> > loaded at the load/exit of mythmusic, so there's really no need for a
> > specific setting in the db for it. It should be host specific, though,
> > but that can be accomplished in the same manner that the rest of the
> > settings are, just a hostname field in the musicplaylist table.
> #endif /* ijr at po.cwru.edu */
> Someone requested per-host playlists and a toggle for "exporting" such
> playlists to global scope -- hence the hostname field in musicplaylist.
I don't see the hostname field being used at all in the code, so...
> The specific setting in the DB lets us remember which playlist a host was
> last listening to so that it loads that playlist when starting mythmusic.
> This is almost verbatim what you wrote above, but it uses the existing
> per-host/global settings framework, which is an exactly identical model.
The default playlist isn't a discrete playlist. It's a special case, it
doesn't need a setting to name it. It'll always be 'default' or whatnot.
It'll always get saved on exit and loaded on startup. Doesn't matter if it's
an exact duplicate of another playlist.
In fact, how would you handle playlists containing other playlists with that
schema? I had just planned on making playlist ids negative ints inside the
existing list. So, a playlist of '64,23,-6,24' would be translated to 'song
#64, #23, playlist #6, song #24' on load.
More information about the mythtv-dev