[GraemeJ]

Not wishing to pile even more stuff on to Mike, but I was doing a backup last night when a thought occurred to me-

The reason for the backup was simply because I had changed the order of a setlist - nothing else, just a few songs with a changed order. The backup went fine, but it does take some 15--20 minutes, as there's quite a lot of material, plus some audio files.

This set me thinking and I was wondering about the possibility of having some sort of incremental backup - those of you who backup their computers regularly will know what they are - as this would shorten the backup process by a considerable amount.

So, maybe this is something that could be put on the wishlist for a later version?

[Zubersoft]

That's a great idea Graeme. I think this will be do-able with the next update. This is the way I envision this working:

1) Under the Utilities in the options, there is now a "Update Backup" option. You select this, and it asks you to select an existing backup.
2) Due to the way backups are currently implemented (in a binary, packed format), I would need to tack on additional information at the end of the existing backup file.
3) The incremental backup that is added at the end of the original will contain an updated database along with commands such as "add new file", "update file", "delete file", along with the information necessary for that command. I can now easily identify changes to file in version 5 as i track the "date modified" value of each file.

This would allow the incremental backup to proceed pretty quickly, and would eliminate the need for lots of small incremental backup files. The only minor downside to this is that the library restore of a backup containing incremental backups at the end would be a little bit slower than just one regular backup file (may not even be noticeable).

It's a great idea, and I don't think it's a ton of work (probably a couple days worth), so I'll table it for when v5 is stable.

Thanks,
Mike

[GraemeJ]

Thanks for the quick response Mike. I certainly wouldn't wish v5 to be delayed for this, or any other new ideas that come along, but it would be good if it was kept in reserve for later.

How best to implement something like this, I leave to you - you have a much better idea of the current file structure than I do .

One thing I should add is that I never do a backup direct on the tablet, it's always done from the PC, using Companion. The eliminates the need for a USB link to the PC (which is where I prefer to keep the backup files).

If working that way, could you not make use of the Archive attribute, which is what PC's use to determine the files that have changed since the last backup? I know very little about the Android platform, so I don't know if a similar attribute is used in that file system but, if it is, then half the work is done for you.

Later:

A bit of research seems to indicate that there is no archive attribute in the Android file system, just a read only one, so that's the end of that idea . I suppose you could still use it when working in Companion, but that might be too limiting for some users (although Companion is so useful, I couldn't imagine why anyone would not want to use it).