View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008104 | MMW v4 | Collections (Filters) | public | 2011-07-08 12:29 | 2012-11-11 01:07 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0008104: Unite content of drop-downs | ||||
| Description | Currently we offer users several drop-downs when editing track properties, e.g. for Artist, Album, Genres, etc. There are several problem in the current implementation: 1. Performance - we try to solve it by moving some tasks to threads, but it's only a partial solution. 2. Content - we try to show Genres based on Collection the selected track belongs to, but e.g. Artists are shown from the Entire Library. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1600 | ||||
|
|
2. As for Content, I'd suggest to always show items based on Type of the current File. I.e., regardless of Collection, all possible values of the current Type would be shown. The reasons are: 2a. It makes most sense from performance point of view. 2b. It also makes from the point of view that a File doesn't necessary belong just to one collection and so opening its Properties would show different content based on the current Collection, or even more different if opened from a non-Collection (e.g. Now Playing). 2c. There doesn't seem to be any serious usability issue this way. 1a. To achieve top performance and avoid any slow queries, we should keep counts of items used for each Type. I.e. each entry in Genres table would have a column for each Type we use (named like Type1, Type2, etc.) and these columns would be automatically updated by triggers based on updates of GenresSongs and Songs tables. 1b. The same as 1a. should be applied to Artists and Albums. Note that I don't think that this kind of counting needs to be done for each PersonType of Artists table, it can be done globally for this table. 1c. We should keep a table (updated by a trigger) of all ParentalRatings, in order to avoid 'SELECT DISTINCT ParentalRating FROM Songs' query. |
|
|
Reminder sent to: rusty Assigning to Ludek for an implementation (post 4.0), but Rusty please have a look at 2. to make sure we are in agreement. |
|
|
Sounds good. |
|
|
OK, just such a column should be rather called Artists.MusicFilesCount instead of Artists.Type1 and the advantage is that we should significantly speed up Artists, Genres node expanding for the default collections, entered as 0009193 |
|
|
Tech note: Finally I used another solution, because suggested solution involved introducing of 16 new columns (8 types on 2 tables), 64! new triggers (8 types on 2 tables on INSERT, UPDATE (2x), DELETE) which seems to blow DB and worse performance on writing. As a better solution I used following: Moved TrackType column to ArtistsSongs/GenresSongs tables (updated by 2 new triggers) and added 2 indexes: (TrackType, IDArtist) on ArtistsSongs, (TrackType, IDGenre) on GenresSongs. This solution achives a very good performance also on very large databases. |
|
|
Tech note2: The most significant slowness was the ParentalRating query, introduced the ParentalRatings table and used it also in the other parts of MM. Usability note: I don't think we should restrict the conent of dropdowns to the currently selected type, because there are a lot of cases where attributes are common to more then one type, e.g. - director can be same for types Video, TV or Video Podcast - album can be same for types Classical Music, Music or Music Video - genre can be same for Audiobook, Video or TV etc. Therefore I left the approach to show all possible values in the dropdown (i.e. showing all genres in the Genre dropdown, all directors in the Director dropdown). There is no negative performance impact. |
|
|
Fixed in build 1600. |
|
|
Verified 1605 |
