MobileSheets Forums

Full Version: Find Missing Files
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
- "Find missing files" takes very long on Win10 (whereas it's lightning fast on Android)
- the buttons "Collapse All", "Expand All" on the results window don't work
- a possibility to save the results of "Find Missing Files" into a file would be helpful
"F11" to switch to "desktop mode" doesn't work in several situations:
- when "Settings" is the current window
- when the result of "Find Missing Files" is displayed
I'll look into those issues. There is little I can do about the slow file access though - that's one of the downsides of Microsoft's API for file access with UWP apps.  I will see if switching to a different file retrieval method is any faster.

My understanding so far is that MSP can access only files in the path specified as "MobileSheets Storage Location", files from other locations are copied there during import. Correct?
Is there any difference in  performance depending on the location of the "MobileSheets Storage Location" (other than the respective drive's speed)?

You might want to take a look here:
The storage location should make no difference whatsoever. That link shows how to query for a list of files, but what I really want is to check if a single file exists (so that I can iterate over each file in the library to check for its existance).  I suppose I could query for every file in the storage location (which could be a massive number of files if someone specified something like the entire C: drive), and then have to create a dictionary of file paths so that, for each file in the MobileSheets library, I can see if it exists in that dictionary. I don't know if that would be any faster, but it would definitely be a little more convoluted that just calling a file.Exists() type method, which is what I'm doing now. For each file, in order to check if it exists, you have to use the parent folder and call GetFileAsync(). This is a fairly slow operation, which is the problem. There is also a TryGetItemAsync, which I'm going to test to see if it's any faster, but I believe the difference is minimal. 

As a side note, I just tested this on my PC with a library containing 632 songs, and the find missing files search returned in under 2 seconds. How long is it taking for you? That doesn't seem unreasonable.

Turns out that the more files are missing, the slower it goes. That at least gives me a way to test it with the current slowdown.

My programming experience has shown that, when there are a "lot of files", it is quicker to get a directory list and match the songs against that.

Assuming that the database contains the relative path for each song, the fastest way is probably to preprocess the database generating a list of "relative paths". Then generate a cumulative directory list  (using FirstFile/ NextFile type functions or whatever your programming language provides) of each relative path. Sort the cumulative list and use a binary search when checking to see if a song exists.

I found the reason why "Find Missing Files" was so slow. Using the correct workflow it's fast enough.
Thanks for your investigation.
Here's what I'm doing:
- My main active library is on an Android tablet with song files in SD0/_MobileSheets and SD1/Android/data/com.zubersoft.mobilesheetspro/files/
- I synchronize all the files and folders manually to an equivalent folder structure on a Win10 device in
- the database on Win10 is
- I copy mobilesheets.db from the Android device
- I manipulate mobilesheets.db using from Sciurius' MSPro-Tools so that it matches the Win10 folder structure
- I copy the resulting mobilesheets.db to the Win10 device in the path as above
- I check the database with "Find Missing Files"

When the MSP folder is the default ...\LocalState "Find Missing Files" takes 45 seconds to detect one missing file out of 1154 songs.
When the MSP folder is d:\HerbertsGoogleDrive\_MobileSheets\ "Find Missing Files" takes 8 seconds for the same result which is absolutely sufficient.

It's a bit tricky to set the MSP folder because usually there's already an existing database before.
- I call "Clear Library" and do NOT check "Delete All Song Files"
  (I would prefer unchecked as default by the way)
- I set the MSP folder as required
- I close MSP
- I replace mobilesheets.db
- I restart MSP
voila - everything is working fine
Here's the batch file that I use to adapt mobilesheets.db.
That's probably not for everyone, you should know what you're doing if you want to try it yourself.

Many thanks to Sciurius for his great MSPro-Tools.
So it turns out the slowdown had nothing to do with file access (which I did optimize a little but had little impact). It was due to major inefficiencies with the third party control I was using to display the entries. I switched to a ListView based implementation provided by Microsoft, and now it's much faster. Hopefully this will help users even without changing the storage location.

As a side note, you should have been able to move the storage location from inside the app without having to go through all those steps...

> As a side note, you should have been able to move the storage location from inside the app without having to go through all those steps...

I could have changed the storage location, that's true. But there were already 1100 songs in the database that were already at my new storage location. I could not avoid that MSP wanted to move the files. So I had to clear the database befor changing the storage location.
It would be nice if the current Mobile Sheets Storage Location would be displayed on the settings page as it is the case with the current values of e.g. "Language" or "Page Color Tone"
So possibly these other findings are also caused by this control and are bound to be changed in a following version:
- Expand All, Collapse All don't work
- the Cancel button during detection of missing files doesn't work as expected
- after "Cancel" the missing files so far are not displayed. There's only all or nothing
Expand/Collapse all do appear to work correctly with the new control. I'll have to look into the cancel button issue some more, but for me it takes less than two seconds to find the missing files, so I'm not sure that is a huge deal. Hopefully it will work that quickly for you now as well.

Really fast. Thank you.
Expand/collapse works fine now.
Cancel is as before. You're right, that's not an issue anymore when "Find Missing Files" is fast enough.

But: "Find Missing Files" is unusable now, it reports almost all songs as missing.
The songs in MSP are working fine, the report of "Find Missing Files" shows the same path as the song editor where the files really exist.
Very strange: When I click a song in the report it shows an error message (probably from Windows) that refers to a completely different path.
It's an old path that I used a while ago with MSP on Win10, but the PDF that I clicked was never stored there and it was never used as MSP storage folder.
This is a new issue in 1.9.7 and did not happen in 1.9.6
See screen shots.
What I tried so far with no change:
- I used a new mobilesheets.db copied from MSP 1.9.7 on Android
- I applied "Clear Library" before copying mobilesheets.db again
- I deleted all *.db files in the LocalState folder before copying mobilesheets.db again
Pages: 1 2