• 1 Vote(s) - 2 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Workaround for machines that experience long delays
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.
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.

(07-15-2019, 08:46 PM)SPG Wrote:
(04-05-2019, 12:17 PM)Zubersoft Wrote: 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?  

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.


  I'm seeing this delay problem on my Surface 4 (w/i5 and 4GB mem). What processor and memory do your Surfaces have?
Surface 4, 4GB
(03-29-2019, 07:32 AM)Richard Berg Wrote: 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?
Surface 4, 4GB
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:

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


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

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

(08-18-2019, 04:29 AM)Zubersoft Wrote: 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?
It was added in version 2.7.2.


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

Users browsing this thread:
1 Guest(s)

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.