[Milhouse]

I thought when setting 128MB GPU on a 512MB RPi it automatically loaded SYSTEM into RAM but anyway, with Gotham I've been seeing around 300MB free. Can't say about the latest builds though as I've been running one a week or so old but have just upgraded to the latest so I'll check that later.

Not just 128MB GPU, but yes, OpenELEC will, by default, load SYSTEM into RAM whenever it determines there is sufficient memory available (more than 102MB available, to be precise). On a 512MB Pi with 128MB GPU, there will be 382MB RAM available at boot.

However I don't see a significant performance difference with SYSTEM loaded into RAM, so have opted to have more free memory by adding "noram" to cmdline.txt.

If you are seeing 300MB free with Gotham, I've a sneaking suspicion you're not loading SYSTEM into RAM. A recent Gotham build (128MB GPU) with SYSTEM not loaded into RAM only has ~75MB free.

If you have a file called /dev/SYSTEM then you are booting with SYSTEM loaded into RAM.

[Milhouse]

I'm running RBEJs latest Gotham build and 'top' is showing free memory of around approx 24MB after about 20hours of running. I've watched the memory usage as i've kicked of various things within XBMC, such as a backup (using the backup plugin) and playing various files and the free mem goes up and down between about 20MB and 35MB with no sign of issues, so I think this is just the Linux memory management using ram as a cache and free it up when needed.

In Frodo there was always much more memory free, closer to 300MB. To go from 300MB free in Frodo, to ~36MB (or less in your case) in Gotham might suggest something isn't quite as it should be. Then again it may be down to caching, but it's still a rather large difference.

I've just booted a Frodo build from 20 August, and with the XBMC GUI visible I have 325MB "free", which is 100MB more than a recent Gotham build. That alone is interesting, but could be accounted for by the increased level of caching in Gotham. However for free memory to drop as low as ~24MB (also add in the "buff" amount for the total free), which it never did in Frodo, is probably a cause for concern unless someone is able to categorically say it's not a problem. Since all the memory has been gobbled up by xbmc.bin though, it seems likely that it will be a problem, particularly when running other processes.

Frodo (fresh boot, 325MB "free"):

Code:

Mem: 192092K used, 189912K free, 0K shrd, 29108K buff, 106332K cached
CPU: 22.2% usr  0.0% sys  0.0% nic 77.7% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.54 0.62 0.34 2/93 1636
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
1115  1052 root     R     318m 85.2   0 22.2 /usr/lib/xbmc/xbmc.bin --standalone -fs --lircdev /var/run/lirc/lircd

rpi512:~ # free
             total       used       free     shared    buffers     cached
Mem:        382004     192124     189880          0      29108     106332
-/+ buffers/cache:      56684     325320
Swap:            0          0          0

Gotham (46MB "free"):

Code:

Mem: 347432K used, 34572K free, 0K shrd, 12076K buff, 71960K cached
CPU: 10.0% usr 20.0% sys  0.0% nic 70.0% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.39 0.64 0.71 1/87 12846
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
1113  1051 root     S     512m137.3   0 22.5 /usr/lib/xbmc/xbmc.bin --standalone -fs --lircdev /var/run/lirc/lircd

rpi512:~ # free
             total         used         free       shared      buffers
Mem:        382004       347432        34572            0        12076
-/+ buffers:             335356        46648
Swap:            0            0            0

[Trickname]

Please test LiveTv

I still can't get livetv to work correctly

here too

[rtenklooster]

Updated Gotham Branch

- updated Xbmc Gotham

- adopted patches from OpenElec git

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

Please test LiveTv

Not working for me. It starts loading it says but then the screen flickers and it stops. (tvheadend)

[Milhouse]

Just to demonstrate the boot memory difference between Frodo and Gotham, here's two such systems briefly playing the same HD movie, showing the free memory before/after: pastebin.

[doveman2]

Not just 128MB GPU, but yes, OpenELEC will, by default, load SYSTEM into RAM whenever it determines there is sufficient memory available (more than 102MB available, to be precise). On a 512MB Pi with 128MB GPU, there will be 382MB RAM available at boot.

However I don't see a significant performance difference with SYSTEM loaded into RAM, so have opted to have more free memory by adding "noram" to cmdline.txt.

If you are seeing 300MB free with Gotham, I've a sneaking suspicion you're not loading SYSTEM into RAM. A recent Gotham build (128MB GPU) with SYSTEM not loaded into RAM only has ~75MB free.

If you have a file called /dev/SYSTEM then you are booting with SYSTEM loaded into RAM.

I do have /dev/SYSTEM and the debug OSD currently shows 296000/382000KB but free -m shows

Code:

OpenELEC:~ # free -m
              total         used         free       shared      buffers
Mem:           373          350           23            0           42
-/+ buffers:                307           66
Swap:            0            0            0

---

LiveTV (Mediaportal PVR) isn't working for me either on the 31/08 build and it takes a looong time to reboot or poweroff.

EDIT: Reverted to the 18/08 build and both problems are fixed

[Milhouse]

I do have /dev/SYSTEM and the debug OSD currently shows 296000/382000KB but free -m shows

Code:

OpenELEC:~ # free -m
              total         used         free       shared      buffers
Mem:           373          350           23            0           42
-/+ buffers:                307           66
Swap:            0            0            0

When I talk about "free memory" I'm referring to the "-/+ buffers free" figure shown by the free command, which in your case is 66MB, so a lot lower than it would be with Frodo. This is the same as free+buffers from the "Mem" line above give or take a rounding difference, which should also be the same as free+buff+cached as reported by top.

Ah OK, one thing I've just noticed is that "free" in Gotham is no longer reporting the cached memory amounts (see post #587 for comparison of the Frodo and Gotham "free" output). Maybe this could explain the difference, as the "buffers free" figure reported by free no longer includes cached memory when in Frodo it was included, and in fact cached memory is now treated in Gotham as a component of "buffers used" (both interpretations are technically correct, as cached memory should be made available to processes if/when required, but until then is used to improve file system performance however the method of reporting now used by Gotham is decidedly less useful). Maybe it's another kernel 3.10/procfs related change. I've updated my monitoring script to work around this difference, and will report back if the memory usage continues to appear unusual.

Apologies for the (potentially) false alarm!

[f1vefour]

Anyone have a link for 2013.18.08 as rbej deleted it from the servers?

[Wanderlei]

Dunno if its xbmc (3.0.6 official) but DTS audio I can hear a ever so faintly drop in volume for a millisecond every 10 or 15 minutes if the tv or amp decodes the audio but if I make the xbmc decode the sound is fine.

I thought it might be the tv doing it when decoding audio but it occurs if the audio is passthroughed to the amp to decode as well, strange.

[rbej]

Updated Frodo Branch

- updated FFmpeg (1.2.3)

- updated firmware

Fix for out of sync hdmi audio after pause

Improved locking to hdmi display framerate

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

[popcornmix]

Dunno if its xbmc (3.0.6 official) but DTS audio I can hear a ever so faintly drop in volume for a millisecond every 10 or 15 minutes if the tv or amp decodes the audio but if I make the xbmc decode the sound is fine.

I thought it might be the tv doing it when decoding audio but it occurs if the audio is passthroughed to the amp to decode as well, strange.

It is impossible for xbmc to alter the volume when in passthrough mode (the encoded dts is passed through untouched). Therefore the issue is caused by the TV/receiver.

[evanspae]

Updated Gotham Branch

- updated Xbmc Gotham

- adopted patches from OpenElec git

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

Please test LiveTv

I'm affraid this build offers no improvements for me and in fact is worse than previous build ...

The issue of overwriting of guisetttings on reboot still continues very problematic
The new menu feature of changing pixel aspect ratio when playing a video works for video, but incorrect aspect ratio of home screen background and menu items still remain
I am also not able to play broadcast .ts H264 recordings
Live TV does not work

I am reverting back to earlier version OpenELEC-RPi.arm-Rbej-Version-Gotham-Branch(25.08.2013).tar.bz2 hoping it wont crash!

[Wanderlei]

Dunno if its xbmc (3.0.6 official) but DTS audio I can hear a ever so faintly drop in volume for a millisecond every 10 or 15 minutes if the tv or amp decodes the audio but if I make the xbmc decode the sound is fine.

I thought it might be the tv doing it when decoding audio but it occurs if the audio is passthroughed to the amp to decode as well, strange.

It is impossible for xbmc to alter the volume when in passthrough mode (the encoded dts is passed through untouched). Therefore the issue is caused by the TV/receiver.

Is it possible that it is a small gap in the audio stream being passed on not a drop in volume as such?

[popcornmix]

Is it possible that it is a small gap in the audio stream being passed on not a drop in volume as such?

It may cause a gap in the audio, or a receiver resync.

[rbej]

Updated Frodo Branch

http://forum.xbmc.org/showthread.php?tid...pid1497465