• 1
  • 40
  • 41
  • 42(current)
  • 43
  • 44
  • 156
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(2014-07-06, 13:57)0wing Wrote: I got errors on the database upgrade with #0706.

What was previous build that you ran? Can you post complete log (e.g. to xbmclogs.org).
@0wing: Are you able to upload your MyVideos79.db somewhere?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2014-07-06, 14:34)popcornmix Wrote:
(2014-07-06, 13:57)0wing Wrote: I got errors on the database upgrade with #0706.

What was previous build that you ran? Can you post complete log (e.g. to xbmclogs.org).
I was running #0703
xbmclogs is down currently. http://pastebin.com/Vm9f006D

(2014-07-06, 16:42)MilhouseVH Wrote: @0wing: Are you able to upload your MyVideos79.db somewhere?

https://www.mediafire.com/?2t16g2256c2vsam
@0wing: Thanks. In the meantime you'll need to revert back to #0703, and once booted you should delete MyVideos85.db so that any future fixed build will recreate it. Keep an eye on PR4985 for a fix.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2014-07-06, 17:12)MilhouseVH Wrote: @0wing: Thanks. In the meantime you'll need to revert back to #0703, and once booted you should delete MyVideos85.db so that any future fixed build will recreate it. Keep an eye on PR4985 for a fix.

Thanks, reverted back to 0703 for now.
(2014-07-06, 13:21)xer0 Wrote: Thanks Milhouse for adding Zram. Working here brilliantly. For anyone wanting to enable and try it here's my autostart.sh -

Code:
#!/bin/sh
#
# Autostart.sh

# Load Zram Module
modprobe zram

# Set Zram Compression (default lzo)
echo lz4 > /sys/block/zram0/comp_algorithm

# Set Zram Size
echo 64M > /sys/block/zram0/disksize

# Optimize Read Ahead (default 128)
echo 1024 > /sys/block/zram0/bdi/read_ahead_kb

# Enable Zram
mkswap /dev/zram0
swapon /dev/zram0

From my really quick test it looks like using LZ4 compression offers faster compression speeds but a lower compression ratio than LZO. I would rather have speed and performance over trying to squeeze as much into ram as I could.

One thing I might play around with later is the swappiness value. From what I understand, it's set low so not to swap as often to a physical swapfile to save on sd writes but that would not be a problem using Zram as the swap is contained entirely in ram so we can read/write as much as we want.

What kind of improvement did you noticed with that setup?

In the link you have:
3) Activate:
mkswap /dev/zram0
swapon /dev/zram0

mkfs.ext4 /dev/zram1
mount /dev/zram1 /tmp

In your post you do not speak of:
mkfs.ext4 /dev/zram1
mount /dev/zram1 /tmp

Isn't that needed?
@Mafarricos: Those are two separate examples of how zram could be used - 1) mkswap/swapon, and 2) mkfs.ext4/mount.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2014-07-06, 17:58)MilhouseVH Wrote: @Mafarricos: Those are two separate examples of how zram could be used - 1) mkswap/swapon, and 2) mkfs.ext4/mount.

Sorry for noob question. Still much to learn about Linux. Will try post suggestion and see if I notice some improvement loading streams.
Doing some tests with YouTube streams, with xer0 setup I notice 2-4 seconds improvement to open stream (from 12-15 seconds to load without zram to 10-12 seconds to load with zram). Since I click on button and the clip really start. Minimum noticed was really 2 seconds, but sometimes double the difference.

So it's some improvement Wink

Also tried in other streams and noticed the same kind of improvement.
@Mafarricos - presumably you have a 256MB Pi? How much memory is allocated to GPU? It's sort of counter intuitive to use RAM for swap - with even less physical RAM available for programs and data, the device should now swap sooner than it otherwise would have - but the compressed nature of zram may offset that downside in some (many?) cases.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Milhouse, I have a version b pi. With 112mb to GPU.
So you are saying the loading improvement isnt really because of the zram?
Or for a 512mb RPI, to use ram to swap isn't a big issue like in a 256mb?

About the question about GPU, for what I understand the GPU ram doesn't load faster or slower the streams, but is used to handle the decoding, so we only need more ram to GPU if video freezes or no image, for eg.
That was only so see how many ram would I have to the rest of the system?
(2014-07-06, 18:45)Mafarricos Wrote: Milhouse, I have a version b pi. With 112mb to GPU.

Yes, but is that a 256MB "b" or a 512MB "b"? I'm guessing the former, I just wanted to be sure.

(2014-07-06, 18:45)Mafarricos Wrote: So you are saying the loading improvement isnt really because of the zram?

No - it probably is, although it could also be due to the new build which seems to make about 7MB more RAM available to ARM compared with #0703. Repeat your test with zram disabled and see if you get the same performance benefit.

Edit: Forget the comment about #0706 making an extra 7MB available - I've just checked again and it's maybe only 1MB extra free on #0706. I thought I noticed a 7MB difference while creating interim builds but it may have been due to some SQL breakage in xbmc that resulted in less memory being used (eg. no movie or tv library being loaded!)

Though really I'm just pointing out that using RAM for swap is (to me at least) a little counter intuitive, but it is possible that zram swap has a benefit over traditional swap because of the compression.

(2014-07-06, 18:45)Mafarricos Wrote: Or for a 512mb RPI, to use ram to swap isn't a big issue like in a 256mb?

On a 512MB RPI, swap (zram or not) should be much less of an issue and rarely needed, if at all.

(2014-07-06, 18:45)Mafarricos Wrote: About the question about GPU, for what I understand the GPU ram doesn't load faster or slower the streams
I know, I just wanted to understand your test configuration by knowing how much physical RAM you had to begin with, and how much RAM had been allocated to to GPU (with the remainder being allocated to ARM).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Milhouse, mine has 512mb.

I made the test by loading manually and not in autostart.

Then made swapon, and tried a YouTube video, and took the time I mentioned, then made the command swapoff, and tried again the same video, did this about 2-3 times in 3 different videos.

So firmware was the same and the difference was the swapon or swapoff via ssh before loading YouTube videos.

I don't know if in the grand scheme, 2 seconds (or max 4 seconds in some cases) improvement is significance if can bring another problems on other aspects.

Xer0, do you also have this kind of improvements?

Only comparing with others can a pattern be discovered.
Like I say, it's all a bit counter intuitive - it's a little surprising that enabling zram swap on a 512MB Pi should have such an effect.

Can you confirm if the zram swap is actually being used after starting a YouTube video (check with "free" to see if if swap used is zero or not), or look at the zram statistics mentioned in the guide I linked to in the release post).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Well tried on another pi that I have, and I really don't see the same improvement... It seems sometimes better and other worst.

And using free the swap isn't being used.

So it seems that the swap isn't making difference to load faster.

So now feels like a placebo effect Wink
  • 1
  • 40
  • 41
  • 42(current)
  • 43
  • 44
  • 156

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)8