Applicable in Last.fm mode? : yes
Applicable in Spy mode? : sometimes, as indicated, mostly only when supplementing Sonos plays with any “other” plays
Unmatched scrobbles are fresh scrobbles which can’t be matched to a track within your MediaMonkey database. The application alerts you that there is a problem by using the yellow “!” icon an the Run Summary dialogue box.
There are several situations which can cause unmatched scrobbles:
- the track was streamed – you don’t own a copy of it, and therefore it is not in MediaMonkey
- Last.fm “corrected” (ie. altered) your scrobble
- your tags are too long, so either Sonos or Last.fm cut the end off from your tag
- maybe you change the track’s tag after you scrobbled it?
AlbumPlays has tools to ease this pain. There is a facility to easily create persistent rules to remap a mangled scrobble, back to your MediaMonkey tag values. Also facility to notify AlbumPlays that you have streamed the album or track, and don’t own it. These facilities are covered in the Seeding Your Database section of the User Guide, so not repeated here.
You can handle unmatched tracks by either:
- update your track so that its tags match those received back from Last.fm. You update your track tags using MediaMonkey. … The AlbumPlays application does have its own database which will automatically be brought back into synchronisation by the final Approve action for the batch of fresh scrobbles.
- or use the action list to create a rule to permanently fix the issue by modifying the tags in the scrobble, and in any future scrobble for the track or album, so that it now matches your MediaMonkey tags
- or use the action list to create a rule to permanently ignore scrobbles for an album or track which you don’t own
- or just ignore the mismatch warning; the scrobble will be discarded when you force-close the batch
If you have corrected the situation by either of the first three methods, press the Run button to retry the Approve action. The batch will be automatically closed if all of the mismatches have been resolved.
Or you can force_close a batch by checking the unmatched scrobbles check-box control in the “ignore” section of the Wizard, and then pressing Run to re-run the Approve action. Any scrobbles which are still unmatched will be discarded.
Resurrected and Lost Scrobbles
Some scrobblers are better than others; many can lose scrobbles if the Last.fm site is down, or stressed. The same thing may happen when there is some problem or congestion on your LAN or Internet connection.
Sonos owners: Native Sonos scrobbling is on a best-effort, no-promises basis. Sonos sends the scrobble off to Last.fm, but doesn’t check nor care whether Last.fm received or successfully processed your scrobble. In my case I calculated that 4% of my scrobbles were lost for one reason or another.
The AlbumPlays application can attempt to compensate for these problems. There is an option to detect missed tracks, where you are playing whole albums in their natural track number sequence. It checks the start times of the tracks on either side of any gap, and takes into account track durations. If there is an apparent hole in your play history, long enough to have accommodated the missing track(s), it offers to fix the situation. (see note below for qualifications) 1
In the illustration shown here, two scrobbles were lost from my Dave Matthews Band album. The application has detected this, and has determined that there was an unaccounted for time gap within the scrobbles which it did receive, and that gap was long enough for the missing tracks to have been played. The application pops up a dialogue box offering to resurrect these lost scrobbles.
Unless you uncheck the check-boxes for the lost tracks, and press the F3 key, the application will add the lost items into the batch of fresh scrobbles. To accept the resurrections you may just close the dialogue box by the F4 key, or any other method.
Although it does not repair your Last.fm history, these plays will be successfully recorded into your MediaMonkey database.
The Task Complete summary dialogue box confirms that the resurrections were successful.
By default the resurrection logic is turned off. If you typically play whole albums, you may want to enable resurrection of lost scrobbles, as described here
AlbumPlays can optionally warn you if any duplicated scrobbles have been detected in the batch of fresh scrobbles.
This isn’t necessarily an error condition, as it is the expected situation if you have repeated any tracks in the duration since the previous Approve action.
On the other hand I have found that some android scrobblers (eg. Simple Last.fm) are prone to generating duplicate scrobbles from a single track play, when a track is interrupted mid-stream by a phone call or android notification.
This warning is shown above, and it is just to alert you that the current fresh batch has tracks with multiple plays. It is up to you to determine whether or not this is an unexpected situation.
Navigate to the Status Report tab to show which tracks had multiple plays.
If you determine that any single track play has generated multiple scrobbles, you will have overstated play history in Last.fm, and maybe in MediaMonkey also.
Go to your Profile page at Last.fm, and click in Recently Listened Tracks. … Do not attempt to delete the plays directly on your profile page, as this will remove the track from your library, deleting ALL plays of the track.
On the Recently Listened Tracks page delete the duplicated scrobbles as shown below.
Truly duplicated scrobbles, ie. exactly the same date and time, will have been automatically and silently disallowed by AlbumPlays, so no AlbumPlays action is required in this situation. However, if you do see the “Duplicated Plays” warning message illustrated above, the timestamps will have differed, and will have made their way into AlbumPlays to overstate your MediaMonkey play counts.
If you want to correct this error, the Track Maintenance section describes how to display all the individual scrobbles for a track, and to delete any unwanted plays.
If you don’t care about the possibility of duplicated scrobbles coming in from your Last.fm history, you can permanently suppress the warning message as described in the AlbumPlays configuration documentation.
This section covers the case where you are using AlbumPlays in Last.fm mode, or when downloading non-Sonos plays from Last.fm.
It doesn’t apply to Spy observations from Sonos units, as that mode is better equipped to detect and handle tracks played from streamed music services.
Open the following “Spy mode” drop-down section to see which of this applies to your Sonos plays from streamed services.Click here if you are a Sonos owner in Spy mode
- the comments in this drop-down section only apply to Spy observations of tracks played using your Sonos equipment
- these comments do NOT apply to scrobbles which have been downloaded from Last.fm, even if you are in Spy mode
- the application knows whether or not a track has been streamed if it was played on your Sonos; it does not need to make any assumptions
- AlbumPlays does not designate any Sonos play as being streamed based upon tag mismatch conditions
- this removes most of the concerns regarding plays which have been designated as being streamed
- therefore the GUI Express Wizard does not require that you confirm the existence of streamed plays within the fresh batch of Spy observations
- the list of Streamed plays is still available from the Status Report tab
- unmatched plays from a streaming source are still a concern if you stream content which you also own, perhaps even more so, as the tagging quality and protocols at the streaming service provider may differ from your own increasing the chance of mismatch
- fix any unmatched observations arising from Sonos play from a streamed service as described elsewhere
_________ close Spy mode dropdown___________
There are two issues arising from streamed scrobbles:
- Playing tracks which you don’t own, from a streamed source, will generate a lot of unmatched scrobbles. These can swamp and hide any scrobbles of your own tracks, which were unmatched for some reason
- AlbumPlays attempts to address this by detecting tracks which appear to have been streamed, and filtering them away from view in your action list of unmatched scrobbles. If the assumption that a scrobble was streamed is incorrect you could fail to detect the mismatch, meaning that the play would not be recorded.
AlbumPlays can warn you if the current batch of fresh scrobbles from Last.fm contains any unmatched scrobbles which are assumed to have been streamed. … I say assumed because Last.fm doesn’t record the source of the tracks which you have played, so the actual source is uncertain.
AlbumPlays will optionally assume that a track has been streamed if *both of the following conditions are true:
- the track tags are unmatched against your MediaMonkey database
- AND neither the album, nor the artist, are featured in your MediaMonkey database
It makes this assumption in an attempt to reduce the clutter when you are trying to deal with mismatches. It filters away any suspected streamed items, allowing you to better focus just upon any of your own tracks which remain unmatched for some reason.
This assumption does create the potential that a false assumption could lead to some unmatched scrobbles from your own tracks being silently filtered away. This would suppress those tracks from being uploaded to MediaMonkey. There is relatively little chance of this occurring, as it can only happen if both of the above two conditions are met.
There is a safety net aimed at further minimising the risk of plays being silent ignored. By default the application pauses, and requires you to acknowledge the streamed tracks warning message, to confirm that the assumptions made by the application are correct. If you listen to streamed material upon a regular basis you may want to turn this feature off.
If you leave this safety net active, to bypass the warning message, you need to check the check box, and then press the Run button again.
To assist with this decision you can display a list of the tracks which have been assumed to be streamed using the Streamed Scrobbles button on the GUI’s Status Report tab.
The filtering away behaviour mentioned above means that:
- these tracks are not included in the Unmatched warning described above
- these tracks do generate entries into your unmatched scrobbles action list, but these rows are initially hidden from view so that you can focus upon those unmatched tracks which are more likely to be from your collection
You should fix any tracks that you notice where AlbumPlays has made an incorrect assumption. You do this by updating the rule template which has been generated for this track, but which is initially filtered from view.
To disclose any filtered template rules you toggle to the streamed tracks display by pressing the F5 key while editing the rules (ie. using either the Edit|ActionListAlbumBasedRules or Edit|ActionListTrackBasedRules menu item.
- update the template to reverse the “streamed” designation
- and flesh out the template to allow the scrobble to be successfully matched against your tracks tags.
The template updating process is described here
You only need to to do this once, as the completed template will become a rule. When the track is replayed, either from your own library or from a streaming service, it will be successfully matched, and therefore will no longer be flagged as a unmatched streamed play.
further information regarding template filtering is here
You can reconfigure AlbumPlays to turn off some elements of the handling of unmatched streamed plays:
- turn off the logic which makes the streamed track assumptions
- and|or turn off the need to approve the warning message regarding the presence of unmatched plays which have been assumed to be streamed
next step : Track Maintenance
back to top : Last.fm mode index
The Resurrections facility may not detect all lost scrobbles. The known restrictions are:
- it will not detect tracks lost from the very end of an album — it cannot distinguish tracks lost from the end of an album, from a situation where you quit the album before completing it — so scrobbles lost from the end of an album remain lost
- it will only detect lost scrobbles from albums — ie. it can’t detect lost scrobbles if you are playing from a playlist of non-connected tracks
- it will only detect lost scrobbles if you are playing the album in its natural track number sequence
- at the moment it only reliably detects lost scrobbles when there is just one single Sonos zone, or group, actively playing music. — ie. it may not detect lost scrobbles if you have several independent Sonos zones or groups playing from different albums at the same time — I may fix this at some stage. Let me know if you are affected by this limitation.
- nb: the resurrections action report can appear somewhat confusing if the fresh batch of scrobbles contains multiple plays of an album with resurrections. Each resurrection is displayed on its own row, so that you can confirm or suppress each individually, but the any contextual rows, showing tracks which were not lost, display only once regardless of how often they were played.