[Snard]

I'm not sure if this is a "bug" or just a side effect of the options I selected when I restored, but I'll describe what I did, what happened, and whether there is a way to prevent this if I have to restore again.

As I mentioned in another topic, I recently bought a new tablet (Nexus 10, which btw is fantastic with MobileSheets! End of commercial ). My first order of business was to transfer my 600 song library to my new tablet, so I backed it up (using the Android app backup function), copied the backup file to the new tablet (via USB) and then did a restore on the new tablet (again using the Android app function for that). For the Backup command, there is only one option available, to include audio files. I have none, but I unchecked the box anyway. For the Restore command, there are a number of options: Restore To location, Create Subdirectory Per Song, and Delete all existing files in default storage location (Recommended). In retrospect, this is probably where I went wrong, but I digress. I picked the default settings for all of these (Default Location, and both boxes checked). I considered one of the other settings for Restore To, but I went with Default Location for two reasons: 1. My sheet music directory on my old tablet had gotten rather cluttered over the many months I've been adding songs. Some were in their own subfolders, but a large number were in the root directory of my Removable Storage folder. And 2. Since my new tablet is a different manufacturer / Android version (and doesn't have a physical SD card slot like my old one did) I didn't want to use "original file locations" in case that didn't exist. (although I think it would have been okay since I took the precaution of creating the same Removable Storage Location on the new tablet as I was using before)

Okay, big long winded intro. I did the restore, and here is what happened. 99% of my songs were fine Even annotations and link points were present and accounted for, which I thought might be an issue because of screen resolution differences (1280x800 for the Thrive, vs. 2560x1600 for the Nexus 10). The only songs that had issues were ones where I was sharing a single PDF among multiple songs (i.e. the PDF contains multiple songs, and I had created songs which selected a subset of pages). What happened is that one of the songs would load fine, but the others would give an error saying "Unable to locate file". When I went to edit mode on the failing songs, I discovered that the "create folder per song" logic had caused it to create invalid file paths for some of the songs. Let me give an example: Assume that the PDF is called album.pdf, and there are 3 songs named Song1, Song2 and Song3. On my original tablet, each song pointed to /somelocation/album.pdf. But after the restore on my new tablet, the three songs point to /Song1/album.pdf, /Song2/album.pdf and /Song3/album.pdf, respectively. And the PDF file is only present in one of the song folders. (You might recall that I submitted a bug request a while back, that backup operations would include multiple copies of the same PDF file when they were being shared in this manner. So I guess this bug request has come back to bite me )

I was able to fix the issue by going to edit mode on the bad songs, deleting the PDF path that wasn't there and re-adding it from the good location (i.e. the first song). But in a few cases, this deleted my annotations and link points for those songs. In a couple cases I was able to use the "Swap PDF" function to point to the right PDF location again, but I noticed that this option is greyed out much of the time. Do you know why this would be?

Sorry for the long winded explanation, but I wanted to give you as much information to go on to decide if this is a bug or a feature, and if things would have gone more smoothly had I chosen different options for my restore. As it turns out, another choir member is getting a tablet soon, and I will be setting up his initial library via a restore in the same way I've just done, so I want to work out the kinks before I have to do this again. Any suggestions would be most welcome.

Thanks
- Mike

[Zubersoft]

Definitely a bug Mike. I'm hoping to get an update out today if possible (it will include dropbox support thanks to another developer who has been helping me), so I will make sure this is fixed. I really appreciate your detailed write-ups. They make it very easy to know what I need to do to replicate the problem, and half the time I know what the problem is just based on your details.

As for the swap PDF issue, I believe the code just checks to see if the song is actually using a PDF file, and not an image file, before it enables the option. If you are seeing it disabled for songs that use PDFs, then I think there is definitely something wrong there. I'll test this today as well.

Thanks,
Mike

[Snard]

Definitely a bug Mike. I'm hoping to get an update out today if possible (it will include dropbox support thanks to another developer who has been helping me), so I will make sure this is fixed. I really appreciate your detailed write-ups. They make it very easy to know what I need to do to replicate the problem, and half the time I know what the problem is just based on your details.

As for the swap PDF issue, I believe the code just checks to see if the song is actually using a PDF file, and not an image file, before it enables the option. If you are seeing it disabled for songs that use PDFs, then I think there is definitely something wrong there. I'll test this today as well.

Thanks,
Mike

Thanks for the kind words. I've probably mentioned before that I have a background in software development and QA, so I tend to describe things from a "how to reproduce it" point of view. I'm glad that I'm able to help correct these issues more quickly.

I've confirmed that the "Swap PDF" button isn't appearing for certain songs that do in fact have PDF files. I don't know the exact logic you are using for this, but I do have a request, especially in consideration of the current bug when doing a restore with shared PDFs. If a song "thinks" that it has a PDF, please allow the "Swap PDF" function, even if the PDF can't be found. This will allow currently broken songs to be fixed more easily.

While thinking about shared PDF songs, it occurs to me that even without the current restore bug, it may be possible for a song to become "broken" under the following circumstances:

1. Manually create several songs which share a common PDF
   
2. Delete one of the songs, leaving the "Delete Images/PDF" box checked
   

I don't know if the code will prevent deletion of the underlying PDF when it is being shared, but it would be nice if it did.

I just had a great idea while typing this message! If the code checks for shared PDF files when you delete a song, maybe it could also check for them when you do a Swap PDF. I.e. if there are 4 songs that point to a common PDF, and you do a Swap PDF on one of those songs, it could put up a prompt with all 4 songs, and let you check/uncheck which ones you want to update.

Mike

[Zubersoft]

I added code recently (v4.0.7 or v4.0.8) to address the deletion of files shared by multiple songs. I tested the code, and it seemed to work well. I think this is handled correctly, but it sounds like the backup changes really aren't. I really should have tested the backup/restore changes better.

Great idea about the swap. Maybe you can help write that code if you want Oh, and as a side note, the swap PDF function does check to see if the file exists, it just checks to see if the songs uses a PDF. The way Android handles context menus is funky though, so I had to do some interesting things to get enable/disable behavior to work the way I wanted. It's very likely that something got messed up in that code.

Thanks,
Mike