GSoC:2008 Collections 2.0 Source preference - nesciens/xmms2-wiki GitHub Wiki

Source-preference

Description

Source-preference is that a) collection querying takes only the sources with best reliability into account b) clients can choose to request only the metadata set by these sources.

There are different ways imagineable to specify the sources. A major issue is whether to specify the sources on a per-connection basis, or on a per-medialib basis. That is, whether every client can set its own prefered sources, or the prefered sources are set globally.

Rationale for global source-preference

Setting source-preference globally has a couple of advantages. Firstly source-preference is consistent through all clients. Moreover users are sure to have an interface (if even the cli) to set their source-preference, while currently every seperate client needs to set source-preference on its own (and might not allow the user to tweak this).

Rationale against connection-based source-preference

Source-preference on a per-connection basis may (will) confuse users, as the result of a collection query depends on the client in use. So the user might browse a saved collection using client A and find something different than if he/she browsed the same collection using client B. To make it even more frustrating the daemon has its own source-preference, so a song might appear in a partyshuffle playlist, that the user perceived as not being in the source-collection... These different perceptions of the contents of collections are in no way useful and are probably annoying.

Implementation

Source-preference might be implemented in the medialib by adding a "rank"-column to the Sources-table. This would then store how important every source is. Additionaly a goodness-column would be needed in the Media-table (or in some MediaBackend-table), storing the difference in rank between the source of that particular row and the best source for that id-key-pair, hightlighting the best rows, as there goodness equals 0.

The ranks can be set using the configuration-properties.

For programming convenience a large part of this can be implemented in SQL. This would require moving Media to MediaBackend, then creating a view Media that looks the same as the current table and a view MediaSourcePref which only contains the rows with goodness = 0. For internal use views BestRankCached (goodness = 0) and BestRank (the real best rank) might also be convenient. After this triggers need to be created on the views to make sure MediaBackend is synchronized. For some specific use-cases (adding new media for example) it will be better performance-wise to write to MediaBackend directly, either calculating the proper goodness in the daemon, or syncing in sqlite just once per transaction. (In fact using MediaBackend is also more efficient in some other case, because of SQLite weirdness.)