This section of the Users’ Guide addresses track maintenance, and it’s impact upon the AlbumPlays application:
- “Unable to upload play counts to MediaMonkey” … what went wrong?
- re-tagging tracks
- deleting tracks
- replacing your tracks with new copies
- moving your tracks to a different location
“Unable to upload play counts to MediaMonkey” … what went wrong?
Nothing has gone wrong. AlbumPlays protects its database integrity by ensuring that it’s tracks remain linked to the master tracks in your MediaMonkey database. If it detects that something has happened in MediaMonkey which has broken the link for one or more tracks, it throws up the above dialogue box, and suspends the uploading of new scrobbles to MediaMonkey until the links are repaired.
I say that “nothing has gone wrong” because this is an expected situation. AlbumPlays links itself to the hidden unchangeable track IDs which are a part of MediaMonkey. Most tag changes will not break this link, however it will happen if you re-assign the track or album to a different or additional artist. It will also break the link if you delete a track, replacing it with another version or copy. The same thing happens if you move a track, with some tool other than MediaMonkey, and then cause MediaMonkey to re-scan the track at its new location. You will also trigger this situation by permanently deleting a track for which there is already AlbumPlays play history.
AlbumPlays was designed to expect these situations, and to rejoin the link to the replacement track without consequence. Once the link is repaired there will be no loss of play history, nor any sign that this occurred. This is usually done automatically, but you may need to give AlbumPlays some assistance in unusual circumstances.
The sync check is done as a normal part of the Approve action. If an out of sync condition is detected the above message is displayed, and the Approve action will be unable to complete until you have corrected the situation.
The method for the repair depends upon how you triggered the break:
- you deleted a track, or deleted it from MediaMonkey
- you replaced a track, or caused MediaMonkey to re-scan the track
- if you did neither; on rare occasions I have seen MediaMonkey spontaneously replace its own record of a track or album (maybe as part of its own self-repair mechanism?) … you should treat this as if you replaced the track
If you need to re-tag tracks in your collection you should do so using MediaMonkey. This will ensure that the MediaMonkey database automatically remains in-step with your track tags. This is important because your track tags are used to produce your scrobbles. Those scrobbled tags will need to be successfully matched against MediaMonkey’s version of the tags when importing scrobbles from Last.fm, and this relies upon those tags being synchronised.
AlbumPlays also has its own database, which is independent of MediaMonkey. Track re-tagging will cause this database to become a little out of date temporarily. … You don’t need to worry about this, as it will correct itself over time.
If see see the “Unable to upload Play counts MediaMonkey” message (illustrated and discussed above) you may need to re-tag your AlbumPlays history. Open the following closed section for more details about this condition, and for further explanation upon the subject of tag synchronisation.
Things to be generally aware of:
- before doing any track maintenance it is best if you do not have a batch of scrobbles still being processed by the Approve action step. The AlbumPlays GUI should be positioned at the Get action
- Sonos owners: when using AlbumPlays in Spy mode, AlbumPlays observes your Sonos zones to get the details of tracks being played, so there is no requirement for tag matching during the Get|Approve cycle. However you still should use MediaMonkey to do any re-tagging, as tag matching is required for any non-Sonos scrobbles imported from LFM, and MediaMonkey will degrade in value if it gets out of synchronisation with your tracks.
- Last.fm has no facility allowing you to re-tag its version of your scrobble history, so once you start scrobbling with a changed tag there will be a disjoint in your Last.fm charts and history displays (ie. historic scrobbles will displayed under the old values, and your future scrobbles will begin a new set of statistics under the new values)
- there will be no disjoint in your MediaMonkey database play statistics. Your MediaMonkey database will reflect your new tags, and fresh scrobbles will united with your previous plays
Deleting tracks or album
If you delete a track from MediaMonkey, one for which you have already downloaded and processed play history, you will also need to update the AlbumPlays database.
When you next run an Approve action, the application will detect that track(s) are missing, and will pop up the dialogue box shown above if you already had play history for the deleted item(s).
If you see the dialogue box, you should run the Audit reports which are mentioned on the pop-up dialogue box. The Audit Reports are accessible by clicking on the GUI’s Audit tab.
The report will list missing tracks or albums, or ones which have been replaced with new versions.
If that you:
- deleted the track(s) (ie. didn’t replace with a new or replacement copies)
- used MediaMonkey to do this (ie. did use the Windows Explorer or some other tool)
- and that the track(s) had some play history
Then you need to also delete them from AlbumPlays’ database via the the Edit|PlayHistory menu item as illustrated below. If you have replaced the track with a new copy you need to go here.
If you deleted the track itself, using the Windows Explorer or some other tool, neither MediaMonkey, nor this application, will notice that it is missing, so there is nothing you need do until such time when MediaMonkey notices the dead track link(s). It is best if you use MediaMonkey for all deleting and re-tagging operations, as this will automatically keep your MediaMonkey database synchronised with your music collection, and you get to house-keep your AlbumPlays database while your actions are still fresh in your mind. … You delete tracks via MediaMonkey be selecting the track(s), and then using Remove from the right click menu. You have the option to delete the track just from MediaMonkey, or to delete the music track(s) also.
Replacing tracks or albums with new copies
If you use MediaMonkey to replace an album or track, with a new version (re-mastered, or a re-ripped copy, etc), you will need to allow AlbumPlays to adjust itself if the track already had some play history. nb: if you use Windows Explorer to replace the track, into the same directory, with a track with exactly the same file name and track tags, then neither MediaMonkey nor AlbumPlays will not notice. This is an error prone procedure, and you are advised to avoid doing this.
AlbumPlays will notice MediaMonkey track replacements when you run the next Approve action, regardless of whether or not the fresh batch of scrobbles includes any of the replaced tracks. You will see the dialogue box which was illustrated at the top of the Deleting Tracks section above.
nb: On rare occasions MediaMonkey itself seems to spontaneously create replacement versions of tracks or albums, maybe something triggered by its internal house-keeping or error recovery. AlbumPlays will detect this, which will trigger the dialogue box, requiring this procedure before you can proceed.
For Sonos owners It is important that you remove the replaced track copies, as Sonos will only index a single entry for each unique tag set. If your Sonos finds duplicates, it will randomly select one of the copies, so you won’t have any control, nor knowledge, of whether you are using the old or the new version.
There are two halves to this procedure: the MediaMonkey side, and then the AlbumPlays side.
Replacement: impacts upon MediaMonkey (and Sonos)
If you wish to have both track versions available, make sure that use a different album (or track) tag name for each version. In this case there is nothing further to do. You will end up with both versions in MediaMonkey, and AlbumPlays will maintain independent play history for each .
If you want just the newest version, you should use MediaMonkey to perform the deletion, as it will perform the physical track deletion as well as also updating itself, keeping your track collection and MediaMonkey database in synchronisation – take option Remove from the right click menu, and then “Delete from Library and Computer”
If you want to keep offline safe copies of the old tracks as a precaution, you could move them to another location with the Windows Explorer and do the deletion (aka Removal) in MediaMonkey, using the “Delete from Library only” radio button.
Then add the replacement version into MediaMonkey using same procedure that you usually use to enrol new tracks (File|AddRescan is what I use)
Sonos Owners: Also trigger a Music Library update using a Sonos controller.
As stated above, AlbumPlays will need attention if the track replacement has been noticed by MediaMonkey. AlbumPlays will still be connected to the old MediaMonkey tracks. AlbumPlays needs to transfer its prior play history across to your new replacement tracks.
For it to be seen as a replacement which can be automatically handled by AlbumPlays, you need to have replaced the old tracks with new copies having exactly the same tags as those which were there before. If the tags are different it will appear as a deletion, and then the addition of some unrelated tracks. In most cases cases the tag values will be identical as they are obtained from the Internet when you ripped each copy of the album. … If there are differences it is easily handles as explained below.
Firstly try transferring your play history by running the Action|FixTracks and Action|FixAlbumKeys menu items. Where the new track tags are identical the history will automatically transfer. There are confirmation dialogue boxes summarising how many tracks or albums where affected. The Log File display show the details (the screen which goes black when the task ends), or you can display it via the File|ShowLogFile menu item.
After the transfer you should now re-run the “Approve” action.
If the Cannot upload dialogue box is re-displayed, this means that the tags did not match exactly. You need to run the Audit Report mentioned in the Deleting Tracks section above. This will identify the tracks which did not transfer. The report will display the old tag values, and you can see the new values in MediaMonkey. Change either the new tags using MediaMonkey, or the old ones using AlbumPlays’ Edit|PlayHistory menu item as shown below.
Run the Action|FixTracks menu item again once you have fixed the tags, and then retry the Approve action. It should now progress to normal completion.
Moving your music
If you need to move your tracks to a new location you should try to avoid having to delete them and re-add them back into MediaMonkey.
The reason for this is that the AlbumPlays database is an extension to the MediaMonkey database. These two databases are kept in synchronisation via hidden fixed keys, stored inside each track and album in MediaMonkey.
If you delete and then re-add material into MediaMonkey, it will be assigned different hidden fixed keys. This will break the synchronisation between the two databases.
AlbumPlays does contain a facility to rebuild the connection (as described in the Replacing Tracks section) but it is best to not break the connections in the first place.
The recommended procedure to handle track or album relocations is to either:
- use MediaMonkey to move the material
- or use Windows Explorer, and then use MediaMonkey to rebuild the connections
Relocate using MediaMonkey
- use the Windows Explorer to create any new directories that are required at the new location
- then open the source and target nodes in MediaMonkey’s Media tree as illustrated below
- drag the material to the new location
- if you drag all of the music material from the target location, MediaMonkey will offer to also relocate any other files in the source directory (album art, playlists, etc)
Relocate using Windows Explorer
- drag the files or folders their new location using Windows Explorer
- then open MediaMonkey’s Dead Links node in the Media Tree at Music|FilesToEdit
- MediaMonkey will parse the database, and identify all tracks which are no longer found at their last known location
- missing files will be listed; select the albums or tracks that you moved
- then use MediaMonkey’s File|LocateMissing/MovedFiles menu option
- specify the top level directory of their new location; MediaMonkey will search within
- once the tracks are found, press Update to modify MediaMonkey with the new track locations
- NB: MediaMonkey has an optional File Monitor facility, which watches directories that you specify, to detect and respond to additions, movements or deletions. If you are doing a significant restructure if is probably a good idea to turn the File Monitor off to avoid confusion.
next step: Housekeeping: play history