Additional Tagging & Reporting Tools

[redwing]

So you're not gonna use MB-created iTunes xml file?

[redwing]

I thought it would be useful for importing data from backed up MB-created xml files or iTunes/MM-exported xml files. But I guess that can be handled by MB as now.
Yes, use your own format as long as it can backup and restore tags.

[boroda]

the problem is that mb api doesn't provide any way to work with importing/exporting any files. there is no way to force mb to write itunes xml file or read it. and i dont want to ask Steven too much, i today sent him a wish for giving me access to all mb templates already.

but (auto)backup/restore tags and 'tag history' written in my own format (more precisely in .net class serialization format) is not a problem at all.

[redwing]

I understand. Managing iTunes xml files is not a must-have feature. This tool can be useful enough on its own.

[boroda]

yes, i got your position. just for the record, there is one big problem with itunes xml: i'm pretty sure that this format doesn't support for custom tags at all. no need to answer this my post, it was just a note.

[redwing]

MB-created xml file saves custom tags too.

[boroda]

i'm really surprised.

[redwing]

What happens if music files are moved to a new drive?
Would it suffice to run remap music files with MB, or the user has to edit backed up xml files?

[boroda]

saving/reading backups is not implemented yet (now only ui is ready). i was going to use track file paths as track identifiers. another possible solution is using some guids generated by plugin, but its a harder to implement solution. do you think its important issue? i want to decide this question before i start to write saving/reading functionality.

[redwing]

If it uses file path as a track identifier, it won't recognize existing files even with a slight change in auto-organization rule. Some more advanced method is needed. The best way would be using MB's own track id (if accessible) then people would only need to run remap music files command with MB when music files are moved to a new drive and the plugin will keep recognizing them as existing files. If it's not accessible, the plugin needs its own remap command in addition to more advanced track identifiers.

[boroda]

If it uses file path as a track identifier, it won't recognize existing files even with a slight change in auto-organization rule.

you are quite right. thank you that you asked this question early. mb supports for hidden custom tag which can store multiple custom ids for various plugins. this tag is used by ipod driver and google play music plugins. this approach reacquires very many workarounds to make sure that ids are generated for all tracks (ids should be somehow generated on 1st run of plugin, plugin can be temporary disabled, so library should be scanned for empty ids on every start, track moved from inbox to library must be intercepted to generate id, etc.), but file paths as ids are unacceptable.

there is another important question concerning 'tag history': should plugin cache (load to memory) all backups on startup or only information for this track should be loaded on right-clicking on track? its a 'speed vs consumed memory' question. considering that 'tag history' menu item must be disabled if there are no backups for this track, there may be temporary freeze just on right-clicking on track. tags might not to occupy much memory by themselves except for artworks. but what if there are 100's of backups?  the problem is that there is a limit on available memory: only 2gb for 32-bit apps. what do you think about this?

[redwing]

should plugin cache (load to memory) all backups on startup

I don't think this would be necessary.

or only information for this track should be loaded on right-clicking on track?

Yes, I'd expect it would work this way. Also selecting multiple tracks won't show the command.

but what if there are 100's of backups?

I don't think in general people change tags that quite often. If the plugin keeps a master data file, it only needs to record new changes when a back up is made, then there won't be much new data to save each time. So the number of backups itself won't matter much.

[redwing]

Also consider not supporting inbox files for tag history feature as they would increase data to store tremendously but most of those data would be useless because that's what inbox is for. But each back up file should include those.

[boroda]

Also consider not supporting inbox files for tag history feature as they would increase data to store tremendously but most of those data would be useless because that's what inbox is for. But each back up file should include those.

yes, of course. i was planning to make things this way from beginning.

[boroda]

I don't think in general people change tags that quite often.

no, the problem is that context menu will contain 'tag history' command and this command must be enabled or disabled depending on is there backup data for this track or not. i.e. even if user uses context menu for other purposes than 'time machine', there can temp ui freezing anyway. though i may not disable 'tag history' command even if there is no data.