Additional Tagging & Reporting Tools

[phred]

Testing a full backup on my 18,000+ tracks took almost one hour and 15 minutes. About 30 minutes longer than the previous version.

Try again after completely deleting tag backups folder and the plugin's settings file in appdata folder.

I had deleted the backups folder before trying a full backup today, but not the settings file. So now I've deleted them both and started another full tag backup. Will report back later today.

Full tag backup took just under 50 minutes. So that's much better than earlier today. Only thing that I changed was the deletion of the settings file.

[phred]

I have autobackup set for 90 minutes. I have changed some tags after the full back and before the autobackup. This error is being thrown

Code

10/16/2016 6:03:56 PM - 6.1.7601.65536 - 3.0.6130.40302 - System.NullReferenceException: Object reference not set to an instance of an object.
   at MusicBeePlugin.Plugin.regularAutobackup(Object state)
   at System.Threading.TimerQueueTimer.CallCallbackInContext(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.TimerQueueTimer.CallCallback()
   at System.Threading.TimerQueueTimer.Fire()
   at System.Threading.TimerQueue.FireNextTimers()
   at System.Threading.TimerQueue.AppDomainTimerCallback()

[phred]

I have autobackup set for 90 minutes. I have changed some tags after the full back and before the autobackup. This error is being thrown

Code

10/16/2016 6:03:56 PM - 6.1.7601.65536 - 3.0.6130.40302 - System.NullReferenceException: Object reference not set to an instance of an object.
   at MusicBeePlugin.Plugin.regularAutobackup(Object state)
   at System.Threading.TimerQueueTimer.CallCallbackInContext(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.TimerQueueTimer.CallCallback()
   at System.Threading.TimerQueueTimer.Fire()
   at System.Threading.TimerQueue.FireNextTimers()
   at System.Threading.TimerQueue.AppDomainTimerCallback()

New tracks and new tags have been added since the last (only) full backup. Auto-backups do not run. Or if they do, nothing has changed in the Tag Backups folder. The error above seems to happen when the plugin is attempting to run the auto-backup.

Now, when I right-click on a new track that wasn't in the original, full backup, and then select 'tag history' this error is thrown. Perhaps it's because the track doesn't exist in the full backup. However, I am also getting this error when trying to see the tag history for a track that was part of the original backup.

Code

MusicBee v3.0.6135.34867 (Win6.1), 18 Oct 2016 21:35:

System.NullReferenceException: Object reference not set to an instance of an object.
   at MusicBeePlugin.TagHistoryPlugin.fillTable(String folder, Boolean includeSubfolders, Int32 maxBackupCount, Int32 trackIndex, Boolean reuseCache)
   at MusicBeePlugin.TagHistoryPlugin.TagHistoryPlugin_Shown(Object sender, EventArgs e)
   at System.Windows.Forms.Form.OnShown(EventArgs e)
   at System.Windows.Forms.Form.CallShownEvent()
   at System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry tme)
   at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
   at System.Windows.Forms.Control.InvokeMarshaledCallbacks()

[boroda]

phred, redwing, i'll try to experiment myself first, because right now i'm not sure what to log in debug version. null reference exception can't depend on library size, its something else.

[boroda]

phred, auto- or manual-backup won't be actually started until any previous backup is completed, but should see some info in statusbar about backup in progress.

[phred]

phred, auto- or manual-backup won't be actually started until any previous backup is completed, but should see some info in statusbar about backup in progress.

Yes, I understand that. If a full backup takes about 60 minutes, and I have auto-backup set for 90, there shouldn't be an issue, correct? And if I change tags, or add new tagged tracks, and leave MB open, auto-backup should run. I have seen an indication of auto-backup running in the statusbar, but when complete there's no new file and checking the error log shows the first of the two errors I posted yesterday.

[boroda]

hope this error with null reference is fixed now. also 1 new option for backup settings and backups must be smaller now (maybe even faster, not sure).

http://www.mediafire.com/file/darerwuapbiwbfm/mb_TagTools_2016-10-19.zip

[boroda]

forgot to mention: new version is not compatible with old backups.

[phred]

hope this error with null reference is fixed now. also 1 new option for backup settings and backups must be smaller now (maybe even faster, not sure).

http://www.mediafire.com/file/darerwuapbiwbfm/mb_TagTools_2016-10-19.zip

Great! Downloaded and installed. Will be starting backup shortly and will report back later today.

forgot to mention: new version is not compatible with old backups.

Good to know, but I always remove previous backups (and settings) with each new version you issue.

[phred]

hope this error with null reference is fixed now. also 1 new option for backup settings and backups must be smaller now (maybe even faster, not sure).

Encouraging results! Previously just over 18,000 tracks took just over 60 minutes for the initial backup. Now, with just over 19,000 tracks the initial backup took just under 50 minutes. IIRC, the previous full backup (18k+ tracks) was over 200mb in size which this new one is 128mb. Also, selecting a track and evoking the 'tag history' not only doesn't throw an error, but it completes very quickly.

I've added some new tracks and am now waiting 90 minutes for the auto-backup. I noticed the new option to not skip auto-backup and have enabled it.

I'll keep an eye out for the 'null reference error.'

EDIT: Also no error thrown when looking for 'tag history' of a newly-added (not yet backed up) track. All-in-all this latest version is looking much better.

[boroda]

phred, just a note: all backup files can be very efficiently compressed by ntfs (up to 4 times in my case), but i'm not sure about cpu usage and backup/restore speed for large libraries.

-----------------

new plugin version 4.18 (2016-10-19-2). i've added new command 'create new baseline of current library'. there will be info/warning window displayed. also window sizes/positions remembering is turned on now again.

this version will be new stable release if (edit: NO) new bugs are found:

http://www.mediafire.com/file/3wnrs9g14agy26w/mb_TagTools_2016-10-19-2.zip

and latest source code:

http://www.mediafire.com/file/rqhjf2em3qmewt7/TagTools_2016-10-19_20.40.39.rar

[phred]

phred, just a note: all backup files can be very efficiently compressed by ntfs (up to 4 times in my case), but i'm not sure about cpu usage and backup/restore speed for large libraries.

I'm not really concerned with file size as I've got many TBs of space. I brought it up because you stated file sizes will be smaller, so I was confirming.  :-)

new plugin version 4.18 (2016-10-19-2). i've added new command 'create new baseline of current library'. there will be info/warning window displayed. also window sizes/positions remembering is turned on now again.

All sounds good. Thanks for adding this feature to what I think is the most downloaded plugin for MB.

[redwing]

Just tested the first version with a 12,000 tracks library again. Backup time and CPU usage were almost the same as the previous version - the initial backup took 5 mins and each incremental backup (either manual or auto) took 12 mins (5 mins for writing + 7 mins for comparing). CPU usage was always 7 to 8%, never exceeding 9%.
The problem is tag history command. It no longer throws the error, but it doesn't work smoothly. It takes noticeably longer time to load whenever a backup is added, and consumes CPU over 30% percent. Only with three backups, it takes 6-7 secs to load and the app window looks almost not responding during that time. Not sure it could handle more than 10 backups reliably.

[redwing]

- If there were changes, show those tags and values only on the popup window upon clicking on the command.

This is what I suggested. But currently it shows all tags, not just changed tags. Then the user has to read all tags to find out what's changed.

changed tags are highlighted by blue-grey color (except for artworks).

Still I think it would be much useful if the tag history table shows only backups with any changed tags (instead of all backups) and changed tags only (instead of all tags). The more backups you have, the harder it gets to browse what tags have changed.

[boroda]

Just tested the first version with a 12,000 tracks library again. Backup time and CPU usage were almost the same as the previous version - the initial backup took 5 mins and each incremental backup (either manual or auto) took 12 mins (5 mins for writing + 7 mins for comparing). CPU usage was always 7 to 8%, never exceeding 9%.
The problem is tag history command. It no longer throws the error, but it doesn't work smoothly. It takes noticeably longer time to load whenever a backup is added, and consumes CPU over 30% percent. Only with three backups, it takes 6-7 secs to load and the app window looks almost not responding during that time. Not sure it could handle more than 10 backups reliably.

i'm afraid i can't optimize speed more.

Still I think it would be much useful if the tag history table shows only backups with any changed tags (instead of all backups) and changed tags only (instead of all tags). The more backups you have, the harder it gets to browse what tags have changed.

i think its not too difficult. maybe in a couple of days.