Applicable in Last.fm mode? : yes
Applicable in Spy mode? : mostly … for Spy observations of your Sonos equipment, it is known when a track was streamed, so you may ignore discussion about the need to deduce whether or not a track was streamed, excepting when importing your non-Sonos plays from LFM
- Unmatched scrobbles
- Force-closing a batch
- Resurrected and lost scrobbles
- Duplicated scrobbles
- Streaming Wizard .. (optional)
- Streamed scrobbles .. (default behaviour)
Unmatched scrobbles are track plays which can’t be matched to a track within your MediaMonkey database. AlbumPlays 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 have not wished to adopt it into MediaMonkey
- Last.fm “corrected” (ie. altered) your scrobble tags
- your tags are too long, so either Last.fm (or Sonos) cut the end off from your tag
- maybe you changed the track’s tag after you scrobbled it, so MediaMonkey tags are now different to when you scrobbled the play
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 translating tags from the current scrobble, and from any future scrobble for the track or album, so that they may be matched against 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, and don’t wish to adopt
- or use the optional Streaming Wizard step with the AlbumPlays Approve action to adopt, or permanently ignore, a streamed track or album
- 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. (nb: a retry is built-in for the 4th option). The batch will be automatically closed if all mismatches are now resolved.
Force-closing a batch
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 missing track, 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, amongst 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 back 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.
The Streaming Wizard is an optional addition to AlbumPlays’ regular Approve processing action. The Wizard is aimed at simplifying the handling of unknown streamed items.
It is turned off by default, and is best left off if you are in the process of seeding your database from historic scrobbles. Once you have reached your current scrobbles, you may consider turning it on, if you listen to tracks from a streaming service, especially from Google Play Music.
The Streaming Wizard will pause the normal Approve action if it finds track plays which cannot be matched against your MediaMonkey database. The situation varies slightly, depending upon the source of the track play:
- either the unmatched scrobble has come via Last.fm; … since LFM doesn’t record the play source, this unmatched scrobble may, or may not, be a streamed play … the scrobble may just be a local play of one of your own tracks, but has unrecognisable tags for some reason
- or this is a Spy observation of a Sonos track play; in which case we know that it was a streamed play, but we can’t determine which track was played … maybe it is not in your MediaMonkey database? … or maybe it is in there, but AlbumPlays needs some assistance to resolve mismatched tags?
In both cases the Wizard lists the unmatched items to give you opportunity to do something about any of them which were streamed. Your options for each row include:
- do nothing; either the play was not streamed, or you just don’t want to do anything about it right now … the unmatched play will be pass through to the default logic for unmatched scrobbles
- or you may “adopt” the streamed track or album (only available if you streamed from your Google Play Music library) … ie. instruct AlbumPlays to load it into your MediaMonkey database, so that its play history may be tracked, and you can use it in playlists … the scrobble will become matched, for this, and any future plays
- or you may ‘hide” the track or album … ie. tell AlbumPlays that the item is indeed from a streaming source, and that you want AlbumPlays and MediaMonkey to silently ignore this, and any future plays
If you made any updates, close the Streaming Wizard panel via the “Update” button, or the F3 key. If you made no updates, you may just close the window with the Windows red “x” on the top right corner, or press the F4 key to cancel without update.
Once the Streaming Wizard panel is closed, the Approve action will continue processing. If there were updates, there is an an attempt to resolve unmatched items, taking into account new information that you have just provided. The normal processing cycle then takes over:
- either your Streaming Wizard update has resolved the mismatches, in which case you are all done
- or mismatches remain, in which case you may resolve mismatches with the action lists, or ignore them by forcing closing … nb: the following section describes AlbumPlays’ default behaviour with regard to unmatched streamed scrobbles
For the following illustration of the Streaming Wizard, I played tracks from two albums which I don’t own, and then one track from an album which I do own, but I retagged it immediately after scrobbling, to simulate a tag mismatch situation:
I have AlbumPlays configured as follows:
- I have turned the Streaming Wizard ON, or here if in Spy mode.
- I have configured myself as being a whole_album listener (ie. not a mixed-tracks listener) … this affects the layout of the Streaming Wizard … and any actions that I take on the Streaming Wizard panel, will affect the whole album from which the track came … (with the other option, Streaming Wizard adoptions, or instruction to hide, will only affect the nominated track)
- I have completed the set-up steps required to be enable adoption from Google Play
AlbumPlays detects that unknown items have been played, and that I have enabled the Streaming Wizard:
- it pauses the Approve action, and displays the Streaming Wizard panel, and waits for input.
- the Streaming Wizard has a row for each unknown “item” which was played … if you registered yourself as being a whole-album player there will be a row per unknown album, otherwise there will be a row for each unknown track
- for each entry, you have up to three choices:
- do nothing, in which case the scrobble will continue to be ignored … if you play the item again, the same thing will reoccur … ie. where the item was from a streaming source, the implication is that you are continuing to audition the item, and you will decide later whether or not to adopt it
- “adopt” it … if the item is a known Adoption Candidate in your Google Play library, the row will have an “adopt” check-box … if you check this box, the track or album will be automatically added into your MediaMonkey database … this and any future plays will be matched, and recorded, just as if you owned the track … it will not re-appear in the Streaming Wizard
- hide the item, ie flag it as being “streamed” … the scrobble will be ignored, and any future plays will also be ignored … it will not re-appear in future Streaming Wizard panels or action lists … ie. it is a track which you stream but don’t wish to adopt … if you change your mind later, you may adopt the item using the Action menu option … or you may delete unwanted “streamed” flags via the Edit|StreamedRules menu option, so that the Streaming Wizard panel will show the item when it is next played
- I streamed the track by Badi Assad from Google, but it is not in my Google library, so the “adopt” check-box is visible, but not enabled … I checked the “hide” check-box, which will resolve the unmatched scrobble, meaning that this row will not cause the Approve action to be suspended waiting for further instructions … and this whole album will not cause any future problems due to mismatched scrobbles
- I also streamed the track by David Rawlings, and this one is in my Google library … I checked the “adopt* check-box … the whole album will be adopted into my MediaMonkey database
- I own the track by the Byrds,and this scrobble was generated from my own local track … because I re-tagged my track, before approving the scrobble, AlbumPlays has been unable to recognise the scrobble … an unrecognised scrobble may be a streamed scrobble, which is why it appears in the Streaming Wizard … I know that it is not streamed, so I ignore this row
- where you make any updates to the Streaming Wizard panel, you must close the panel via either the “Update” button, the F3 key, or the Navigation menu.
- when the Streaming Wizard panel is closed, the Approve action resumes processing
- if you made any updates, the Approve action’s match-up logic is retried, taking the new updates into account
There is an update log for any adopted items.
The intended use of the Streaming Wizard is as follows:
- add some tracks or albums into your Google library
- run the Google library update procedure in AlbumPlays. This does the following:
- if the new tracks were tracks which you uploaded to Google, they need to be matched to your own tracks, so that we learn the IDs which Google assigned to their copy of your tracks
- if they are tracks from Google’s subscription streaming service, AlbumPlays needs to detect them, so that it can add them to its list of Google Adoption Candidates
- audition the tracks or albums … ie. play them
- AlbumPlays’ regular Get|Approve cycle will detect any unknown plays, and if you have activated it, the Streaming Wizard panel will be displayed, causing processing to pause, to wait for your input
- you may ignore any of the items, or you may adopt or hide streamed items
- the Approve action resumes, taking into account any Streaming Wizard updates
- if unmatched items persist, you may deal with them as described here
This section describes AlbumPlays’ default behaviour with regard to unmatched plays from Streaming sources (ie. plays of tracks which you don’t own, and are not in your MediaMonkey database).
nb: this default behaviour may be enhanced by enabling the Streaming Wizard which is described above
This section covers the case where you are using AlbumPlays in Last.fm mode, or when downloading non-Sonos plays from Last.fm. In these situation AlbumPlays has to try to deduce whether a scrobble has be played from a streamed source, as Last.fm doesn’t record the music source.
This does NOT 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 which you could fix
- 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 can optionally assume that a track has been streamed if all 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
- AND you are importing scrobbles from Last.fm (ie. not importing track IDs from your Google Play library)
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 track plays 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.