There are several reasons why you may have unmatched Spy observations arising from your Sonos plays:
- the reason will depend upon whether you were playing from your local library, or from a music streaming service
- if the incidents are arising from your local library plays, the default configuration may not work for your environment. You may need to teach AlbumPlays how to translate between the differing methods used by Sonos & MediaMonkey to locate your tracks
AlbumPlays will show you that there are unmatched Sonos plays via the following methods:
For the following illustrations I played some tracks from my local library, and I also streamed three Bill Evans tracks using the Google Play Music streaming service. I played one track from a Bill Evans album which I don’t own, and two tracks from an album which I do own. One of these two other tracks was Google’s copy of the track that I own, ie. from the 18+ million tracks which they stream for a monthly fee. The other track, from the same album, was from Google’s My Library service, where I played my own track, which I had previously uploaded to Google.
It would be ideal if two of those three plays got uploaded to MediaMonkey, and only the track which I don’t own was discarded. But this is not going to happen on this occasion by default, because the tags for the Google track differs from my own version. If you look at the Sonos queue you can see that they have given the album a different artist name to the one which I used, ie. Bill Evans Trio, not Bill Evans.
The Run Summary
This is displayed at the end of each AlbumPlays action.
The summary from the Get action shows that I have imported Spy observations, but discloses nothing about their streamed or matched|unmatched status. It shows that there were 16 track plays observed. We can’t see this yet, but 9 of them were played by my wife. I am using an AlbumPlays configuration option to track only my own plays, so only the 7 plays, which I played, will progress.
The summary from the Approve action shows that only 5 of my 7 Spy observations were uploaded to MediaMonkey. The other two were rejected as being unmatched streamed plays. The default behaviour for unmatched streamed plays is that there is no warning, no chance to intervene, and other than the little message at the top of the display, there is no indication that they have been silently discarded. This is a convenience default behaviour, intended to streamline the application if you listen to a lot of streamed music which is not also part of your own collection.
The default behaviour for unmatched Sonos observations of plays from your local library is to warn you , and to suspend the Approve action. This allows you a chance to fix the situation, or requires you to approve the discard if you are unable to fix it, or don’t care. Unmatched spy observations from your local library are unexpected (note 1).
You can override the default behaviour for unmatched streamed plays, so that they are handled in the same way as local plays. You do this by using the _force_pause_for_streamed_confirmation configuration option. In this unusual case, that would have been helpful, because the application has just discarded the play of a Bill Evans track which I do own. It discarded this play because Google’s music tags differed from my own tags for this album.
The Approve action will now not proceed, unless you fix the mismatch, or approve the discard of the unmatched plays via the check box control.
So, in summary, unmatched Spy observations are handled differently depending upon their source:
- by default, unmatched streamed plays give a very light-on indication, and require no confirmation before discarding the play from the upload to MediaMonkey
- unmatched local plays give a clear warning, and suspend the Approve action until you approve the loss, or fix the underlying cause
- what is “lost” is the upload of the play into MediaMonkey; the scrobble to Last.fm is not lost
Albums Played report
This report is displayed at the end of each Get action. Any unmatched tracks are indicated in the right hand column.
This is where we can see that my wife played 9 of the original 16 tracks. The report also identifies which of the albums played had unmatched tracks.
We can make updates from this screen, but no updates that will affect whether or not tracks are unmatched.
The report does give reasonably a clear warning whether or not AlbumPlays is able to match plays from your local library using the track location method. The right hand column will be blank if track location matching is working.
The Unmatched Streamed Scrobbles report
This report is available from the Status Report tab.
It lists the streamed tracks which were excluded from the MediaMonkey upload, as they were unmatched.
The report is available after the Approve action, whether or not the Approve action completed, or was suspended awaiting approval from you. The report remains available until a fresh batch is started by the next Get action.
The Unmatched Raw Scrobbles report
This report is also available from the Status Report tab.
It is identical to the above report, excepting that it lists unmatched spy observations which were from the local library.
Timeline for unmatched Spy observations
|Play source||Album in MM?..||Expected outcome..|
|streaming service||Yes||At then end of a Get action, it will be marked as streamed and Unmatched in the Albums Played report|
|Provided the Streaming Service’s tags match your own it will become matched during the Approve action|
|If remains unmatched it will be excluded from the Upload to MediaMonkey. See the next section for more detals.|
|You can avoid this happening again by defining a rule to enable the track to be matched, as described here|
|streaming service||No||At then end of a Get action, it will be marked as streamed and Unmatched in the Albums Played report|
|It will remain unmatched at the end of the Approve action as it isn’t in your MediaMonkey database|
|There will be indications in the Run Summary and the Albums Played report.|
|It will be listed in the Unmatched streamed scrobbles report available from the Status Report tab|
|You will not be otherwise warned that the play has excluded from the upload to MM*, unless you have overridden default behaviour|
|local library||Yes||If the album is marked as Unmatched in the Albums Played report at the end of the Get action,|
|this implies that AlbumPlays is unable to match by track location using default settings.|
|You can teach AlbumPlays how to match by track location.|
|AlbumPlays will automatically fall back to match by music tags (for more info see here)|
|If the play cannot be matched by music tags, you will get a Warning on the Run Summary, and it will not|
|allow the processing cycle to be proceed until you either fix the cause of the mismatch,|
|or allow the cycle to complete without uploading the mismatched plays to MediaMonkey|
Unmatched plays from your local library are unexpected if AlbumPlays is using the default option, which match the SPY observation back to MediaMonkey using the track’s location on your disk. Unmatched local plays are an indication is that AlbumPlays is unable to use track location match, which is something that you can fix. ↩