Housekeeping – tracks

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?

"Unable to upload" dialogue box

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:

Re-tagging

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.

tag synchronisation issues .. click to open

Why does this application has its own database?

The reason is to minimise coupling between AlbumPlays and MediaMonkey; allowing you to take upgrade versions of MediaMonkey independent of any AlbumPlays consideration, and vice versa. It also keeps open the possibility of porting this application across to other music databases in the future.

You say that it doesn’t matter that this applications gets out of step?

It is usually optional whether you update AlbumPlays’ database with your new tag values. They will be automatically reset to the correct current values when the track is next played. The discrepancy does not cause mismatches when you import fresh scrobbles, as the match up is achieved using the current values in your MediaMonkey database.

The key requirement is that MediaMonkey remains in synchronisation with the tags in your music tracks. You best achieve this by using MediaMonkey to do all track re tagging.

There are a couple of minor things which are affected by the temporary lack of synchronisation:

  • the main one impacts the facility used to transfer your play history across to new albums when you have upgraded to new track copies (eg. you buy a remastered copy of an album for which you already have play history).

If you get the “Unable to upload play counts MediaMonkey” message (illustrated and discussed above) it means that the databases have become out of synchronisation due to tracks being replaced with new copies, or by MediaMonkey recreating its entry for those tracks … ie. not just a few tags being out of sync.

The procedure to transfer your play history to the new tracks is described here. That procedure depends upon tag synchronisation between the AlbumPlays and MediaMonkey databases. The procedure will fail to clear the “Unable to upload..” message it the tags are not in sync.

If this happens you will need to manually alter either your MediaMonkey tags, or your AlbumPlays tags, to allow the transfer proceure to do its job. Run the audit reports (as described here) to identify which tracks are affected. Then compare MediaMonkey to the audit reports to identify the tag differences.

If you prefer your prior tags, use MediaMonkey to re-tag your tracks. … Or if you prefer the current MediaMonkey tags you need to retag your AlbumPlays history as described below.

Once you have made the tags equal again, you need to rerun the auto-sync transfer facility again.

How to manually update AlbumPlay’s history tag values

You may try to re-synchronise the whole database by running the Action|SynchroniseTrackTags menu item; this resets all of the tags in the AlbumPlays database to the current values of your MediaMonkey database

Or you can use the Edit|PlayHistory menu item to manually update the tag for a single album or track; this doesn’t change your track or MediaMonkey tags, it just updates AlbumPlay’s database.

Editing tags

collapse

 

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.

Tracks are missing

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.

Missing Tracks audit report

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.

Delete track or album play history

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.

display scrobble details, with optional delete

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”

Delete using MediaMonkey

Delete track *and* MM entry

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.

Replacement: impacts upon AlbumPlays

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.

Confirmation for fixed tracks

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.

Editing tags

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

  1. use the Windows Explorer to create any new directories that are required at the new location
  2. then open the source and target nodes in MediaMonkey’s Media tree as illustrated below
  3. drag the material to the new location
  4. 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)
  5. drag to a different location

Relocate using Windows Explorer

  1. drag the files or folders their new location using Windows Explorer
  2. then open MediaMonkey’s Dead Links node in the Media Tree at Music|FilesToEdit
  3. dead links node
  4. MediaMonkey will parse the database, and identify all tracks which are no longer found at their last known location
  5. missing files will be listed; select the albums or tracks that you moved
  6. then use MediaMonkey’s File|LocateMissing/MovedFiles menu option
  7. specify the top level directory of their new location; MediaMonkey will search within
  8. once the tracks are found, press Update to modify MediaMonkey with the new track locations
  9. reconnect the relocated tracks
  10. 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. configuring MM's File Monitor disabling MM's File Monitor

next step: Housekeeping: play history

back to top: LFM mode index
back to top: SPY mode index