|
|
If you did that would you stop there? Sort by other aggregate functions would equally useful; eg. mostly mean(date last played) and max(date added), but also mean(play count), |
|
|
If you are in Grid Album view info that you have is Album Art, Rating, Album Name, Album Artist so last played, date added, play count do not have meaning as info is not available, but you ar eright we should consider allowing Grid sort by all Visible information. Will leave Petr to triage if he likes that idea. |
|
|
Don't get your point. Added, and the Play attributes are the same as Rating and Genre. Ie. They are all assigned at the individual track level. None if them are Album attributes, which is why are talking about Averages and Means etc. |
|
|
Not sure what is not Understandable. Other starts are not seen and as you check only Avg. Rating is missing. Only other thing that is possibly Missing is "Album Name (Album Year)" in view so that when you sort by date you can visually see sorting. image.png (42,871 bytes) |
|
|
What is not understandable is this: You support modification to sort album grid by Rating. But you don't support sort by Date Last Played, or Play Count, or Date Added ... because this info is not available at the album level. I am saying that they are the same as Rating. Rating is not available at the album level either. I don't know of any way to set Album level Rating, other than setting it at the individual track level. The database has nowhere that album level rating is stored (AFAIK) So Album Rating is an on-the-fly aggregate function of its tracks. Don't that mean that all of these things are equally doable? One other thing: there is value in sorting the Grid even if the value used for the sort sequencing is not visible. eg. If I sort the Album Grid to descending max(Date Added) ... I don't need to see that actual dates, and in fact they would be distraction ... all I would be wanting to achieve would be a grid of my albums, where my newer rips would be towards the top. |
|
|
Problem with these computed fields (incl. rating) is that it's loaded asynchronously just for the albums currently in sight (so it's not loaded for all albums in the grid at a time) and sorting performance by this kind of fields can be very slow (incl. grid update). Also computed values mentioned by Barry makes sense to me. |
|
|
petr: "Problem with these computed fields (incl. rating) is that it's loaded asynchronously just for the albums currently in sight (so it's not loaded for all albums in the grid at a time) and sorting performance by this kind of fields can be very slow (incl. grid update)." I understand. Thanks for explaining. MM4 offered album grid sort by rating. How did that work? IMO the real problem is that these are left as computed fields. It would be better of they were stored fields in the Albums table. ie. an update trigger on Songs update, where rating, playcount or date last played were altered. I see that the Albums table already has a date last played attribute for video media The benefits would be: * enhancement to Grid by Album sorting|filtering * enhancement to List By Album sorting|filtering on these attributes without breaking apart the album * create Collections and playlists using these album level attributes |
|
|
We can add them to the Albums table and update values using triggers |
- Anonymous
