[mythtv] patch: playlist updates

[Isaac Richards]

On Monday 24 February 2003 09:47 pm, Andy Davidoff wrote:
> #if Isaac Richards /* Feb 24, 20:31 */
>
> > If hostname is null, the playlist is global.  If it's non-null, it's
> > local to the host.  Just like the existing settings table.  The default
> > playlist will always be local to each machine, since it's just a copy of
> > the current playlist and not directly user editable.
>
> This is the first I've heard of this "copy" operation; I assume you mean
> loading a playlist and saving it as another, new playlist.

No.  This is how I want playlists to work:

   User runs mythmusic, and has no items in the current playqueue.

   User adds tracks 3, 4, 5 to the play queue.  The current playqueue is now  
[3, 4, 5]

   User decides to keep the current play queue, and saves it as a playlist, 
called 'Black'.  When saved, it gets assigned an id of -23.  The current 
playqueue is then replaced with a single item referring to the new playlist, 
and becomes [-23].  

  User adds a couple more tracks (8, 9) to the queue.  The current playqueue 
is now [-23, 8, 9].  The playlist 'Black' is not modified by this action, 
unless the user goes and saves it again (at which point the current playqueue 
would just become [-23] again).

  User saves this current playqueue as a new playlist, 'White'.  'White' gets 
number -24.  The current playqueue is now [-24].  Which, through the magic of 
inheritance and polymorphism =) gets played back as [ [3, 4, 5 ], 8, 9]

  User adds a couple more tracks to the current playqueue and then exits the 
app.  The current playqueue [-24, 12, 13] is saved to the 'default playlist', 
for loading on the next run.  Both 'Black' and 'White' are available to other 
machines to load, as they were stored as global lists, the state saving at 
the end is not.  Or, maybe it could be marked in the music tree as what the 
original machine name was last listening to or something, that's just UI 
details.  If it were to be available to other machines, it'd of course be 
read-only.

> 	Foo saves state to a default source, "Red".
> 	Bar loads state from default source, "Red".
> 	Foo saves new state to new source, "Yellow".
> 	Bar saves new state to new source, "Blue".
> 	Foo saves new state to new source, "Green".

They can't "save state" to anything but the "special" playlist called 
'default', and that only happens on startup and shutdown.

> How do you store all four states?  The Red state is
> global (+1), Foo and Bar have local states (+2), but
> there is no way to save any more states.
>
> If Foo and Bar share a state that's not global, it
> costs us twice the space to store the two states
> that are identical.

<shrug> Any duplicated space in this part of the database is insignificantly 
tiny compared to, say, the entirety of a week's worth of television 
programming data.

> Further, if Foo changes the "shared" state, Bar will
> not see the updated state unless it manually copies
> the new state from Foo.
>
> Am I missing something?

I think you're missing the fact that I don't mean for the "default playlist" 
to ever be explicitly saved or loaded by the user, except maybe it'll be 
read-only visible to other machines as I mentioned above.

Isaac