The aim of this step is to “seed” your database with any historic scrobbles stored in your Last.fm account. This step is optional; there is no problem if you want to start using this application without loading your history.
Seeding the database with historic scrobbles can be a tedious task. There are other options:
- if you previously used some other tool to import your play data into MediaMonkey, you could elect to retain the existing MediaMonkey summary of your play history, and ignore your Last.fm history
- or you could ignore the past, and begin accumulating play statistics as from today
The next few sections of the Users’ Guide describe the seeding from Last.fm option. You need to read these sections regardless of which option you choose, as the facilities described here are those that you will use of a day-to-day basis to handle any scrobble mismatches. The same tools are used if you are a Google Play user, and are wanting to import information from your Google library.
Instructions showing how to use the alternative start-up options are found in the FAQ.
If you are interested an explanation of why scrobbles become “unmatched”, how it is a pain, and why this pain will go away, then open up the following closed section.
Cause of the difficulties, and the good news
Once you have obtained your historic scrobbles from Last.fm, we need to match these up with the same tracks in MediaMonkey. This can be difficult as the scrobble tags may be different to your current track tags:
- you may have changed the track’s album, artist or title tags since you scrobbled the play
- Last.fm may have “corrected” your scrobble.
To date Last.fm have collected 104 billion (with a “B”!) scrobbles. This database would be useless if there were no consistency of names applied to artists, albums and tracks. The Last.fm site can automatically moderate your scrobbles where it detects that you are not using the standard names and titles which they have settled upon.
- Sonos, or Last.fm, may have cut the end from long track, artist, or album names.
This especially affects classical music, which can have very long descriptive track names
Also, Last.fm doesn’t record the source of the music that you have scrobbled. This means that we will not be able to distinguish between plays from your own music collection, and plays from streamed services. This is a pain, because it means that plays of your own tracks, which weren’t automatically matched to MediaMonkey due to any of the above reasons, may be buried amongst all of the streamed plays of tracks which you do not own, and have not loaded into your MediaMonkey database.
So the task can be tiresome, but the tool described here attempts to reduce that pain level. It is a doable job; when I seeded my own database back in 2011, I had 54 thousand scrobbles, and I managed to match 96% of them. The unmatched were mostly some dabbling that I had done with streamed services.
And the good news is that the pain goes away once you start upon your day to day plays, after you have seeded your database:
- you will normally import the fresh scrobbles soon after the tracks have been played, before you get a chance to complicate the matching task by re tagging track, artist or album names
- you only have to compensate once for any Last.fm scrobble “correction”, or Sonos name truncation. AlbumPlays will notice, and remember, that you refer to the track differently to Last.fm. It will automatically re-apply your own names to any fresh scrobble which is imported but cannot be matched against your MediaMonkey database. It will automatically complete the match without needing any further assistance from yourself.
- Sonos owners: if you are using AlbumPlays in the mode where it detects your plays directly from Sonos equipment, the problem entirely goes away anyway. You are immune from whatever change Last.fm makes to your scrobble, because AlbumPlays will already have applied the play against your MediaMonkey database. AlbumPlays can also distinguish Sonos plays from your own collection, and won’t try to import unmatched streamed plays into MediaMonkey.
The first stage of this step is to import a batch of your historic scrobbles, from Last.fm, into the AlbumPlays database. An empty database was created during installation, and the application will be pre-positioned to run the “Get” action. Press the “Run” button.
AlbumPlays has been set up to initially limit the number of scrobbles that we read from Last.fm. It is intended that you retain this setting only while proving that AlbumPlays is functioning correctly, and to keep volumes small while you are learning how the applications works.
This is an example of the expected output. The log window is the black panel underneath. It starts white, and turns black once the step has completed. The “i” icon in the overlaying panel indicates that the step was successful, and completed without incident. The section which I have highlighted on, the black panel, shows that we read just a limited set of our historic scrobbles; I have 1052 “pages” of scrobbles to download, and so far have asked for just 3 pages, a small step, but every journey has to start somewhere
The UI advances to the “Approve” action. Press the Run button, which will trigger the validation of the acquired scrobbles against the MediaMonkey database, and if there were no errors, would apply these against the MediaMonkey database.
So here is the pain; there are errors. The GET step downloaded 525 scrobbles from Last.fm, and 67 of them were unmatched against my MediaMonkey database!
At first glance this seems disappointing, but in my case it is accounted for by the fact that I initially started scrobbling while I was just beginning to rip my music collection. So a lot of my initial plays were from a streaming service, and many of those tracks will not match, as I don’t own the albums.
The ratio of problems will diminish as:
- I start to encounter more plays from my local library
- AlbumPlays starts to learn which of the albums that I am playing come from a streamed service, so that it knows to ignore these tracks and albums
- and as I advise AlbumPlays of tagging translations, it will remember the fixes, and auto-apply them whenever the track is encountered in the future
- Sonos owners:: if you later progress onto AlbumPlays’ Spy mode, it can automatically differentiate between local & streamed plays, and it knows not to worry about streamed plays, where you haven’t loaded these tracks into your MediaMonkey database
The UI is now offering the opportunity to call it quits with this batch of scrobbles. If you check the check box, and press Run again, the application will proceed, ignoring the unmatched scrobbles:
- it will apply the play counts from the matched scrobbles into the MediaMonkey database
- it will junk all the unmatched scrobbles; they will not be retained in the AlbumPlays’ database
- AlbumPlays will return to GET mode, so that you can repeat the Get|Approve cycle
But we shouldn’t give up yet. The next stage is to fix some of these matching errors, so we will not use the “ignore” check box at this point.
NB: you can override the “Action” radio button setting at any time, to run multiple successive Get actions while the batch is open. The pot of unapproved scrobbles just gets larger, ie. the successive GETs do not overwrite each other.
Previous step: Configure the application for your environment.
Next step: Seed your database – part 2 – fix mismatches.