Reply to thread

Message

<blockquote data-quote="JulianBuss" data-source="post: 69056" data-attributes="member: 10499">I want to inform the community that I' working on the following: As written in earlier posts I'm not satisfied with the filtering possibilities in music views: one can create custom views and create a filter for a view level, but the filtered level remains visisble.Use case: I have music tagged with genres like &quot;Pop slow&quot;, &quot;Pop fast&quot;, &quot;Pop party&quot;, &quot;Pop rock&quot;, &quot;Pop live&quot; and so on. No I want to have a view showing all pop songs, that means everything having the word &quot;Pop&quot; in it's genre. Currently I can create a custom view with a first level showing &quot;genre&quot; and with thea filter &quot;like %Pop%&quot;. But when using the view, it shows me &quot;Pop slow&quot;, &quot;Pop fast&quot; etc. first instead of the albums, artist or whatever. In Meedio there is the possibility to create a filter for an entire view, not only for a specific view level. MP does not have that, so I started to implement it. While digging around I found that in MusicViewHandler.cs there is different SQL used for album, genre, artist and other views. For example, the artist view only uses the artist table of the database, the album view uses a join of artist and album view. So when I want to filter that by genre, it's not possible because the gerne information is not present in that situation. After some thinking I decided to create a new, standard virtual SQL table used by *all* music views. This virtual table is the result of the inner join of the artist, album, genre, song and path tables. Because I only use certain columns (and not all colums) it's quite fast. Depending on the view type (album, artist, genre...) this virtual table is grouped by some criteria, for example by album name. Advantage: we have only one basic SQL statement for all view types, and that SQL is just complemented by a &quot;group by&quot; and &quot;order by&quot; clause, depending on the view we want to display.That saves some lines of code and makes it easier to read. AND: with that we have the chance to create any custom filter in any view. For example, I can add a filter by genre in the album, artist or any other view, just by extending the &quot;where&quot; clause. I have to do some more tests and I have to check how to add a GUI element for entering a filter.Because this modification might have some impact on other things, I have to coordinate it with SteveV, who is on vacation at the moment. So it might take some days before I can finish this modification and submit it as patch.</blockquote>

[QUOTE="JulianBuss, post: 69056, member: 10499"] I want to inform the community that I' working on the following: As written in earlier posts I'm not satisfied with the filtering possibilities in music views: one can create custom views and create a filter for a view level, but the filtered level remains visisble. Use case: I have music tagged with genres like "Pop slow", "Pop fast", "Pop party", "Pop rock", "Pop live" and so on. No I want to have a view showing all pop songs, that means everything having the word "Pop" in it's genre. Currently I can create a custom view with a first level showing "genre" and with thea filter "like %Pop%". But when using the view, it shows me "Pop slow", "Pop fast" etc. first instead of the albums, artist or whatever. In Meedio there is the possibility to create a filter for an entire view, not only for a specific view level. MP does not have that, so I started to implement it. While digging around I found that in MusicViewHandler.cs there is different SQL used for album, genre, artist and other views. For example, the artist view only uses the artist table of the database, the album view uses a join of artist and album view. So when I want to filter that by genre, it's not possible because the gerne information is not present in that situation. After some thinking I decided to create a new, standard virtual SQL table used by *all* music views. This virtual table is the result of the inner join of the artist, album, genre, song and path tables. Because I only use certain columns (and not all colums) it's quite fast. Depending on the view type (album, artist, genre...) this virtual table is grouped by some criteria, for example by album name. Advantage: we have only one basic SQL statement for all view types, and that SQL is just complemented by a "group by" and "order by" clause, depending on the view we want to display. That saves some lines of code and makes it easier to read. AND: with that we have the chance to create any custom filter in any view. For example, I can add a filter by genre in the album, artist or any other view, just by extending the "where" clause. I have to do some more tests and I have to check how to add a GUI element for entering a filter. Because this modification might have some impact on other things, I have to coordinate it with SteveV, who is on vacation at the moment. So it might take some days before I can finish this modification and submit it as patch. [/QUOTE]

Verification