Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi (/showthread.php?tid=140518)



RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-07-22

(2013-07-22, 21:43)doveman2 Wrote: Where's the correct place to report bugs like this?

Not sure, to be honest. The Weather add-on is, I think, a core part of XBMC.

Hammering the GUI could be a bug, or just poor design, but either way it usually goes unnoticed when stuff is developed on a quad-core i7 with 8GB RAM... I'm not sure if efficiency is a goal for XBMC (I'd like to think it is) but I've said it before: all code should be tested on the least capable officially supported device before being signed off or accepted. At least that's a rule I'd be enforcing if I was project manager!! Smile

(2013-07-22, 21:43)doveman2 Wrote: I'm also seeing higher CPU (77-87%) when video (mpeg2/ts) is paused and no better when the screen dims, than when it's actually playing (44-58%), which is a pain as if you have to go and do something else and pause the video, you'd like it to use minimal power while it's not doing anything. I can only guess this is because the pause OSD appears in the top-right and this triggers XBMC's issues with redrawing the screen. Strangely though, this problem doesn't happen if I bring up the timeline OSD whilst playing the video (slight increase from 45% to 54%), or even the full Now Plaiying OSD (still the same when I pause though, regardless of what's displayed at the time).

I don't have any ts files to test with, is it just mpeg2/ts files? I just did a quick test of an SD movie over NFS, and when playing top shows 14-18% but while paused (Conflued Modified with small OSD in top right corner) the CPU load increases to a solid 25%, which is...strange.

Test post.


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-07-22

test post


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-07-22

I've suggested in a PM to rbej that he starts a new thread as the forum is getting a little cranky where this thread is concerned - I've got a 50/50 chance of this post appearing...!


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-07-22

+1


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-07-22

(2013-05-10, 12:25)popcornmix Wrote:
(2013-05-09, 10:51)tfft Wrote: Rbej (et al), I've used Gotham_01.05.2013 which seems to work pretty well.
I did notice that ogv (OGG video) files don't play well - in fact, they start and
then the video starts stuttering and the audio dies and everything freezes.

Can someone please confirm.

VP6 and VP8 are supposed to be supported as well, right ? Other encodings ?

Software video codecs (theora, vp6, vp8, mjpeg) are still in the experimental phase.
Sometimes, (when frames span multiple 80K packets) they stall.
This is a firmware bug, that I need time to investigate.

There is an easier fix, on the xbmc side of using fewer, larger packets for software video codecs
which I may fall back on if the firmware fix is particurly tricky.

I've fixed an issue with software codecs (VP6/VP8/Theora/MJPEG) where the input frames span multiple packets.
You'll need updated firmware. You can download start_x.elf/fixup_x.dat from here:
https://github.com/Hexxeh/rpi-firmware

or wait for an updated build.

I've also added support for MJEG files without huffman tables, which are quite common form webcams.


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-07-22

(2013-07-22, 21:56)MilhouseVH Wrote: I just did a quick test of an SD movie over NFS, and when playing top shows 14-18% but while paused (Conflued Modified with small OSD in top right corner) the CPU load increases to a solid 25%, which is...strange.

GUI updates at ~10 fps when video is playing. When video is not playing it tries to update at vsync (if vsync enabled) or 100fps (if vsync disabled).
As cpu required for (low bitrate) video decode is quite low, it's not surprising that pausing or stopping video increases cpu.

Enabling vsync and selecting a 24fps HDMI mode will reduce cpu.


RE: OpenELEC Testbuilds for RaspberryPi - Koloss - 2013-07-22

(2013-07-22, 13:08)spjonez Wrote:
(2013-07-22, 10:10)Koloss Wrote: How move my exists Openelec do usb-stick?

Steps for Windows are here, MilhouseVH provides steps in Linux in the next post:
http://forum.xbmc.org/showthread.php?tid=150297&pid=1288945#pid1288945

Thanks, but my usb-stick test as slowly as with only my sd-card class 10,

Booting:
39sec with sd-card
49sec with usb-stick

In other tests i cannot see a different!


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-07-22

(2013-07-22, 23:44)popcornmix Wrote: When video is not playing it tries to update at vsync (if vsync enabled) or 100fps (if vsync disabled).

Craziness! Wink


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-07-22

(2013-07-22, 23:44)popcornmix Wrote: GUI updates at ~10 fps when video is playing. When video is not playing it tries to update at vsync (if vsync enabled) or 100fps (if vsync disabled).
As cpu required for (low bitrate) video decode is quite low, it's not surprising that pausing or stopping video increases cpu.

Enabling vsync and selecting a 24fps HDMI mode will reduce cpu.

My TV only supports 60hz and I've enabled vsync. It seems rather nuts that the pause GUI (which is completely static), whether the timeline/Now Playing OSD is showing before pausing, is "updating" at 60fps and pushing the CPU high.

Does guires support anything lower than 720p? As my brother will be using the composite output at 720x576i, it might be an idea to set gpu_mem=128 so that OE loads entirely into RAM and perhaps reducing the guires might reduce the CPU usage a bit for him as well.

(2013-07-22, 23:46)Koloss Wrote: Thanks, but my usb-stick test as slowly as with only my sd-card class 10,

Booting:
39sec with sd-card
49sec with usb-stick

In other tests i cannot see a different!

With a class 10 SD card it can be hard to find a faster USB stick. My Transcend USB3 stick is about the same (28MB/s) for reads and a bit slower (10MB vs 12MB) for writes. I tested my sticks on my PC first to find a good one, as even some USB3 sticks have worse write speeds than some USB2 sticks.

The only reason I'm using the USB really is to minimise the chance of corruption when overclocking, which is a good reason Wink


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-07-23

(2013-07-22, 23:56)doveman2 Wrote: Does guires support anything lower than 720p? As my brother will be using the composite output at 720x576i, it might be an idea to set gpu_mem=128 so that OE loads entirely into RAM and perhaps reducing the guires might reduce the CPU usage a bit for him as well.

guires is just an upper limit. It will default to the display size (e.g. 720x756) when that is below guires, so nothing to change there.


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-07-23

(2013-07-23, 00:06)popcornmix Wrote: guires is just an upper limit. It will default to the display size (e.g. 720x756) when that is below guires, so nothing to change there.

Cool, thanks.


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-07-23

(2013-07-22, 21:56)MilhouseVH Wrote: Not sure, to be honest. The Weather add-on is, I think, a core part of XBMC.

Hammering the GUI could be a bug, or just poor design, but either way it usually goes unnoticed when stuff is developed on a quad-core i7 with 8GB RAM... I'm not sure if efficiency is a goal for XBMC (I'd like to think it is) but I've said it before: all code should be tested on the least capable officially supported device before being signed off or accepted. At least that's a rule I'd be enforcing if I was project manager!! Smile

Yeah, I'm never sure whether to report bugs in the main XBMC support forum or the RPi support forum, as it's hard to know if they just affect the RPi or not (as you say, these things are probably not noticeable or considered unimportant on a high-powered desktop PC).

Quote:I don't have any ts files to test with, is it just mpeg2/ts files? I just did a quick test of an SD movie over NFS, and when playing top shows 14-18% but while paused (Conflued Modified with small OSD in top right corner) the CPU load increases to a solid 25%, which is...strange.

Playing an SD movie over SMB gives me 30-45% CPU on XBMC. I was running with debugging enabled though, so maybe the overlay is adding some. Running at 720p with vsync enabled and no overclock.

I just tried adding a NFS folder with Add Videos and playing from that and it's about the same even with debugging disabled and monitoring with top instead (30-37%). Takes about 10s to start playing as well.

I just got the OS NFS Mount working by not using any options with the mount command and so I tested using that and it's much the same as the XBMC mount.


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-07-23

(2013-07-23, 01:28)doveman2 Wrote: I just tried adding a NFS folder with Add Videos and playing from that and it's about the same even with debugging disabled and monitoring with top instead (30-37%). Takes about 10s to start playing as well.

My Pi is overclocked to 1GHz (500Mhz for core, 600Mhz for sdram) which may go some way to explain the difference between 18% on my Pi and 30-45% on a stock 700Mhz Pi. It takes about 5 potatoes to start playback.

(2013-07-23, 01:28)doveman2 Wrote: I just got the OS NFS Mount working by not using any options with the mount command and so I tested using that and it's much the same as the XBMC mount.

Popcornmix says it's working for him with those NFS options, so maybe there's a difference in your server settings. Identifying which NFS option is the problem could help identify what setting needs changing on the server.


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-07-23

(2013-07-23, 01:36)MilhouseVH Wrote: My Pi is overclocked to 1GHz (500Mhz for core, 600Mhz for sdram) which may go some way to explain the difference between 18% on my Pi and 30-45% on a stock 700Mhz Pi. It takes about 5 potatoes to start playback.

Yeah, that would probably explain it Wink

Quote:Popcornmix says it's working for him with those NFS options, so maybe there's a difference in your server settings. Identifying which NFS option is the problem could help identify what setting needs changing on the server.

It seems it's proto=udp it doesn't like, as adding just that back caused it to stop working again. Adding back all the other options except that and it works fine as well. CPU usage is no lower than before but that's to be expected.

I do have both UDP and TCP enabled in Hanewin.


RE: OpenELEC Testbuilds for RaspberryPi - spjonez - 2013-07-23

(2013-07-22, 23:46)Koloss Wrote:
(2013-07-22, 13:08)spjonez Wrote:
(2013-07-22, 10:10)Koloss Wrote: How move my exists Openelec do usb-stick?

Steps for Windows are here, MilhouseVH provides steps in Linux in the next post:
http://forum.xbmc.org/showthread.php?tid=150297&pid=1288945#pid1288945

Thanks, but my usb-stick test as slowly as with only my sd-card class 10,

Booting:
39sec with sd-card
49sec with usb-stick

In other tests i cannot see a different!

I've never timed boot, I never turn my Pi off. Try quickly scrolling through TV/movies with full screen fan art at high res (720p+) with a skin other then Confluence, it's easily 5-6x faster and a lot more stable at higher overclock settings. If you aren't seeing a speed difference loading fan art, or you can crank your Pi to 1Ghz and not have it crash in 5min then you probably aren't running off USB. Did you leave the storage partition on your SD card or delete it? What does your cmdline.txt look like?


This forum uses Lukasz Tkacz MyBB addons.