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


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

Users browsing this thread:
1 Guest(s)

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