[Zubersoft]

I'm just grabbing memory.

[Geoff Bacon]

Are you pre-allocating the memory as one chunk when you need it or are you just creating a memory file and letting it expand as it is written to? Just checking; I'm sure that you are allocating the full size before use.

Geoff

[Zubersoft]

I'm using a memory pool - I look for a block of memory that either matches what I need or one that is bigger if no match is found. If the pool is smaller than the maximum size and a block of memory is needed, a chunk of memory is allocated that matches the amount required for the bitmap. So I have a list of blocks of memory, not one giant block of memory as I can't know exactly how much memory is required beforehand. 

Mike

[Geoff Bacon]

Sounds good

Geoff

[rrrpiano]

Mike,
  Over the past few days I have not seen this problem again. I'll report back if/when I see it again. I have the task manager window open at the same time to see if anything shows up there.
  Thanks for your support.
Rod

[rrrpiano]

Saw the problem again today. I only have MS and the Windows task manager running. When it "hangs" I see the CPU jump to 25-30% and stay there while MS is not responding (sometimes up to 15-20 seconds). When the hanging stops, the cpu drops back to nearly 0. Memory does not look different between hanging and non-hanging condition. Gpu usage does not jump during this. Normally when I open a new song, the CPU jumps tp about 10% for a second or so, them drops back to 0.
Anything else I can monitor when this happens to pin it down further?
thx

[Zubersoft]

This is with version 2.6.8, correct? Does the problem occur just once every so often, or once it happens, do you see it occur over and over? I'm curious whether it's something related to garbage collection or something else going on that is tying up the UI thread. What were you in the middle of doing when the problem happened? Were you editing songs? Just paging through songs? If you can zip up all of the xml files and mobilesheets.db under C:\Users\<your username>\AppData\Local\Packages\41730Zubersoft.MobileSheets_ys1c8ct2g6ypr\LocalState and send it to mike@zubersoft.com, I'd really like to examine your library and the current settings.  If you experience this problem even with a nearly empty library, let me know. I really hope I can figure this out somehow, but I need to know where to look. There are so many variables, and I'm not seeing the problem myself at the moment, which makes things much more difficult. Are you connected to MIDI devices by chance? What about bluetooth devices?

Thanks,
Mike

[rrrpiano]

Hi Mike,
  In the last about 10hrs using MS, I've only seen it happen a couple times. It's not very often. It seems to be happening less lately (compared to a few months back), but I can't quantity it. When it does happen it usually lasts 10-25 seconds.
Yes, I'm using 2.6.8. No MIDI devices. Bluetooth is off. No other user apps running during MS use.

It usually happens when I select a song to view from the song list. It then hangs (continuing to show the song list page) for 10-25sec before it actually opens the song. Sometimes it happens when I'm returning to the song list from viewing a song. I've never seen it happen when editing a song, or during any other operation that I can recall.

My library has about 1700 songs, so I don't know if it would be different with a nearly empty library. I could try that and see what happens, but again I only see it once every 5hrs or so....


I'll send you a zip. Are there log files in MS that can show timestamps when an 'open song request' happened, and then a timestamp when the song actually opened? Hopefully you can spot something. 

thanks again,
Rod

[Zubersoft]

There aren't any log files at the moment. I can certainly put together a build for you with logging in it. Or I may just start implementing a logging framework so that I can start capturing data for solving bugs if the user turns logging on. 

When switching between songs, the previously loaded PDFs have to be cleared out of memory. Perhaps this problem can occur under certain conditions when the PDFs are cleared. If that was the case, changing the setting for Settings->Display Settings->Render Preference should have some impact on that. You could try switching that setting to see if it helps with the issue. I'll keep an eye out for what you have described as well. I'm rarely able to use the app for extended periods of time like what you are describing though as I spend most of the time either modifying code, tracking down and fixing bugs (which involves restarting the software over and over) or supporting customers. So adding logging probably is the best way to gather the information required to solve this. 

Thanks,
Mike

[rrrpiano]

I'll try changing the settings as you suggest and let you know what I see.
I just sent you a link to my zipped database file.
thanks again,
Rod

[Geoff Bacon]

Re "the previously loaded PDFs have to be cleared out of memory", I thought you were just storing the blocks in a garbage area i.e. you could clear them on their next reuse (perhaps have a flag so no need to clear them if just allocated). If no obvious space for a flag, you could use the first few bytes in the buffer to store a signature when the block is no longer required (if the signature is present then the buffer needs to be cleared, if zeros then no previous use) 
Historically, the VAX/VMS operating system could develop excessive paging if one iterated through a large array in a non-optimal manner, I doubt that you have this problem (Vax only had 512 byte pages!)

Geoff

[Zubersoft]

I'm storing images in blocks of memory. The PDFs themselves are loaded by external third party libraries to produce those images. You have to open and close the PDFs in those libraries to release the memory they allocate. I don't have control over their behavior so I can only hope they aren't leaking memory or causing other issues.

Mike

[Geoff Bacon]

Hi Mike

That makes sense.
How about closing the PDFs in a self terminating thread(s) i.e. no need to check for completion? Of course, this will probably have minimal effect if the tablet has a single cpu and/or the scheduling is co-operative rather than via interrupts.

Also, using a thread might not make any difference if there is another immediate call to the external PDF library (this might hang until the old PDF has been fully released).
If memory is not an issue (it probably is) and if the library allows it (which it may not), you might be able to open the next PDF file before releasing the old PDF file via a self terminating thread. This should provide quick song changes without hanging the GUI (assuming the cpu has enough oomph and the PDF libraries are well written). The only way to tell would be to code it and I can see that testing will be difficult as the problem is intermittent.

I think that it about all I can contribute to this problem.

Many thanks for all your work developing/maintaining MSP

Geoff

[Zubersoft]

The PDF libraries are single threaded, meaning access is locked both for opening and closing. So there is no benefit to trying to parallelize opening/closing unfortunately. Having said that, almost operations involving the PDF library are already done on a background thread. I take every measure I can to avoid tying up the UI thread in any way.

Thanks for all your feedback though. Problems you can't reproduce yourself are always the hardest to solve.

Mike

[SPG]

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