[Ben]

Exact same thing/behavior here, I work in MSP 2.6.8 (Windows) for a while, then encounter slow or nigh to no response.
This started to happen perhaps 6-8 months ago.
Since MSP can be closed and reopened quickly I didn't bother to report this. 
It doesn't seem "normal" though.
Never any issues in Android.
Thanks. 
Ben

[Zubersoft]

I'm hoping that some of the changes I'm making with the annotations rework will help with this. I have gotten a memory dump from a user when the application was not responding, and none of my code was actively being executed. This means that the slowdown/hang was occurring in Microsoft's code, into which I have no insight. So it may be very difficult for me to figure out how to fix this as I have never been able to reproduce it myself. If it has something to do with the complexity of my UI layout, then I may have to make drastic changes to how the UI is designed, which could impact the responsiveness in general. For example, right now, the library screen and the song display screen are both loaded inside the same "page", as Microsoft calls it. I just only show one of them at a time. Even though only one of the screens is shown at a time and this should have no impact on the UI responsiveness, perhaps it's still just too complex of a component heirarchy and Microsoft's framework chokes on it occasionally. If that is the case, I would have to split those screens. This means that every time you would load a song, or return from a song back to the library screen, there would be a transition. This would cause a very noticeable delay upon loading a song or setlist as that entire screen would have to be loaded each time this was done. It would also potentially slow down returning from that screen to the library as all of the UI components would have to be deallocated. That is why it's designed the way it currently is. 

So I'm hesitant to make any changes, especially as I'm not seeing any problems myself and the kinds of changes described above could have very negative consequences. So my plan is to proceed with the annotations rework, which is introducing Win2D as the primary mechanism for rendering songs which should lower memory usage and result in faster drawing, and see if problems still persist after that. If the problems occur even just while using the library screen, then that either points to something in Microsoft's code over which I have no control or an issue with the UI design, which will be problematic for the reasons discussed earlier.

Thanks,
Mike

[rrrpiano]

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

I do have the same problem. Often.
It seems to occur when I've been working a lot in MobileSheets,
moving and adding songs between albums, collections, setlist etc.,
and editing in songs.
I then leave MS and reopen to get normal respond time.
I have problem when using MS in orchestra for playing.

Microsoft Surface 3 and 5, Window 10 latest upgrade.

Best
SPG

Hi SPG,
  I'm seeing this delay problem on my Surface 4 (w/i5 and 4GB mem). What processor and memory do your Surfaces have?
thanks,
Rod

[rrrpiano]

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...

Hi Richard,
   I have a Surface 4 with an i5 and 4GB. I am seeing this delay problem also.
Are you also seeing this problem on a Surface?
thanks,
Rod

[Richard Berg]

Rod: I have the Surface Pro 5 (2017 model) with i5-7300U and 8GB.

I'm still convinced it has to do with the UWP suspend/resume cycle.  I know the special build with logging in the OnActivated / OnLeavingBackground handlers didn't shed any light, nor did the debug trace, but I've done more extensive testing since then.  For me, freezing is 100% correlated with Windows force-suspending the MSP app.  

In the past, I would let MSP run for days or weeks at a time, only restarting when it crashed.  This made the freeze behavior seem more random.  Now that I'm in the habit of restarting MSP frequently, I can confirm:

• It ONLY repros after I've hibernated the machine (or used the PLMDebug utility to force it).  Once this happens, MSP will continue to freeze every time it's minimized or loses focus -- not just on sleep -- until I quit the app.  I can reliably predict when the bad behavior will resurface by checking whether Task Manager shows MSP as Suspended.
  
• However, when the app is freshly started (current PID has never been suspended), I can freely switch to/from other apps and come back to MSP without finding it's frozen.  Similarly, I can see in Task Manager that Windows has not put MSP in the Suspended state, despite being minimized.
  

So, anytime I need reliability before a gig, I proactively restart MSP via the Task View.  I've gotten so used to this workaround that I kinda forgot about troubleshooting the underlying issue -- sorry folks!

I will say that the severity of the freezes has gotten better in recent builds.  Usually more like 5-10sec now instead of the 30-40+ seen in the video linked earlier.

By chance do you use Extended Execution?  I remember thinking that this warning in the docs sounded similar (though not identical) to the freeze behavior:

If an extended execution session is requested while in the [b]Suspending[/b] state, and the user requests the app be launched again, it may appear to take a long time to launch. This is because the extended execution session time period must complete before the old instance of the app can be closed and a new instance of the app can be launched.

https://docs.microsoft.com/en-gb/windows...ta-locally



Extended Execution would also explain why MSP does not enter the Suspended state when minimized (prior to forceful suspend, at least).


Note: I'm not completely sure what the doc means by "new" instance here.  When a UWP app is rehydrated, it retains the same PID; its kernel resources may or may not have been reclaimed while it was suspended, depending what else the OS was up to, but the app shouldn't be able to tell the difference.

[Zubersoft]

I'll see if I can reproduce what you are describing on my own Surface Pro. 

Yes, I do use extended execution if the app is running in fullscreen mode. This is supposed to stop the app from being suspended on machines plugged in, or on mobile devices if the battery settings will allow it. I don't think it seems to work very well though, and according to Microsoft's documentation, the OS may only allow this for a couple minutes before suspending the app anyways. Setting the device to use desktop mode instead of tablet mode helps with this, as you can run the app in windowed mode that way without minimizing it.

I do not requested extended execution while the app is in the suspending state. I request it when the app is first loaded, or if switching between fullscreen/windowed mode. My code is not currently clearing the request after being suspended though, which is wrong I believe, so I'm going to fix that. 

If a new instance of the app is launched, it goes through a very different flow than if it is resumed. With a new instance, all of the normal initialization is triggered and resources have to be allocated again. On a resume, I just turn back on everything that I disabled in OnSuspend.


Thanks,
Mike

[tmj100]

I made the batch script at the beginning of this thread.  I am running several machines and they display different performance behavior. The cheapest junkiest PC runs the best and does not need the batch file. The Dell All In One 21 inch - runs the slowest and needs the batch file to run.   I did performance tuning on the PC before creating the batch file - where I shut off as many services as I could.  The installed OS image is what the vendor put on.  I even swapped out the disk drive for a new solid state unit.  

With a lot of services shut off, it still had severe delays.    The, I tested the MS execution priority level at several setting and found the highest it could be set.  For the Dell, this pretty much fixed the issue enough that it is usable during live performances and now has about 120 hours of on stage high demand time and still working fine.    Our Android machines have no such problems but of course the screens are also small and can not compete displaying 2 sheets side by side as the Dell does. 

I did not make a link file.   Just entered the script in a    MSxxx.bat    file and run that.  The REM comments were left in in case anyone wants to mess around with it. 

NOTE:    My belief is that this is not an MS coding issue but instead the vendor loaded OS image is the issue and one of these days I will do a fresh OS load on the Dell.  Until then it is usable for me.    On the cheapest junkiest windows machine which is a touch screen 17.3 inch EPIK ELAIO all in one, the same as the current IVIEW model  (Epik quit selling it now)  --  I did a full fresh clean OS install and performance issues went away.  It has 4 gig ram and only 32 gig ssd.    It runs smooth and sweet with Windows 10, update version 1903 and when I use the priority execution batch file on it -- it runs even smoother.   Hope this helps a little.

[Zubersoft]

Quick update: rrrpiano has been testing a custom build that is based on the FastSpring version and after 10 hours of use, he has not seen any delays. He is still testing to see if the delays ever occur, but if they do not, this could be a solution for people that are encountering this issue. I'll just switch those users over to the FastSpring version, as there must be something about the Microsoft version that is slowing things down (I have no idea what that could be though, as the two are largely the same). 

Mike

[Richard Berg]

My code is not currently clearing the request after being suspended though, which is wrong I believe, so I'm going to fix that. 

Can you let us know which version contains this fix?

[Zubersoft]

It was added in version 2.7.2.

Mike

[Richard Berg]

Thanks.  FYI I'm now running 2.7.4 and don't see a difference in freeze behavior.

[rrrpiano]

An update. I am seeing less and less delays with the latest updates (I'm on 2.8.9 of the Microsoft version now). I haven't tried the Fastspring version lately.
I've messed around with many of the Mobile Sheet's settings options over the past couple of months, but nothing I've tried makes a diff from what I see.
I've tried running MS with wifi and Bluetooth turned off, and even played with a couple of Win10 o/s power VS performance trade-off settings on my Surface4, but found nothing that makes a diff.
All I see is that CPU and memory use spikes when these delays do happen, but I don't see any particular process causing this when watching the Task Manager. I still find it strange that total memory use in Task Manager spikes, but no process listed accounts for it. Something stealthly is causing this....
The only consistent thing is that the longer I am using MS, the worse the delays get, until I close and restart MS. Then back to no delays...for while. Feels like a memory leak to me, but I have no way to prove this. Anyone know of any tool that could quantify a memory leak if it happened?
Still a mystery, but not as bad as what I was seeing 4-5 months ago.
thx
Rod

[Zubersoft]

From all of the information I have gathered, the problem is mainly due to editing many songs, one after the other. Each switch in and out of the song editor screen must be causing some of issue, but in all of my investigations, I can't figure out what that might be. There doesn't appear to be any kind of significant memory leak or other obvious problems. It could be a framework issue with Microsoft's library, as there are plenty posts about leaks caused by switching between pages in a UWP application. I also see different behavior depending upon the device being used to test. I've modified my code in every way I can think of to prevent potential leaks - the song editor screen isn't recreated every time, it's reused and repopulated with the data from the new song being edited. I would think that would eliminate all potential leaks, but it's apparently not enough (if the problem is some kind of leak in Microsoft's framework). One interesting change that is coming with the annotations redesign is a switch to Win2D for the rendering of pages. This will result in significant memory savings on rendered pages and should speed things up as well. I'll be curious to see if this helps with the freezing problem after multiple edits if the issue is somehow tied to the preview of the files on the files tab. 

Let me ask this - if you don't have the Yamaha GENOS connected to MobileSheets, and you edit 10-20 songs in a row, do you still see a 30 second delay? It would be very helpful to know if the delay is related to active MIDI connections.

I don't think switching versions would fix this problem, but if you really want to go through with that (it will require a new installation and you'll have to transfer your library to that version), email me at mike@zubersoft.com.

One last question - what version of MobileSheets are you running? I just want to make sure you are on the latest version.

Thanks,
Mike

[McAroni]

This is maybe not just an windows problem. I made the experience too that MSP is closing when I am in annotations mode. Mostly when I zoomed in to write something withe the pen. I usually avoid too zoom in and everything is fine. I thought my older Samsung device could not handle the zoom in the annotation mode

[Zubersoft]

This is only a problem with the Windows version. There are no problems on the Android side like this that I'm aware of and the code bases are completely different between the two. There are no problems being reported on Android with the app slowing down over time. If you are experiencing crashes with zooming, that is a different problem that would need to be investigated. Please write up a separate post for that with all of the details for how to reproduce the problem and I will see if I can reproduce it on my own Samsung Note Pro 12.2.

Thanks,
Mike