The MediaMonkey database stores play count data in summary form. It also has facility to store all individual scrobble details, although it makes no use of them.
AlbumPlays’ default setting is to load just the useful play count summary data into MediaMonkey, but does also have an optional facility to transfer all of the individual details as well.
|MediaMonkey play related data||Used by MediaMonkey?||Description|
|Summaries only||Yes||Track’s total play count and date last played|
|Details||No||as above, plus all individual scrobbles|
If you are familiar with MediaMonkey you will know that a track’s last play date, and play count, are displayed, and are available for searching, display sorting, and display filtering purposes.
However the individual scrobbles do not appear to be used, even if they are stored by MediaMonkey. I am not aware of any way to display or use them, other than their faint reflection in the Library Statistics display. The areas shaded yellow in the following illustration are meaningless unless the play counts details are stored in MediaMonkey.
But it is questionable whether the yellow areas on the above report are meaningful anyway. The Windows version of MediaMonkey does generate and store a a play detail for every track which is played by itself. Maybe the same happens for all track plays made with the Android version of MediaMonkey; I haven’t investigated this. But because this level of information is essentially meaningless to MediaMonkey, there appears to be no consistency checking nor enforcement between these details and the play summary information.
external tools can upload additional plays into MediaMonkey. AlbumPlays is an example of this. Many tools just update the summary information, because that is all that seems to be important to MediaMonkey.
there are also also external tools which allow manual adjustments to be made to MediaMonkey’s play summary data.
Tools from either of these categories could easily cause MediaMonkey’s summary data to become out of synchronisation with its detail data. MediaMonkey doesn’t seem to detect nor care about this. So the information shown in the above Library Statistics report may, or may not, be factual.
AlbumPlays is the master copy of play related data
One of AlbumPlays’ prime functions is to harvest your play counts from across all of your music platforms, including track plays which were invisible to MediaMonkey. AlbumPlays’ design assumption is that it holds the master copy of your play history. MediaMonkey remains the master copy of of your tracks, and their tags.
Details of all of your individual scrobbles are retained within AlbumPlays. It has facilities that MediaMonkey does not have to protect and manage these:
- consistency auditing between the individual scrobbles and the play summary information used by MediaMonkey
- repair capability should the database ever become out of synchronisation
- facility to display and redact individual scrobbles
For efficiency reasons AlbumPlays’ default behaviour is to transfer just the summary information into MediaMonkey. It does this by overwriting MediaMonkey’s date last played and play count columns at the successful completion of each Approve action. By default it does not add the individual scrobbles into MediaMonkey’s Played table. MediaMonkey will retain (invisible) details of just the tracks which were played using MediaMonkey itself.
You can change this situation by configuring AlbumPlays to also transfer the individual scrobbles as described here.
Considerations if using MediaMonkey as a player
There is an important consideration to be aware of if you reconfigure AlbumPlays to transfer scrobble details, AND you are using MediaMonkey to play tracks. ie. you use MediaMonkey as a player, and not just a tool to catalogue, browse, tag & produce playlists from your collection.
- MediaMonkey will generate play details for the tracks which it plays. It is important that you configure MediaMonkey to scrobble these plays to Last.fm.
- AlbumPlays will harvest all scrobbles from Last.fm. It will now have knowledge of your MediaMonkey plus your non-MediaMonkey plays.
- AlbumPlays will overwrite MediaMonkey’s play summary columns with updated data
- If you have reconfigured AlbumPlays to also transfer scrobble details it will clear away any fresh scrobble details which were generated by MediaMonkey. This to avoid duplication, and is because MediaMonkey has no facility to detect or manage duplication
So the important consideration is that if you want to reconfigure AlbumPlays to also transfer details, AND you are using MediaMonkey as a player, you must ensure that MediaMonkey is scrobbling.
You also need to be aware that AlbumPlays will overwrite MediaMonkey play details, with just those scrobbles which are both successfully received by Last.fm, AND which are then received and matched within AlbumPlays. This is a design limitation of AlbumPlays.
So, why bother loading the individual scrobble details in MediaMonkey?
In my view there is not too much to be gained. The main impact is that you add bloat to your MediaMonkey database and elngthen the run time of the Approve action. The only benefits that I am aware of are:
There are MediaMonkey add-ons which will display the otherwise hidden scrobble details which can be stored into MediaMonkey. MagicNodes is quite nice. An example of it’s output is shown below; this from the list of albums I played back in October of 2009, ie. six and a half years ago. So maybe information of that type floats your boat?
All of your individual scrobbles will be stored in MediaMonkey as well as in the AlbumPlays database, so there is some futher protection if the AlbumPlays database is ever becomes corrupted or lost. nb: there is currently no facility to extract or use the detailed data in MediaMonkey. … The real answer to this risk is to have regular application backups, keeping at least one version offsite. eg. something like CrashPlan, or have something copy the database to Dropbox.
You don’t have to decide now
As described above, all of your individual scrobbles will be retained in the AlbumPlays database. If you ever decide that you also want them in the MediaMonkey database for some reason you can run the following menu item which will import all of your scrobbles from AlbumPlays into MediaMonkey, replacing whatever was there.
That is all that you need do if you just want a one-off snap shot. Or you can reconfigure AlbumPlays as described here to have it continuously add fresh scrobbles at the end of every successfully completed Approve action.