[Zubersoft]

I've been researching potential problems, and one thing that is mentioned is that the arcvm (the VM running Android apps on a Chromebook device) can decide to kill apps to get resources back if it's running low on memory and such. I'm wondering if MobileSheets is using too much memory in some situations (compared to amount of RAM available on the device), resulting in the device deciding to kill/restart it to get resources back. One thing I can try is significantly limiting the amount of memory used for PDFs and such to see if this makes things more stable. This will slow down the loading of some PDFs (particularly larger ones) and increase CPU usage as fewer pages can be cached in memory. That's another thing we can try testing with a build once we've confirmed my theory about the app being restarted.

Mike

[BluesBoy]

That means that the app was completely restarted, because that popup is the "Loading database" progress dialog. It didn't switch back to the library screen - the OS restarted the app, similar to what I saw when the screen was turned off. That's a horribly bad sign, because if the OS is just restarting the app out of nowhere, it's not like I can stop that in my code... With a test build, we can definitely confirm this theory though. Bluesboy - if you have a Chromebook as well, you'll have to use adb to sideload the app (https://www.howtogeek.com/752759/how-to-...oper-mode/). I just want to confirm that you are okay with this though, because it's a little technical. ChromeOS normally requires all installations to go through Google Play.

Thanks,
Mike

Not a problem. Besides playing a mean harp I'm also a pretty technical guy. I already had the Linux VM setup but not the Android debugging. Just did that. As I said earlier in the thread, I'm running an HP x2 11 Chromebook tablet convertible.

[jdp72]

Maybe a stuppid gues, but could it be that a chromebook sends a keypress (the arrow left key) without really pressing it? When the focus is on MSP it will go back to the Recent screen. And thinkging of that, coudl it be that a connected bleutooth pedal somehow sends a keypress as a sort of keep alive or test which actualy on a chromebook is that left arrow key?

[BluesBoy]

Maybe a stuppid gues, but could it be that a chromebook sends a keypress (the arrow left key) without really pressing it? When the focus is on MSP it will go back to the Recent screen. And thinkging of that, coudl it be that a connected bleutooth pedal somehow sends a keypress as a sort of keep alive or test which actualy on a chromebook is that left arrow key?

Not a stupid guess but, it's been ruled out. I ran tests with both Bluetooth and WiFi turned off and the issue still happened.

[jdp72]

Maybe a stuppid gues, but could it be that a chromebook sends a keypress (the arrow left key) without really pressing it? When the focus is on MSP it will go back to the Recent screen. And thinkging of that, coudl it be that a connected bleutooth pedal somehow sends a keypress as a sort of keep alive or test which actualy on a chromebook is that left arrow key?

Not a stupid guess but, it's been ruled out. I ran tests with both Bluetooth and WiFi turned off and the issue still happened.

Great! And how about something with the local keyboard?

[BluesBoy]

Maybe a stuppid gues, but could it be that a chromebook sends a keypress (the arrow left key) without really pressing it? When the focus is on MSP it will go back to the Recent screen. And thinkging of that, coudl it be that a connected bleutooth pedal somehow sends a keypress as a sort of keep alive or test which actualy on a chromebook is that left arrow key?

Not a stupid guess but, it's been ruled out. I ran tests with both Bluetooth and WiFi turned off and the issue still happened.

Great! And how about something with the local keyboard?

My Chromebook is an HP x2 11 which is a convertible tablet with removable keyboard. When it is in use in the stand as a sheet music reader the keyboard is not attached. When it is not physically attached there is no way for it to send any signals to the Chromebook (it connects via physical POGO pins).

[Zubersoft]

I'm sending over a build now to try to gather information.

Thanks,
Mike

[jdp72]

Maybe a stuppid gues, but could it be that a chromebook sends a keypress (the arrow left key) without really pressing it? When the focus is on MSP it will go back to the Recent screen. And thinkging of that, coudl it be that a connected bleutooth pedal somehow sends a keypress as a sort of keep alive or test which actualy on a chromebook is that left arrow key?

Not a stupid guess but, it's been ruled out. I ran tests with both Bluetooth and WiFi turned off and the issue still happened.

Great! And how about something with the local keyboard?

My Chromebook is an HP x2 11 which is a convertible tablet with removable keyboard. When it is in use in the stand as a sheet music reader the keyboard is not attached. When it is not physically attached there is no way for it to send any signals to the Chromebook (it connects via physical POGO pins).

I use an Asus CB5500 with keyboard attached. But it seems to me its really difficult to find the problem. Yesterday had a rehearsel of 6 hours, not once MS dropped to the library, this morning needed to change something and within 30 minutes it dropped back to the library while doing nothing other than viewing the page which i needed to change on my PC. Great respect to the developer if he could find it!

[Zubersoft]

From what I've been able to gather so far by working with BluesBoy, the application is being completely restarted the OS. I don't really know why the OS is doing that, but it's not something I can prevent. Having said that, the one guess I have is that maybe MobileSheets is trying to use too much memory, and the OS decides to restart it to reclaim resources, so my next test is going to be to significantly limit the memory usage on chromebook devices (meaning fewer pages will be cached in memory) to see if that prevents the OS from restarting the application randomly.

Mike

[RAc]

From what I've been able to gather so far by working with BluesBoy, the application is being completely restarted the OS. I don't really know why the OS is doing that, but it's not something I can prevent. Having said that, the one guess I have is that maybe MobileSheets is trying to use too much memory, and the OS decides to restart it to reclaim resources, so my next test is going to be to significantly limit the memory usage on chromebook devices (meaning fewer pages will be cached in memory) to see if that prevents the OS from restarting the application randomly.

Mike

Intersting... I do not know much about application programming, but I know that both Windows and Linux services support a kind of software watchdog, meaning that the service/daemon managers periodically try to decide if the service is still alive and if not restart it. Maybe there is something similar in app app development layer?

if this is reproducable on a Windows device, I suggest reading out the application and system event log and search those for entries matching the time of restart. To do that, simply type "event viewer" in the task bar search box, hit ok if asked whether you want that app to make changes to your system (it will not, just requires admin privileges) and open Windows logs from the list on the left, then scroll through system and application events.

[Zubersoft]

It is an issue specific to Android, and while a few users have indicated that they've seen it happen in the standard Android version, that seems to be extremely rare. 99% of the reported cases are on Chromebook devices, and applications on ChromeOS are run inside a VM, so there are just a lot of complicated layers.

Mike

[RAc]

Maybe this might be a step towards an explanation:

Monitor system health  |  Android Open Source Project

Of course, if the apps run inside distinct VMs, then there is also the chance of a VM itself crashing, but I would think that this would be logged somewhere...

[Zubersoft]

I wanted to provide an update. I've been working with BluesBoy (who has been amazing with helping me test lots of builds), and I was able to identify a pattern: MobileSheets seemed to restart every day around 19:00 on his device. I had added logs for activity lifecycle events, and it showed that a configuration change on the device was causing MobileSheets to forcibly restart (this is the normal behavior for certain configuration changes such as the user changing the primary/active language on their device). I'm still waiting for more information from BluesBoy, but this would point to an automatic system change at 19:00, such as a "night mode" or something on the device that is changing during the night, causing MobileSheets to restart. This means I have two options:

1) It is possible to prevent some configuration changes from restarting the app by indicating that you will handle them yourself in the application configuration. I already do this for things like rotating the device - I handle it in the app instead of the app just restarting (which is the default Android behavior). Once I identify what type of configuration change is occurring, it may be possible to just indicate that I will handle it myself to prevent the restart. 

2) Some configuration changes force an app restart no matter what (such as dynamic color changes which was introduced on Android 12L). In that case, I can just save some information about the last song and setlist that was loaded, and ensure that MobileSheets automatically loads the song or setlist and skips back to the previously viewed page. This won't be seamless, but it would at least prevent the need to manually load things back up.

I'll post back here once BluesBoy has helped me identify what type of configuration change is occurring. I may need to do both #1 and #2 above though, to cover all possible configuration changes.

Mike

[RAc]

 In that case, I can just save some information about the last song and setlist that was loaded, and ensure that MobileSheets automatically loads the song or setlist and skips back to the previously viewed page. 

Mike

Funny, I had thought about requesting that as a feature anyways before this problem popped up. For me it is typical to have one tune/song/piece open for a good while, so when restarting MSP, to me it would be very natural and time saving if it came up with the same piece I left it with when closing MSP.

[aspiers]

Wow amazing detective work Mike and Bluesboy!  I can't remember reliably, but 7pm could well align with every time I've seen this problem.  Looking forward to hearing more about future results of this investigation.

In the meantime, here's some more data, which may lend further weight to the 7pm theory:

Recently I set up a new Chromebook with the same library which I just bought so that I could have a backup in case this problem happened mid-performance, and also so that I could have them both operating in book mode.  (During setup I encountered several other problems unrelated to this one which I'll report in separate threads.)

After finally getting book mode working with my Airturn BT105, to my dismay, at some point in the first 30 minutes I experienced what seemed to be this same problem, or at least something very similar, which affected both Chromebooks simultaneously!  This was a big disappointment, because one of the reasons I bought the new Chromebook was based on the assumption that if this bug resurfaced, it would not affect the other Chromebook.

By "simultaneously", I mean within a fraction of a second of each other.  At the time, I assumed that this was some kind of cascading failure where the issue on one side triggered the same thing on the other side.  However, the 7pm theory could provide a different explanation for why the restart happened on both at the same time.

Almost exactly the same thing happened a day or two later.  On this occasion I'm much more confident it would have been around 7pm, because it was right at the end of a rehearsal before a gig which I think started at 7.30pm.

Here is the setup I had:

• Brand new Lenovo Ideapad Duet 5 as the Bluetooth group leader (positioned on the left-hand side)
  
• Old Google Pixel Slate joined to the Bluetooth group (positioned on the right). This is the one which I have previously seen spontaneously returning to the library screen.
  
• Airturn BT105 paired with the Pixel Slate over Bluetooth (for some reason it doesn't work with the Lenovo even when successfully sending keypresses to the MSP pedal settings page).  Even though it's turning pages on the follower, this succesfully turns pages on the leader too.
  

What I saw:

• Both machines returned to the library screen within a fraction of a second of each other.  However the Lenovo (leader) seemed hopelessly confused, since the library screen was empty and unresponsive.  (I can share a photo of this if it helps.)
  
• After this, I had to kill and restart the Lenovo app as it was totally unusable.  However, when this exact same problem happened again the next day a restart wasn't necessary.