[tbclark3]

I was able to test your work-around today because MobileSheets crashed while I was practicing. The proposed solution works, but it still requires taking at least one hand off of the keyboard in order to touch the screen, and at a time that may not be convenient. It also takes significantly longer than my proposed solution.  Please consider implementing an option to restore the setlist and page when opening.  You could even link it to performance mode. It would allow for a seamless recovery. 

For what it's worth, I'm now sure that on at least 3 occasions, including today, the crash has occurred while I was making a facial gesture that was potentially ambiguous.  I'm happy to help with testing if you can think of any way to do it, or if you can provide me with a version that does debug logging.

66,000 people didn't look at this page out of interest.  A significant number of them have probably experienced a crash, did a Google search, and ended up here, but didn't bother to add to the 5 pages of comments already present because they didn't want to have to go through the process of logging in.

[Zubersoft]

That is very important information - the face gesture is one of the most complex features because I'm utilizing a library from Google to do the facial analysis, and I don't have control over any of that specific code, so if it crashes, there isn't much I can do about it (except grab Google's latest changes and hope they've fixed whatever instability is occurring in their code). Can you please try turning that feature off and see if it resolves the crashes? Or is that feature critical for you? I just want to check, as it would be incredibly helpful to know if the crash stops with that feature turned off.

Mike

[Zubersoft]

I'm still not sure how relevant that metric is - bots scraping the page probably contribute to those view counts. There are 10 year old posts about a minor bug that was fixed that have 40000 views.

Mike

[BRX]

And probably quite a few users like me who read every post on the forum out of interest regardless if it's something one's concerned or not.

[tbclark3]

The facial gesture feature was game changing for me. I'm an organist and can't use foot pedals, and can't spare a hand most of the time. I'm not sure I can live without this feature, but I can try to practice without it the rest of the week. I will report back.

PS if scraping were responsible for the huge number of hits on this topic, or if there are lots of people who read every topic, then all of the topics would have this many hits, but they don't.

[Zubersoft]

I will say that the face gesture feature is generally more stable on normal Android tablets than Chromebooks I believe, at least on Chromebooks with an x64 processor (versus an ARM processor).

Mike

[mwiseman]

 I'm an organist and can't use foot pedals, and can't spare a hand most of the time.

You can get a Bluetooth switch that you hold in your mouth and bite. https://www.airturn.com/collections/assistive-tech/products/airturn-bite-switch-remote-controller

[tbclark3]

Mike, I practiced for awhile without facial gestures and MobileSheets didn't crash; however, I don't think it means anything because the total time wasn't sufficient. However, this morning when I was practicing with an instrumentalist and using facial gestures, it did crash in the middle of a page, and I wasn't aware of making any gestures at the time that it could have tried to interpret.

In any case, when it crashed, I tried getting back to the right place by touching the setlist--and it worked, but took way too long. I am asking again for you to mitigate this problem by creating an option to open MobileSheets in the setlist and on the last page that was being played. This option is needed no matter what is causing the crash.  If we wait until we figure out what is actually precipitating the crash (which might be never) then the option wouldn't be needed, but I desperately need it in the meantime. I have a concert coming up in about 2 weeks and I'm hoping that I don't get stranded with disappearing music in the middle of a performance again.

[Zubersoft]

I'll get the setting added for this update then.

Mike

[tbclark3]

I'll get the setting added for this update then.

Mike

Thank you! I don't think I could actually play any more without MobileSheets. Its design is excellent and I can't imagine living without it.

[tbclark3]

Mike, is there an ETA for the new release, or is there something I could test for you? I'm getting into a busy rehearsal schedule preceding a concert, and need to be confident that my music isn't going to disappear.

I've continued to do some testing. I have a lot of Android apps on my Chromebook, so I temporarily removed all of them except MobileSheets, and I had a crash anyway, so I don't think it's interference from another Android app.

I also think it's possible that there may be a connection between network connectivity and the crashes. This thread started with a hypothesis that 3G might be the culprit, but I'm wondering if it's broader than that. There is one venue where I use MobileSheets where I always have a Wifi connection, and one venue where I almost never do (unless I use my phone hotspot). Over the months, the crashes have been more common at the venue where I have a connection. I'm going to try keeping Wifi off when I'm there. It will take a while, probably weeks, to form any conclusions, but I am working on it.

[Zubersoft]

The Android side is basically ready, but I'm porting changes and I can't push out just one of the platforms due to the database changes creating incompatibilities between versions. So I'm just trying to get all the porting and testing done as quickly as I can. The code changes on Windows are almost done, so I just have to recreate the user interfaces on iOS and convert the code over. I'm always quite bad at giving estimates but I should have a better sense for where things are at over the weekend. If I'm able to make a lot of progress, then the release could happen towards the end of next week, but I won't promise that, as I can't rush this work. I tried to include far too much in this update instead of releasing multiple smaller updates, as people kept pushing for more things to be included. I usually try to prevent that as much as I can.

Mike

[Lawrie]

Hi Mike,
I've quite recently run into what may be a related issue.  It's happened 3 or 4 times in the last week:
I'd be just finished cropping a song, touch the "OK" to save and find myself either at the library screen, or MS would close altogether.

Go back in, and it's not cropped - fair I guess as the save failed.

Further information.  In one case, it was a song* from a single song PDF, in another it was a song in a large, multi song PDF that had been loaded via a CSV file.

Could this be a database issue?  If so, how can I repair the database?


* I can't recall if it was newly loaded or if it was a song that had been there for a couple of years (which was when I initially loaded this particular library)** and that we hadn't played since migrating to MS and thus was likely the first time it got cropped.  To explain that last, I often used the automatic crop feature on import but now rarely bother because it wasn't aggressive enough for my preferences.

** You may or may not recall that I manage my own files and use a different folder structure for each library.  NB All folders are under the default MS installation location:
Storage/emulated/0/Android/data/com.zubersoft.mobilesheetspro/files/<DirectoryNameForLibrary>

Below the <DirectoryNameForLibrary> There may or may not be further folders to differentiate between what instrument I might be playing E.G. Trom1, or Trom2, or Tuba (sometimes EbTuba) etc..

In some instances there may also be folders that relate to the books for the paper library that the rest of the band uses. E.G. Red, Blue etc..  In these instances there will also be a related collection to make it easier when someone calls for "Red 32" or the like.  When these circumstance are relevant, the song meta data will have the songs book and number identifiers in the Custom field, which also gets displayed in the library page using conditional field display in "Song Title Formatting" - E.G. Red 32 will have "Rd032" in the Custom field.
There will also be a collection that contains all the songs for that instrument so a song may belong to "Trom1" as well as "Red".

Somewhat complicated I know, but it makes sense to me and helps me manage the multiple bands I'm in and the instruments I play in them.

[Zubersoft]

I don't see any issues with the way you are managing things Lawrie. As far as the cause of what you are seeing, it sounds to me like the app is in a weird state in those situations. Let me ask this - were you multitasking and MobileSheets was in the background for a while? Or was the tablet asleep for a long time before the cropping occurred? The reason I ask is that there is code that is executed at startup that stores all of the data for the library. That code is shared between all the different screens in the application. I've seen many crash reports where this shared data was basically cleared as if the app was started up fresh yet the user was on a completely different screen (such as in the song editor or the cropping screen). This causes a crash as the code isn't expecting the app to be in an unitialized state and to have that data missing. I have never known how to reproduce this, or what can lead to it happening. I added code to some screens to try to account for it, but it's very difficult to account for it everywhere without knowing what leads to it. It's almost like the OS is shutting down large parts of the app. There is something called the activity stack on Android where the different screens are layered on top of each other, so that when you are finished with one screen, it goes back to the previous screen you were viewing (i.e. you save the changes in the song editor and it returns to the library). I'm guessing based on the crash reports that the OS is clearing out the older activities and just keeping the latest one, meaning there is nothing to return to and was part of the main activity being closed, it clears out the data and unitializes things to prevent memory leaks. I'm not sure if this is something I can explicitly prevent if it's driven by the OS.

Mike

[Lawrie]

Hi Mike,
OK, this is weird...  I definitely replied to you but my post appears to be missing.  Perhaps I forgot to actually post it after previewing it...  I'll try to replicate the important bits.

I don't do any multitasking on the tablet I use for MS - it is fully dedicated to MS only.

However, even though I should know better*, the tablet is normally never shut down, nor is MS ever closed.  My habit is to simply close the cover and put everything to sleep.  It rarely, if ever goes for more than a day in sleep mode, but 20+ hours is common as many of my rehearsals start at about the same time and run for about 2 hours.

Pretty much the only times a restart of the tablet happens is when I do a firmware update (which, coincidentally, actually happened yesterday).  I guess it's time to change that habit.

* Everyone "knows" that the best way to fix computer glitches is a restart   but before retiring 10 years ago I'd spent too many decades in IT; mainly building and managing networks where servers are NEVER, EVER shut down or restarted** unless there is a dire need.  At least, that's my excuse and I'm sticking to it 

** Clustering and virtualisation has softened this need but I'm sure you get the picture.