[mythtv] [mythtv-commits] mythtv commit: r10078 by ijr

[Simon Kenyon]

Colin Guthrie wrote:
> Simon Kenyon wrote:
>   
>> Colin Guthrie wrote:
>>
>>     
>>> The db schema is much neater (tho' the playlists is still a string list 
>>> of song_id's)
>>>       
>> do you plan to change that?
>> and if so, to what?
>>
>> perhaps a table containing the playlist name and a single song id which 
>> you could iterate over
>>     
>
> I did originally plan on changing it to a table defining the playlist 
> (auto-id + name) and a link table that contained (pl_id, song_id, order 
> {as db order cannot be guarenteed - especially for reordering etc.}).
>
> However as I dug into the code I discovered a feature I didn't know 
> about which is that playlists can contain other playlists in them 
> (provided no circular dependancy is created overall).
>
> In order to do this, they use negative numbers as song_ids in the 
> current database and the code is littered with "if (id < 1)" type 
> conditions. It's not very easy to understand but it does work.
>
> Anyways, to represent this structure neatly in the database I'd need to 
> do a (pl_id, song_id, sub_pl_id, order) structure, where only one of 
> song_id or sub_pl_id can be specified and the other must be NULL (NULL 
> is better than 0 if you consider how foreign key constraints work, even 
> if we cannot use foreign keys with then MyISAM engine).
>   
drat and double drat

i'm not doing the work - so i don't get to vote
is the recursive playlist stuff used/useful?
does it affect reliability/performance?

my son creates playlists on his ipod galore
me, i just pick an album and play it (or shuffle my collection and take 
pot luck)

an alternative would be to make playlists be a simple collection of 
songs and introduce the complexity at a higher level of aggregation
- collections of songs
- collections of collections
partition the complexity so to speak


regards
--
simon