• 1
  • 177
  • 178
  • 179(current)
  • 180
  • 181
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
(2014-01-31, 01:01)cognitive alien Wrote: I'm new to this but looks like something weird with lircd hogging loads of cpu
Load average: 5.35 5.02 3.36 3/96 403
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
271 1 root R 538m144.4 0 72.2 /usr/lib/xbmc/xbmc.bin --standalone -fs --lircdev /var/run/lirc/lircd

This is the latest build above.....

PS should add using cec on the tv remote, dunno if that causing issues....

How do you know it's lircd hogging the cpu? Make sure you don't have any scrolling text on the display, that will keep the CPU busy.

(2014-01-31, 02:01)sunwarming Wrote: The other issue is when a menu or something in loading in openelec in the bottom right corner comes up "Processing" or "working" and a white wheel comes up next to it, but the wheel isn't moving like in xbmc 12. It is static and looks like the PI has frozen, but it hasn't in reality.

See here. There is a solution, to use an animated GIF, but the OpenELEC build system doesn't play nice with binary patches so for the time being (as this is a development build, and a working spinner isn't something I consider critical, given the alternative) I've just disabled the CPU-intensive animation in my builds.
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-01-31, 04:16)tuxen Wrote: Just a thought; are you sure your laptop can output 25p? Not many gfx cards can.
My PC for example can not output 25p or 30p only 24p.

Hi tuxen.

Yes, my laptop is a Lenovo X1, with an onboard Intel HD Graphics 3000. And no problem to select 24 and 25p output on it. But I can only select this in 1920x1080 resolution. Not in other resolutions :-)
Thanks to @popcornmix and @Milhouse

The new r17182 works flawless, on all my framerate content now :-)
Edit: ups things move fast here.. Smile

(2014-01-31, 05:36)nola mike Wrote: Kind of a dumb question, but I'm trying to use stable releases the easy way--saw that I can just dump the tar file in the .update folder, but I can't seem to find it?
http://wiki.openelec.tv/index.php/Updating_OpenELEC
You have to extract the .tar and put the files from the folder "target" to the folder ".update" on openELEC and reboot. 7zip, winrar, tar Smile, etc can extract the files.

You should be able the reach .update via. Samba \\openelec\update or using winscp, make sure display hidden files is enabled if using the latter. If you still can't find it create it "mkdir /storage/.update" via ssh or use winscp again. A . in front of the file/folder means that its hidden, so a normal "ls" won't list it, you can you the option "ls -a" to display it.

Hope you got a few general pointers.
(2014-01-31, 05:41)MilhouseVH Wrote: Load average: 5.35 5.02 3.36 3/96 403
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
271 1 root R 538m 144.4 0 72.2 /usr/lib/xbmc/xbmc.bin --standalone -fs --lircdev /var/run/lirc/lircd

How do you know it's lircd hogging the cpu? Make sure you don't have any scrolling text on the display, that will keep the CPU busy.
There you go tried to sort out the formatting better Blush
I saw a constant 100% cpu on screen usage, went to PC, putty in, did top and lircd is using 72.2% cpu, rebooted and it went back to normal
I got a few PIs and just started overclocking etc so will do some more testing over the weekend
Quick q for the gurus, I got a few folders which contain ripped DVDs ie lots of different files in there, how can I configure to just 'play the folder'? Or another workaround?
Cheers
PS formatting still not right, doing my head in now lol
(2014-01-31, 05:41)MilhouseVH Wrote:
(2014-01-31, 02:01)sunwarming Wrote: The other issue is when a menu or something in loading in openelec in the bottom right corner comes up "Processing" or "working" and a white wheel comes up next to it, but the wheel isn't moving like in xbmc 12. It is static and looks like the PI has frozen, but it hasn't in reality.

See here. There is a solution, to use an animated GIF, but the OpenELEC build system doesn't play nice with binary patches so for the time being (as this is a development build, and a working spinner isn't something I consider critical, given the alternative) I've just disabled the CPU-intensive animation in my builds.

Thank you for the answer! I'll leave it as you have configured it, it's better to have a good performance from the PI than having a wheel turning. Thanks!
(2014-01-31, 12:19)cognitive alien Wrote: I saw a constant 100% cpu on screen usage, went to PC, putty in, did top and lircd is using 72.2% cpu, rebooted and it went back to normal

That's not lircd, that's xbmc.bin. Any number of things could cause xbmc.bin to consume CPU - an addon running in the background, or text scrolling in the GUI, are typical causes of high CPU.

PS. Use code tags.
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-01-31, 12:39)MilhouseVH Wrote:
(2014-01-31, 12:19)cognitive alien Wrote: I saw a constant 100% cpu on screen usage, went to PC, putty in, did top and lircd is using 72.2% cpu, rebooted and it went back to normal

That's not lircd, that's xbmc.bin. Any number of things could cause xbmc.bin to consume CPU - an addon running in the background, or text scrolling in the GUI, are typical causes of high CPU.

PS. Use code tags.

well this is a fresh install so could it be the 'news' scrolling at the bottom of the screen and how do I inhibit it? yes sorry about code tags, was in a hurry to try and condense the post, doh
IMO rpi builds should come with RSS disabled by default.
http://wiki.xbmc.org/index.php?title=RSS_ticker
 
  • Intel NUC Kit DN2820FYKH ~ Crucial DDR3L SO-DIMM 4GB ~ SanDisk ReadyCache 32GB SSD ~ Microsoft MCE model 1039 RC6 remote
(2014-01-31, 13:06)xbs08 Wrote: IMO rpi builds should come with RSS disabled by default.
http://wiki.xbmc.org/index.php?title=RSS_ticker

IMO it should. I submitted a PR with this change in, but it wasn't accepted.
sraue (openelec maintainer) was against it, as openelec has a custom RSS feed.

I use an advancedsetting.xml (with MySql settings in), so I just add:
Code:
<lookandfeel>
        <enablerssfeeds>false</enablerssfeeds>
    </lookandfeel>

and no RSS (you don't even get the option in the gui).
(2014-01-31, 12:59)cognitive alien Wrote: well this is a fresh install so could it be the 'news' scrolling at the bottom of the screen and how do I inhibit it? yes sorry about code tags, was in a hurry to try and condense the post, doh

System -> Settings -> Appearance -> Skin -> Show RSS news feeds [enable/disable]

(2014-01-31, 13:06)xbs08 Wrote: IMO rpi builds should come with RSS disabled by default.
http://wiki.xbmc.org/index.php?title=RSS_ticker

What's actually quite bad is that the default Settings level of "Basic" doesn't allow the RSS feed to be disabled - the user has to switch to Standard level first, then the "Show RSS news feeds" option becomes visible. I would be content to leave RSS enabled by default on the Pi assuming the GUI setting to disable it is visible by default (it's easy enough to change), but hiding this option is just going to lead to a lot of unnecessary grief for first-time users. Really bad decision IMHO.

(2014-01-31, 13:32)popcornmix Wrote: IMO it should. I submitted a PR with this change in, but it wasn't accepted.
sraue (openelec maintainer) was against it, as openelec has a custom RSS feed.

That's unfortunate, and I really can't see the logic of imposing the RSS feed on users when it impairs the user experience to such an extent that the first thing any user will do is switch it off. But now with the option being hidden by default it's going to result in a lot of new users having a really poor experience, and not knowing how to resolve it. That makes absolutely no sense to me, and it's not in OpenELECs interest either as users will blame OpenELEC for the awful performance, and maybe switch to a different distribution, or blame the Pi and buy more expensive hardware (or give up entirely).

(2014-01-31, 13:32)popcornmix Wrote:
Code:
<lookandfeel>
        <enablerssfeeds>false</enablerssfeeds>
    </lookandfeel>

I'll probably drop this into the next release. It's not really something I want to do, as when the user returns to stock releases they'll be faced with the RSS feed again, but it may be better than nothing.
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.
I often come across posts by people who have tried OpenElec on the Pi and found the performance to be too poor. I'm sure quite a few of these bad experiences will be down to this crazy RSS feed. Unfortunately, to a new user it's not going to be at all obvious why or how to 'fix' it.

I too think this should be disabled by default.
(2014-01-31, 14:03)MilhouseVH Wrote: What's actually quite bad is that the default Settings level of "Basic" doesn't allow the RSS feed to be disabled - the user has to switch to Standard level first

The RSS option should be visible for all setting levels in future builds. That's half the problem solved... Smile
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-01-28, 00:53)popcornmix Wrote:
(2014-01-28, 00:25)LehighBri Wrote: Nailed it! I just tried millhouse's latest build in the next post that includes this fix and EDL support works again in omxplayer. Man you're fast... thanks so much for this. Really appreciate the attention to this. So that solves my issue... maybe allen87 should try this too??

Good to hear it worked.
Thanks for the test case - that's the key to getting a bug fixed, find a simple way of provoking the failure and get me to see it failing.

Thanks again popcornmix. Are there any plans to submit an official PR to XBMC to get this out of newclock3 and into the XBMC master branch? It's by no means critical, just curious.
(2014-01-31, 15:45)LehighBri Wrote: Thanks again popcornmix. Are there any plans to submit an official PR to XBMC to get this out of newclock3 and into the XBMC master branch? It's by no means critical, just curious.

Yes. Merge windows are first ten days of each month, so starts tomorrow. I'll go through newclock3 and submit PRs for any confirmed improvements.
Technically this EDL one is a bug fix, so could be accepted outside of a merge window. Should be submitted within new few days.
  • 1
  • 177
  • 178
  • 179(current)
  • 180
  • 181
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223