View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006509 | MMW v4 | Playlist / Search | public | 2010-09-28 13:21 | 2010-12-20 03:30 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0006509: Playlists should display using appropriate view settings | ||||
| Description | Playlists node contains music playlists, home video playlists (and future: photo playlists). Any playlist should display using a view optimized to it's content. Playlist can automatically determine what View settings to assign to a playlist at creation, however, such guesses may be suboptimal so the user should be able to manually define the view per playlist. (We considered making them subnodes of a collection instead, to allow them to display based on the Collection view, but this would incorrectly show _all_ tracks (even those that don't match) sub to a <Collection>.) Note: the same functionality should apply to the Now Playing list. | ||||
| Additional Information | UI Spec at: http://www.jirihajek.net/MMwiki/index.php/MM_4.0_UI#Main_Panel | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1335 | ||||
| related to | 0006777 | closed | petr | Collection Default settings |
| related to | 0006961 | closed | petr | Columns change order after switching views |
| related to | 0006642 | closed | Ludek | Search Dialog needs to be updated to support Collections |
| related to | 0007032 | closed | Ludek | Edit Playlist: Name field doesn't display well |
| related to | 0007120 | closed | petr | # column settings forgotten |
| related to | 0007552 | closed | petr | Playlist column settings unclear wrt which Collection settings are being used |
|
|
In order to give user a chance to edit playlist type, we should add 'Edit' command to right-click menu (and maybe change 'Edit autoplaylist' to 'Edit'). In case of Playlists, it would show a simple dialog: Name: _Playlist 1__________ View as: _Music____________ [v] [Ok] [Cancel] In case of auto-playlists would be these two edit lines added to the top of the dialog? Technical spec of how it should work: Playlists: After creation of an empty Playlist, its View would be set to {Empty} and temporarily considered to be Music. After addition of some files, View would be changed according to Type of these tracks. In case Playlist already has a non-empty View and this View would need to be changed because of new tracks added (i.e. more than 1 View is necessary), the View should be automatically changed to Mixed (a simplified view, with a Summary column visible and only few others). Note that we should internally store information if user ever changes View for given Playlist manually - in this case no automatic changes would ever be done on this one. AutoPlaylists: Here View field maybe isn't that much necessary, as it would be automatically handled by Type field of autoplaylist rules. However, since user might have different expectations, I'd rather have View field even here, pre-populate it based on Type rule, but give user a chance to modify it to any value. |
|
|
Re. the UI suggestions, sounds good. Re. the technical spec: 1) Playlists: can you clarify what the criteria is that determines whether changes to the playlist will trigger an automatic change to the View (it sounds like changes to the playlist trigger View changes early in the life of a playlist, but i don't understand specifically what determines this). 2) AutoPlaylists: so are you suggesting that every AutoPlaylist _must_ have a Type defined? |
|
|
1) Each track has a Type specified which corresponds to some of the standard Views (Music, Video, ...). So, we could make rules based on this. However, in order to simplify things for the beginning, we could possibly simply set all Playlists to Music (since I suppose most users will use Playlists exclusively for Music) and leave the changes to View to be done manually by user? 2) No, I was just suggesting, that in case user somehow configures Type condition, View might be changed accordingly. However, maybe this isn't necessary and as in 1) we could leave Music by default. |
|
|
I suppose that we could have it default to Music for now, though this probably doesn't make sense in the long term (e.g. once we add support for Photos). |
|
|
Assigning to Ludek. |
|
|
Fixed in build 1318. |
|
|
1. The dialog looks weird in Win7, wrong background, etc. 2. Due to just decided merge of Collections and Views, we have to change it slightly: Playlist configuration Title: ___________ Display as Collection: _Music__________ [v] I.e. show Collections instead of Views (as they will no longer be visible to users). 3. Automatic choices of Collection to be used for Playlist presentation could be improved to: After any addition (or maybe also after a change of Track Type of some track?) to a Playlist, all Types of tracks in the Playlist would be collected and a Collection that contains all that Types in its Criteria configuration is chosen. A practical example of this is: a. A playlist is made out of several Music Video tracks => it's set to be presented as 'Music Video' Collection. b. Then few Music tracks are added => its presentation is changed to 'Music' Collection (since it contains both Music and Music Video Types). c. If then some Audiobooks are added => presentation is changed to Entire Library, i.e. some general, content neutral presentation, as it contains all Types. Note that this handling has also to be done e.g. after a Collection is permanently deleted. |
|
|
Items 1) and 2) fixed in build 1319. But I am not sure about the item 3) From the user perspective I would expect that if a user sets a playlist to Display as Collection: Music (BTW I think that the original 'View as: Music' sounds better) then the playlist will be always displayed as Music even if I add a video file into the playlist. Similarly just viewing the playlist configuration and seeing it displayed as 'Music' should ensure users that it will be always displayed as Music. For this reason I wouldn't implement 3) |
|
|
3) Sure, you are right that after a manual change of this value done user, it shouldn't _ever_ change its value automatically again. The algorithm described should be applied only for newly created playlists, until the value is modified by user. 4) As for the wording - you might be right, but I wanted to include the word 'Collection', so that it's clearer to user what item we refer to. So, alternatively we could use something like: View as: _Music___ [v] Collection |
|
|
Re: 3) It implies that we need something like: [ ] View as: __Music___ [v] Collection and have the Combo box disabled until user enable the checkbox (and thus disable the dynamical assignments). But this could be a little confusing and I still don't think this is a good idea, because it brings also some performance issues and also 99 percent of playlists will probably consist of music files. |
|
|
3) I supposed that the checkbox wouldn't be necessary, this variable would be internal to MM, i.e. automatic until the first change. That said, it might be nicer to add an item 'Automatic' to the dropdown, which would be the default, until modified by user. Re. need for this functionality - I find it quite important, since if someone starts using Playlists for non-Music items, we should show them in the expected way. E.g., if I use Send To Playlist command from TV Shows collection and then switch to the newly created playlist, I wouldn't like to see it presented as Music. Re. performance - I don't think that it would cause any significant issue. In the the straightforward implementation wouldn't work well, we could e.g. create DB triggers that would keep each Playlist item up-to-date with info (can be stored as bits of an integer) about Types of tracks it contains. |
|
|
I think that performance impact can be minimized by having the 'automatic' feature only work when the playlist is initially created. Once the settings are adopted, no monitoring of content Types would be required, and the Collection settings wouldn't have to change. |
|
|
Adding the 'Automatic' as default to the dropdown solves the issue I've raised initially. Re. performance impact both solutions (Rusty's and Jiri's) doesn't solve the problem for (large) auto-playlists where the performance impact would be serious, because we need to read all the tracks before in order to determine type and thus columns that should be displayed in the tracklist. I think we will need to use a simplified solutions, e.g. to determine this just based on one track, this would at least solve the problem for playlists consisting only from tracks with the same type (e.g. the TV Shows playlist mentioned by Jiri) But maybe the most suitable solution would be to determine the type once after all tracks are shown in tracklist and use the determined type/view next time the playlist is displayed or re-apply the view once the reading of all (auto-)playlist tracks is finished. Downside: First time showing of playlist will need to use a default view. |
|
|
We don't need to read Autoplaylists at all - we know Type of the tracks directly from the specification of the query, i.e. in case Auto-playlist is created with Type=TV show' criteria, we can easily automatically assign a Collection that contains this Type of tracks. So, I'd say that either solution proposed (by Jiri or Rusty) would work fine. I guess that we can start with Rusty's, since it should be pretty easy to implement and decide in the future, whether any update is necessary. |
|
|
And what if the Auto-playlist isn't created with the Type criteria at all? e.g. For example the default auto-playlist called "Accessible tracks" consists just from one rule: Status | is accessible and usually is very large, because it contains all accessible tracks. |
|
|
For now, I'd probably set such autoplaylists to Music type (i.e. a Collection having Music type tracks). We can think of a better solution, if needed (which probably won't be). |
|
|
OK, so to summarize this. For Auto-Playlists: If user is adding new auto-playlist then this dialog is present: Name: __New AutoPlaylist_____ View as: _Music_______[v] collection --------------------------- |Basic|Advanced| Match [All] of the following criteria: ...... [Clear] [OK] [Cancel] so the 'View as:' dropdown is set to 'Music' until user define a rule consisting of condition 'Type is' and (Match is set to [All] criteria), then the value in the dropdown is automatically changed to the determined collection. For standard Playlists: When user is creating new playlist then this dialog appears: Name: __New Playlist___ View as: _Music__ [v] Collection [Ok] [Cancel] and the "View as" dropdown is set to a) 'Music' if user creates an empty playlist b) Corresponding collection determined based on the group of tracks for which the playlist is about to be created Agreed? |
|
|
Sounds good. |
|
|
Fixed in build 1320. |
|
|
As noted in 0006777: The playlist 'View as' setting has no effect. e.g. Playlist set to 'Classical' doesn't appear like the Classical collection. Petr indicated some related issues with this functionality: - Change view as for playlist will not apply when user confirm dialog (need to change to another node and then back to playlist) - In Auto-Playlist edit is incorrectly labelled 'Search' instead of 'View as' note: this functionality has not been tested extensively. |
|
|
Fixed in 1335 Re: Auto-Playlist edit is incorrectly labelled 'Search' instead of 'View as' - this is all right (see 0006642 for details) |
|
|
Verified 1336. Functionality works correctly. A couple of issues remain but they're documented separately: 1) mixed up columns: 0006961 2) playlist name field isn't wide enough, and is right-justified instead of left justified. |
