Incident Identifier: B4AD34B9-3356-491A-AF07-6337A56B4091 CrashReporter Key: 431c3c29af9197b61707df304c46212d051da864 Hardware Model: iPad1,1 OS Version: iPhone OS 5.0.1 (9A405) Kernel Version: Darwin Kernel Version 11.0.0: Tue Nov 1 20:33:58 PDT 2011; root:xnu-1878.4.46~1/RELEASE_ARM_S5L8930X Date: 2012-02-28 10:14:02 +0000 Time since snapshot: 62 ms
Incident Identifier: A3503570-CD85-4256-8806-7BAB953F2299 CrashReporter Key: 431c3c29af9197b61707df304c46212d051da864 Hardware Model: iPad1,1 OS Version: iPhone OS 5.0.1 (9A405) Kernel Version: Darwin Kernel Version 11.0.0: Tue Nov 1 20:33:58 PDT 2011; root:xnu-1878.4.46~1/RELEASE_ARM_S5L8930X Date: 2012-03-02 20:20:54 +0000 Time since snapshot: 59 ms
I wonder if the pages viewed are being cached into iPad memory and this is the issue here.
The alternative might be to sync the library into iPad storage so that they read from that rather than being in memory.
This means that the iPad would not be in real time sync with the core library for artwork. This is not an issue if libraries are not changing every minute.
Hi Nick I've done a little testing that I've not completed yet, but
About 95% sure that the Covers used in the Browse Grid are actually Cached by the iPad............not sure if it's "all" your Library yet or just a percentage, but it's definitely caching a good percentage
Also, just to again point out that
a) the Browse Grid uses the CoverImg002.ReSize170.jpg
b) While the Explore Album Detail Screen uses the (usually larger) Cover.jpg........and near as I can tell, the App does NOT Cache this image
Like we discussed at Bristol last week, the current iPads are starved of Ram......and Apple's OS Memory Management scheme has always been very agressive at closing non-core Apps that "over step" the mark however
One thing that I can't get a handle on at the moment though, is the fact that at least 3 people here don't really experience crashes......Jack D, Tintin (recently) and myself
So, there is more to this than the App consistently crashing........there are other Processes which are contributing to the Low Memory as well
Could the size of the library have something to do with the crashes? I only have about 650 CDs and usually I run a focus that reduces the amount to 550. I also have several CDs that I have organized into sets so that cuts the amount of displayable covers a bit more.
MD600(2x2TB); iPad Pro LR. 818v3, 8000SE HT. 861v8+ID41,HD621; BW 2x802D,HTM1D,4x804S;SVS sub; Mac 5 MC501s; RGP 600Pro, JVC X950; Radiance Pro; Oppo 203 FR. G65, DSP3200-3300 DSW, HD621; Mac MC152; Oppo 103, PDP TCP65VT60, Radiance 2124; RGP1200C 4. G65, DSP3200-3300,HD621; OPPO 83, Radiance XE PDP 5. 818v3; Prime HP Amp; HD800
NCPL.........8,500 Albums approx.......@20k for each 170 pixel image = ~170Mb (assuming that all Covers are cached, which I think is very unlikely in this case)
Ratbert.......2,500 Albums = 50Mb
Jack D........650 Albums = 13Mb
It's likely that Meridian are setting an Upper Limit on the amount of Memory that the Cache uses.......and then uses Purge and Refresh from Storage as is required as the User moves thru the App
However, because the symptoms vary between different users........and people like Tintin experienced no crashes after turning off another background app..........I think there other factors in play AS WELL AS the Meridian App Memory / Cache management itself
Ronnie, Seems like there is something to the library size. It will be interesting see what happens with the iPad3. Still I assume there was/is some way for M to have programmed in such a way as to avoid this problem or at least make it a rare occurrence?
MD600(2x2TB); iPad Pro LR. 818v3, 8000SE HT. 861v8+ID41,HD621; BW 2x802D,HTM1D,4x804S;SVS sub; Mac 5 MC501s; RGP 600Pro, JVC X950; Radiance Pro; Oppo 203 FR. G65, DSP3200-3300 DSW, HD621; Mac MC152; Oppo 103, PDP TCP65VT60, Radiance 2124; RGP1200C 4. G65, DSP3200-3300,HD621; OPPO 83, Radiance XE PDP 5. 818v3; Prime HP Amp; HD800
Hi Jack The only problem is that it's most likely that this is a Low Memory related issue
However, you and I don't have (many, if any) Crashes.......and yet we use iPad 1's..........which only have 256Mb of Ram
While Nick NCPL and others use iPad 2's......which have 512Mb of Ram......which Theoretically should allow the Meridian App a further 256Mb of Ram for Caching etc.............WAY more than enough to cover their Larger Libraries
And yet, they have more Crashes than we do.......which is the exact opposite of what you'd expect
The iPad 3 is likely to have 1 to 1.5Gb of Ram, with a Quadcore A5x processor and a 2,048 by 1,536 screen..........and so theoretically lots more Ram for the App to play within
But on paper, you could easily make the same prediction for the iPad 2 performance......and yet that's not the case
That's why I think there is background stuff in play as well
I do have an iPad1 but I haven't used it with the new M Core yet. I have only used the iPad2 which I use to control my primary music system. I mostly use the iPad1 to control my HT system but I do have an MS600 in that set up. I suppose I should play around with M Core on the iPad1 a bit to see how it functions.
MD600(2x2TB); iPad Pro LR. 818v3, 8000SE HT. 861v8+ID41,HD621; BW 2x802D,HTM1D,4x804S;SVS sub; Mac 5 MC501s; RGP 600Pro, JVC X950; Radiance Pro; Oppo 203 FR. G65, DSP3200-3300 DSW, HD621; Mac MC152; Oppo 103, PDP TCP65VT60, Radiance 2124; RGP1200C 4. G65, DSP3200-3300,HD621; OPPO 83, Radiance XE PDP 5. 818v3; Prime HP Amp; HD800
... I don't know where diagnostics log is on iPad but on iPhone iOS5 it's in settings/general/about/diagnostics and usage/diagnostics and usage data. ...
I just changed a typo in the above. I missed out general so have corrected it. Anyone that is experiencing a large number of 'crashes', do Meridian a favour and make sure that 'automatically send' is enabled.
Im no export in these things, but from the crash logs posted, my interpretation is that there seem to be two issues.
First, the Sooloos app, CoreControl, is big on memory usage. In all three of the memory usage logs, it was the largest app running on the iPad and thus, the one most likely to cause iOS to have to perform tasks relating to memory allocation. I don't have an iPad so don't have this app, but on my iPhone, it is no surprise that my largest app Safari is also my most unstable.
Second, one of the logs there does appear to be an Sooloos application crash but, not directly in Soolooos code but quite a bit further down in the back trace/call stack within the iOS user interface library. These can be very difficult to track down and hopefully Meridian will get enough diagnostics to allow them to track down this type of crash.
The fact that 3 of the 4 logs posted seem to indicate low memory issues would add weight to the argument that the disappearance of the app is not a crash but a result of iOS jettisoning apps to free up memory.
Like larger modern OS's, iOS also implements virtual memory, but it is much more basic. Unlike 'proper' virtual memory implementations where any of the virtual memory can be transparently swapped by the OS between RAM and disc, not all of the contents of the iOS virtual RAM can be. Whilst iOS can automatically remove read-only content, such as program code, from RAM when free RAM gets below a certain threshold, for read-write sections, such as data, iOS asks the application to free up memory and if it fails to free up sufficient RAM, iOS terminates/jettisons the app. If the jettisoned app is not currently active, then this process is largely transparent to the user, however, if that app is the current running app, it simply disappears from screen. It is this I believe that we are seeing in the majority of 'crashes'.
Whilst low memory situations may be as a result of memory leaks, I do not believe that this is happening to any major extent here (if at all). So assuming that the issue is a direct result of the limitations of iOS virtual memory management, made worse by iOS devices having limited RAM in the first place meaning that the amount of data that it can hold is very limited.
A possible scenario that we seeing is that the Sooloos CoreControl app is using a large amount of RAM to hold data (possible cover art). So it is up to the Sooloos app to free as much of this up as it can when iOS tells it to free up RAM. As other applications can be running in the background, just see from nclp's first crash log to see the list of other runnable processes on the iPhone, this trigger can occur at random times when one of the processes periodically wakes up to do its stuff and then goes back to sleep. The issue then becomes how much RAM can Sooloos freeup and is it sufficient to prevent iOS from terminating it. Only Meridian can know the answer to that.
Meridian owner since 1992 Prime & PSU, Focal Elear headphones, Roon (ROCK 8Gi5 NUC), Explorer 1 & 2, F80. 200/203, various Sonos (via Roon).
Google Search
|
Meridian Systems
|
Meridian Streaming
|
Restaurant
|
WiKi
|
Duncan's Meridian Info
|
Board Rules
|
Restaurant Rules
