[Zubersoft]

A few users have contacted me due to a problem where MobileSheets wouldn't respond to touch events for several seconds in certain situations. One user figured out a workaround - raising the application priority for MobileSheets. I'm not sure why this would have such a large impact on those devices, but it usually means there are services and applications fighting for resources. That user created the following script to launch MobileSheets with an elevated priority:

Code:

REM   ==== MobileSheets Execution Priority Level promotion =====

REM  the following loads MS then sleeps and then raises the execution priority to a higher level.

start MobileSheets.lnk

REM  neither SLEEP or TIMEOUT are work as specified for some reason but do not impact script functionality

REM sleep 5

REM timeout /T 5

wmic process where name="MobileSheets.exe" CALL setpriority "high priority"   

REM    "high priority"   works well on the DELL

REM     wmic process where name="MobileSheets.exe" CALL setpriority "Realtime"   ( does not work)

REM ==== end script =====

I just wanted to share this for any user that it might help.

Mike

[Richard Berg]

If you don't know how to create a *.lnk file (Windows shell shortcut) to a UWP app, see this guide: https://winaero.com/blog/desktop-shortcu...indows-10/

Trying it now...

[Richard Berg]

FYI, it did not fix the long delays on my machine.  (they might be shorter now -- hard to say for certain)

[Zubersoft]

I'm really sorry to hear that. I still haven't heard from any other person who has experienced those kinds of long delays, so I'm not sure if it's an isolated issue or not. Have you tested the app on any other device you own?  

Mike

[Geoff Bacon]

Just a thought

Is there an antivirus checker running in the background? These tend to cripple windows systems for a few minutes after the system is booted



Geoff

[Richard Berg]

Only whatever anti-malware comes with stock Windows 10.

I took a video with Task Manager running side-by-side so you can see that nothing else is eating system resources: https://photos.app.goo.gl/fBZwszVkrKK2wor58

Examining the video also let me quantify the freeze for the first time: turns out it's 40 seconds, not 20 as I'd previously estimated.  (It may unfreeze faster if I'm not moving the mouse / tapping the screen.)

I've sent time travel captures to Mike so hopefully we'll get to the bottom of it when he gets some free time.

[rrrpiano]

I'm also seeing delays/freezes on my Surface Pro 4 (i5, 4MB ram) with MobileSheets. MobileSheets is the only app where I see these delays/freezes. This has been happening for the past 6 months or so if my memory is correct.
To be clear: for example, when selecting a song to display, or trying to change pages, many times (not always!) there's a 5 second +/- display freeze before MS responds. During this time MS is unresponsive to touch commands....except if I kill the program (by clicking the "x" in upper right of MS window).
I usually run MS with no other apps running on the machine, thinking maybe it is fighting for resources. Not sure if this matters. It will freeze with and without other apps running.
I have not tried the suggested script to elevate the MS priority. I don't feel comfortable messing with this.
I am using the builtin Windows Security, nothing else for malware, etc. No backups are happening at these times.

I don't have another Win10 laptop/tablet to try to duplicate the problem.
Hard drive memory is ~50% used. Lots of room left.
MS only uses ~58MB of ram typically (out of 4MB).
Power usage is "very low" (from task manager)
Any thoughts on what to try/check?

If I were using MS in a gig situation, this issue would be a real problem for me. It's just frustrating at this point....

thanks!

[rrrpiano]

When this happens the next time, I'll watch what's happening in the task manager to see if something shows up.

[Zubersoft]

Just to verify, are you running version 2.6.7 of MobileSheets? Also, which update of Windows 10 are you on?

Thanks,
Mike

[rrrpiano]

Just to verify, are you running version 2.6.7 of MobileSheets? Also, which update of Windows 10 are you on?

Thanks,
Mike

Glad you asked. I have MS 2.6.3, Windows update 1809 KB4503327.

There are times when I open MS and a "list of changes" for a new MS update will show on the screen.

I presume that I never have to manually update MS, and when I open it up it will automatically grab the latest MS updates, if any are available. Should I expect this to happen? If not, how will I know an update is available?

For some reason I never got the automatic updates after 2.6.3.

So I now manually updated to 2.6.7 (went to the Microsoft Store, and saw that an update was available). Should this freeze problem to be fixed with this update?

thanks again,
Rod

[Zubersoft]

Rod,

If you haven't disabled automatic updates for MobileSheets through the Microsoft Store, then yes, Windows 10 should eventually update that for you. I always post release notes on the forums when a new release is available, although if there are any serious reported issues, I hold off on posting the release notes until issues are resolved. There are no notifications in the app itself about updates though as Microsoft doesn't provide a way to check if an update is available on the store through their API. The version of MobileSheets that I sell through FastSpring pops up a notification whenever an update is available as in that case I'm using my own server to deliver updates.

Some users have reported much better performance with version 2.6.7.  I think the main reason some people are seeing this is that there was a problem in earlier versions where MobileSheets would iterate over all USB and bluetooth devices on the machine, and try to connect to any that were MIDI devices. This connection attempt would hang (because Microsoft's call would never time out) so it would essentially leave a processing thread in a deadlocked state. If there were enough devices that MobileSheets tried to connect to, this may have depleted a lot of the available threads in the thread pool. This would then cause delays in processing after that because the thread pool would be struggling to find available threads for handling background tasks. This is just my guess based upon the nature of the changes I made, as I added a forced timeout when connecting to MIDI devices. Let me know if 2.6.7 is any better for you.

Thanks,
Mike

[rrrpiano]

Thanks for the detailed reply Mike.

I checked the "Update apps automatically" in the Windows Store. It was set to On. I'm guessing that there was some glitch in the Windows Store software that didn't allow the auto updates to happen (there were a few other apps that I needed to manually update today). Something likely 'out of sync' with Windows update perhaps.

I will look in the future to see if apps are waiting for me to manually update. If this happens again, I'll contact Microsoft support to see why the auto app update isn't working.

I'll let you know if I continue to see any more of this freezing.

Thanks again for your excellent support and software.
Rod

[rrrpiano]

I have all the latest MS and Msoft updates, but I'm still seeing this problem over the past few days.
Sometimes it's a 5 second delay from selecting a song in MS and the song appearing.
I turned off Bluetooth on my Surface to see if this made a diff, but it did not.

When watching the Win10 task manager I notice that MS consumes more and more memory as I open new songs. After opening 1 song it uses about 120MB. After 5-6 songs, MS is using 600MB of memory, which is about 15-20% of the working memory on the machine. At this point, with just the other minimum Win10 stuff running, I'm seeing 60% memory usage. Not sure if this is causing the freeze/delay problem....thoughts?


When I select a new song in MS, why doesn't it flush the previous one(s) from memory? Wouldn't that be more efficient?

Any other things I could check when this freeze/delay is happening?

thanks for your support!

[Zubersoft]

If your device runs out of memory and has to perform frequent garbage collection as a result, that certainly could cause delays. At a certain point, you shouldn't see MobileSheets consume additional memory. When a new song is selected, I do free all of the memory used for PDFs that were loaded, but I keep the buffers that were allocated for images in memory to prevent frequent allocations and deallocations. This is extremely important because huge stutters can occur if garbage collection has to occur on large blocks of memory. This was one of things I tried to improve a number of updates ago to see if it would help users with the performance issues they encountered. The buffers for each image should match the number of pixels used for the pages that are displayed. If your songs were stretched to the fill the screen and the surface pro 4 is 2736 x 1824 and I buffer 14 images max in memory, that is 19961856 bytes per buffer (~20 MB), so 280 MB max. I also use WriteableBitmap objects, which allocate the same amount of memory each, but these have to be allocated/deallocated when switching songs. So MobileSheets can easily use around 600 MB, but it shouldn't keep climbing, as it's a limited size memory pool.

Having said all that, I'm switching to Win2D with the annotations rework, which is going to help reduce the memory usage needed (as I will no longer need to use WriteableBitmap objects), and could also help performance due to less allocations/deallocations. I don't know if this will fix the delays you are seeing, but it may.

Do you only notice these delays after MobileSheets has been running awhile, or does it even happen after first loading it? If you completely close down MobileSheets and restart it, does it work better for awhile or not? I ask because with my development and testing, the application is being restarted a lot and usually hasn't been left running for long periods of time. I sometimes will take it out of sleep after several hours and test things, and I don't see the long delays doing that, but I want to see if this has anything to do with why I'm not seeing this issue on my Surface Pro 4. 

Thanks,
Mike

[Geoff Bacon]

I don't have a Surface Pro so this is just about Windows in general.

Windows tries to keep as much of the program and data in memory as possible for fast access .i.e. memory might still be allocated to a program even though it will never be used again (windows doesn't know that). This will continue until the program is closed or windows determines that it has insufficient free storage. Assuming it is lack of free pages, windows will then release "old" pages. Any modified pages need to be first saved in a virtual page file from which they can be restored should they be referenced again. Unmodified pages do not need to be stored because they can be recreated from their original disk location. This technique is donkeys old.
Basically, what I'm saying is that a large memory usage does not necessarily mean that there is a program; it is more the pattern of usage. 

"I'm seeing 60% memory usage" means that you should have plenty of usable memory - for comparison, my desktop has 53% used.

Mike: Are you writing temporary files to disk or are you just grabbing memory? If writing large temporary files, performance can be significantly improved by pre-allocating the full file size rather than just letting the file be automatically extended as it is written from the start.


Geoff