[Skip]

It could be 'outside' interference, such as a generator or other local EM source and not internal to the devices. Maybe use them in another town or power source?
 Wrap them in tinfoil?

[mikerice123]

It could be 'outside' interference, such as a generator or other local EM source and not internal to the devices. Maybe use them in another town or power source?
 Wrap them in tinfoil?

We have tested these both at home and away from our home in different locations including a different city, as well as when they were plugged in and when they were running on battery, all with the same result.

[tadawson]

On or off the network?

(Thinking about upgrade checks/etc. coming in from or connecting to outside). 

Specifically, have you tested in airplane mode?

[mikerice123]

I believe in every case our Chromebooks were on the WiFi network in the facility we were in.  I haven't tried it in airplane mode.  Chromebooks don't have that feature, but I can disable WiFi and bluetooth and test that (there is no cellular radio in our Chromebooks).

[mikerice123]

I tried your suggestion and turned off WiFi and Bluetooth and left my Chromebook on during one of the windows.  Unfortunately the Chromebook returned to the library screen during the window.

[Skip]

Does it happen with just one device on and the other unpowered?

[Zubersoft]

I have not found a way to prevent the application restart when the configuration change happens. So unless someone knows an engineer from Google that can provide information on this, I'm not sure what I can do about it... It seems like a major flaw of Chromebook devices.

Mike

[tbclark3]

I am also experiencing the issue of unexpectedly returning to the library screen on my Acer Chromebook Spin 713.  It occurs so rarely that it is difficult to establish a pattern. However, it has occurred twice now while I was in a performance with disastrous consequences.  It does not occur at a predictable time, and definitely occurs outside of the time intervals proposed by a previous poster (although an exhaustive exclusion would require a comparison in both universal time and local time). It occurs whether or not the device is on a network. It occurs whether or not the Linux subsystem is running. My perception is that this problem began for me about the time MobileSheets introduced facial gestures.  I am an organist, and the facial gestures page turns are game changing (neither hands nor feet are available for page turns), so I almost never play without them being active. That said, I occasionally do, and have not had the crash occur at a time I was not using gestures.  I may have one more clue:  I have only one gesture configured--mouth open to turn page, and the crash has not happened during an actual page turn. Twice recently, however, it has been my perception that an unrecognized facial gesture may have caused the problem--for example, pursing my lips. 

I am aware of the "always load last viewed page" option. However, it does not return to the same place in a set--making it essentially useless for use in a concert where a set is almost always in use.  This problem seems to be widespread, and the consequences are significant.  Would it be possible for MobileSheets to mark its place (on permanent storage) every time a page is turned, including whether in a setlist, and to put an emergency button on the library screen called something like "Restore page" that would return to the same page in the same set that was active the last time a page was turned?

[Lawrie]

I have not found a way to prevent the application restart when the configuration change happens. So unless someone knows an engineer from Google that can provide information on this, I'm not sure what I can do about it... It seems like a major flaw of Chromebook devices.

Mike

Hi Mike,
just a reminder: this is not limited to Chromebooks.  As I've previously mentioned, I'm also seeing this behaviour (though rarely) on my Onyx Boox Tab X (using the Fastspring e-ink edition of MS).

My tablet is almost never connected to the internet*, and certainly not during performances and rehearsals - I.E. not when I'm actually using MS.  It is only connected at the odd random time when I think to check for updates to MS.

With that in mind, I remember a while back there was some discussion about licence check issues being a problem for some users.  As my tablet almost never gets a chance to verify the licence it made me wonder: could licence checks that can't be performed, or that appear to fail, somehow be connected to the jump back to the library screen?  I haven't seen a pop-up for a failed licence check since not long after I bought MS, and it was around then that I recall this issue coming up (late'23 or early '24 perhaps???).

* I don't use cloud storage.

[tbclark3]

I think this is a MobileSheets problem and not an operating system problem, and there is good evidence to support it.  I use my Chromebook a lot for things other than MobileSheets, and I have never had an app close or reset. Mobilesheets is the only one that does. I have done a web search and can't find a similar problem on another Chromebook app.  Like the poster above, I have also had it happen on my Android phone. Finally, it happens when there are no obvious operating system changes such as a network change--not to mention that other apps tolerate network changes and other changes gracefully.

This bug has disastrous consequences, and it has happened to me twice in solo concerts. PLEASE take another look or figure out some way to add debugging info. And, again, I repeat my request for a button to restore one's page in a playlist which would at least minimize the disruption.

[Geoff Bacon]

Hi Mike

Just for information

I don't know if this is related to the original problem but, when selecting a song from a displayed setlist, I occasionally get returned to the initial library screen ("Collections") rather than the song being displayed. 
This only happens when trying to select a song, it dosn't happen when swiping to move from one song to the next one.
I have never been returned to the library screen whilst playing a song 

It is not a biggy as it is easy to select Setlists followed by the setlist and then the required song.

Geoff
PS: There doesn't seem to be a spell check option

[Geoff Bacon]

duplicate deleted

[Zubersoft]

tbclark3,

In reference to this:

I am aware of the "always load last viewed page" option. However, it does not return to the same place in a set--making it essentially useless for use in a concert where a set is almost always in use.

If you tap Load All when loading the setlist, it absolutely will take you back to the last page you were viewing in the setlist unless you have changed the default application settings. Regardless, I have changes in place for the next update so that if you tap a song within a setlist, it will also resume the last viewed page for that particular song.

As far as it only being a MobileSheets problem - are you actually comparing Android apps to MobileSheets? Or Chromebook apps? They are entirely different things and run in a very different way (Android apps run through emulation in a sandbox). What other Android apps did you test? I have never been able to reproduce this issue, and until someone can provide me with steps necessary to trigger it, I'm probably not going to be able to do much about it. As far as debugging info - there are a few things I can debug, such as what action triggered the return to the library screen (if any), so I can certainly add this as something that is disabled by default that the user has to explicitly enable. If you are working with the FastSpring version of MobileSheets we can work on tracking this on your device if this is something you are seeing regularly as well if you want to run a build with more logging.

Mike

[tbclark3]

Mike, thanks for your thoughtful response.  You are correct that I was not differentiating in my comment between Chromebook native apps and Android apps. I do, however, run several Android apps frequently, including Thunderbird email, remmina, and OpenVPN. None of them has ever crashed and reopened like MobileSheets does. I understand that doesn't prove that the problem is with MobileSheets, and I also understand how difficult it is to debug.  I would be happy to help if you give me some suggestions.

The crash happened again yesterday *while* I was performing in a hymn festival. My music just disappeared in the middle of a verse with a chapel full of people singing.  Yes, from the library screen, I can find the setlist I was playing, which means scrolling, and select it, then select Load All, and it does return me to where I was playing, but about 5 or 6 seconds later--too late to be useful. This flaw makes MobileSheets unreliable, and I'm sure that's not the reputation you want to have.  There are almost 66,000 views of this thread.  It's a huge problem.

If the problem can't be solved, maybe it could be mitigated.  Could you add a selectable feature called something like "Restore setlist and page" so that when the app opens or returns to the library page, it immediately goes to the setlist and page where it was when the app crashed (or closed).  For normal use, such as practicing, the feature could be turned off, but it would be a safety net during performances.  I read a measure or so ahead of where I'm playing, so even if it took a second to restore the page, that wouldn't result in an embarrassing glitch. This app is incredibly well designed, and I can't imagine going back to paper music, but I have to be able to trust my music app, and right now I can't.

[Zubersoft]

I can certainly look into adding an option like that to reopen whatever was previously viewed. The number of users reporting this problem (a much more important metric for me than just the number of people viewing this thread) is incredibly small. I would hear about this a lot more if it was making the app unusable for a large percentage of the user base. I also am pretty confident that whatever the problem is, it's a much more prevalent on ChromeOS compared to normal Android tablets. While a few users mentioned above that they have experienced it on standard Android (or-eink) tablets, it seems to be a very rare problem on normal Android tablets. 

If the problem was intermittent, that would be one thing, but me not having a way to reproduce it at all is the major problem here. I have seen something like this on one of my tablets, and it occurred when loading the app right after the tablet booted up. The problem then never occurred again while running the app after that. So I do think there is some weird issue that can potentially occur in that scenario, but I don't reboot all my Android tablets enough to see it more frequently. However, when time allows, I can try to look into that more to see if it's something I'm able to reproduce on demand after rebooting a device (I've only seen it on one specific device though). I have no idea if that's related in any way to what you are seeing though, as this doesn't match what you've described. I'll probably have to test more on one of my Chromebooks, which I don't generally do as much.

On a side note, if you make the "Recent" tab the initial tab at startup, when the app starts up, you could tap the setlist entry at the top of the list, and if you enabled the option to automatically load the last viewed page, you'd be right back where you left off. That would only take a second or two compared to having to search.

Mike