by Barry4679 » Wed Sep 23, 2020 4:19 am
rusty wrote: ↑Tue Sep 22, 2020 12:04 pm
To shed a bit more light on this, one of the guiding philosophies behind MM has been that whatever data is supported should be in an open manner--meaning that it should also be able to be stored to track tags in a standardized format so that the information can be easily shared with other applications (and vice versa).
That accounts for the track-centric focus you describe. Perhaps this might change in the future--just trying to give some visibility into why certain features haven't yet made it into MM (and why some have been minimized in the past).
Thanks for the background info Rusty. I appreciate you making the effort to explain.
Some comments:
- it may be a guiding philosophy, but it is not a hard rule ... ie. the track history in the played table is not persisted into the tracks, is it?
- but my major point is that the data need no be persisted anyway, because it can be derived from data that already is persisted
For my own purposes I push the following data into the MM db, to overcome the current MM limitation:
- Album play count = round(average(individual album track play counts))
- Last Album Play Date = max(track play date)
That probably sounds horrible, inaccurate, and useless, to a mixed track playlist person.
But, by definition, an Album-focused person is rarely, if ever, playing playing mixed track playlists .... so the above approximations do a good job of being useful criteria in active playlists, and album filtering|sorting. ... The main thing is that both values be constant for all tracks in the album, to avoid album fragmentation in lists or playlist selection. ... Maybe a Median calculation would be better for Last Album Play date, but Max is calculated with less overhead.
They could even be virtual fields ... ie be rows in the MM GUI, but not stored in the database.
I think that this addition would be welcomed by any album focused people.
[quote=rusty post_id=472849 time=1600794262 user_id=182]
To shed a bit more light on this, one of the guiding philosophies behind MM has been that whatever data is supported should be in an open manner--meaning that it should also be able to be stored to track tags in a standardized format so that the information can be easily shared with other applications (and vice versa).
That accounts for the track-centric focus you describe. Perhaps this might change in the future--just trying to give some visibility into why certain features haven't yet made it into MM (and why some have been minimized in the past).
[/quote]
Thanks for the background info Rusty. I appreciate you making the effort to explain.
Some comments:
[list]it may be a guiding philosophy, but it is not a hard rule ... ie. the track history in the played table is not persisted into the tracks, is it?[/list]
[list]but my major point is that the data need no be persisted anyway, because it can be derived from data that already is persisted[/list]
For my own purposes I push the following data into the MM db, to overcome the current MM limitation:
[list] Album play count = round(average(individual album track play counts))[/list]
[list]Last Album Play Date = max(track play date)[/list]
That probably sounds horrible, inaccurate, and useless, to a mixed track playlist person.
But, by definition, an Album-focused person is rarely, if ever, playing playing mixed track playlists .... so the above approximations do a good job of being useful criteria in active playlists, and album filtering|sorting. ... The main thing is that both values be constant for all tracks in the album, to avoid album fragmentation in lists or playlist selection. ... Maybe a Median calculation would be better for Last Album Play date, but Max is calculated with less overhead.
They could even be virtual fields ... ie be rows in the MM GUI, but not stored in the database.
I think that this addition would be welcomed by any album focused people.
