Comment 7 for bug 661460

Revision history for this message
Ferran Pujol (ferranpujol) wrote : Re: support smart playlists and crates

A filter that evaluates to true for songs that are in a particular crate and multi-parent crates are essentially the same (A child crate is a crate that selects tracks that match its query AND its parents query). They both present a problem when cross-referencing crates, e.g:
Crate A = songs that are not in crate B
Crate B = songs that are not in crate A

This cannot be evaluated. Did you thought about this when you came up with this ideas? How could we solve this in a way that is efficient and is easy for the user to understand why he/she can't configure a crate the way he/she wanted? Some users might get confused about why their crate doesn't work. In fact this would introduce the users with the task of "debugging" a smart crate expression, as some complicated ones could lead to this kind of evaluation cycles.

If we limit the crates structure to be a tree (just one parent per crate), we can easily prevent this issues. In fact, in this case the only problematic operation would be to move a crate down one of its child branches. This can be managed just by breaking all the child relations of that create before moving it down one of its branches.

We could keep the “is in crate” filter if we don't support it on smart crates queries but just in the search field and as a library column.

So, is it really worth to support multiple parent crates? What are the use cases that would benefit from that and which couldn't be achieved in a reasonably easy way with a tree-like crate structure?