• 1
  • 10
  • 11
  • 12(current)
  • 13
  • 14
  • 156
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(2014-04-28, 17:19)delinend Wrote: Sorry.. Have not tested many of the lastest builds. But have now tryed #0427, and see some "none smooth" playback of DVD/ISO PAL25, that are interlaced.
If I set "Deinterlace video" = "Automatic", the video is still not smooth, and there is sometimes lip-sync problems.
If I playback other DVD/ISO's PAL25, that not are interlaced, there is no problems.
Thanks for that pointer. I also have random issues with PAL25 DVDs but never thought about checking deinterlacing. Will do so in my next testing round.
(2014-04-29, 00:34)popcornmix Wrote:
(2014-04-29, 00:21)Shanyel Wrote: That's my cmdline.txt
boot=/dev/mmcblk0p1 disk=/dev/sda1 ssh noram dwc_otg.fiq_fsm_enabled=0 quite

Not "enabled" but "enable".

oops didnt notice that
thanks!
(2014-04-29, 00:09)popcornmix Wrote:
(2014-04-28, 23:56)SSC_Jarod Wrote: I watch a strange behaviour in 3D picture quality since the release from 30th March r18050.
In this release the 3D Picture Quality is suberp smooth and sharp and it looks like you watch a non 3D movie in 1080p very clear. In the following releases i have particly slow downs, like there were a lot of frame drop and the picture Quality itself, has lost the smoothness and sharpness of the 30th March buld. Looks like sometimes unsharpen to me and after a little time my eyes react to 3D picture in not a good way Wink

Two friend of mine with also rasp, did confirm that and are stuck on that build. Is there something changed in the Settings that we must switch on/off since that release? Or can someone take a look at 3D Pic Quality from that build an e.g. The newest one?

Can you confirm that #0330 was the last good build and that #0401 was bad?
It doesn't look like anything relevant changes at that point. If you are not sure, can you test to find the first bad build?

Hi Popcornmix,

Will try from that build from 30th March on, but as i remember was the following build not as good in picture quality. Think i do it on weekend and give response ... Wink

Thx
J.
(2014-04-17, 17:40)postdeath Wrote:
(2014-04-17, 17:28)popcornmix Wrote:
(2014-04-17, 17:21)postdeath Wrote: I have had horrific performance problems in the recent past using Gotham builds on my original 256 Pi - is this something that can/will be fixed, or are the older Pi's just unable to run Gotham smoothly? Frodo still works perfectly (usb+sd, w/oc: 1000).

Should be fine. Can you try a clean install with gpu_mem=128 and report if that seem okay initially.
Gradually add any custom settings, add-ons and skins, and make a note of exactly what harms performance.

No problem, I'll do it over the weekend and get back to you, thanks. Blush It seems to have the biggest problems with stuff like poster and fanart, after a short while of scrolling, all library items will lose their images, and eventually even the skin background image will vanish (seen across many different skins)

A little later than promised, but I finally worked out what my problem was - I was manually importing my old config.txt after each install, and it appeared to have an accidentally uncommented conflicting gpumem command in there. I feel dumb as hell, but it's all working now. Thanks! Smile
(2014-04-29, 09:42)da-anda Wrote:
(2014-04-28, 17:19)delinend Wrote: Sorry.. Have not tested many of the lastest builds. But have now tryed #0427, and see some "none smooth" playback of DVD/ISO PAL25, that are interlaced.
If I set "Deinterlace video" = "Automatic", the video is still not smooth, and there is sometimes lip-sync problems.
If I playback other DVD/ISO's PAL25, that not are interlaced, there is no problems.
Thanks for that pointer. I also have random issues with PAL25 DVDs but never thought about checking deinterlacing. Will do so in my next testing round.
I connected a DVD drive and went through my collection, I can confirm the same.
PAL interlaced is not smooth. I only had one though.
(2014-04-29, 00:34)popcornmix Wrote:
(2014-04-29, 00:21)Shanyel Wrote: That's my cmdline.txt
boot=/dev/mmcblk0p1 disk=/dev/sda1 ssh noram dwc_otg.fiq_fsm_enabled=0 quite

Not "enabled" but "enable".
You got a spelling error more in there if you have not noticed quite should be quiet.
Why the noram "disk" if I may ask?
(2014-04-30, 01:58)tuxen Wrote: Why the noram "disk" if I may ask?

By default OpenELEC will load the whole of SYSTEM into RAM (ram disk) if there is enough free memory available, which there will be on a 512MB Pi with gpu_mem <= ~140.

The difference this makes in terms of performance is, IMHO, negligible, and I think you're better off adding "noram" and not having SYSTEM loaded into RAM, which results in about 110MB extra physical memory being made available to XBMC and the rest of the OS.
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.
Yeah I know the limit is actually 368MB so you can have 144MB GPU mem. And I get by fine with no fonts crashes or screwed up fanart, and even running the transmission service and tried pressuring it with all sorts of stuff, and never ran out out mem . I have not experimented much with this but sdram is surely faster than the sdcard. I do not see a major performance boost no but still there is some, so I was wondering why not utilize what you can.
Also skins such as amber if you use the widget bar addons is not restarted but kept running in mem and I never had trouble with this to. (I expect other confluence does the same there are just no way to return to them running other than creating a favorite.

What can you imagine use that much ram on a XBMC system only? 372MB minus 110MB is quite a lot, and in line with 256MB, and beyond what I can imagine anything using. It seems to me it gains more from some extra GPU mem if you set it higher than 128 (or 144) but again I see no trouble. Please don't misunderstand I'm just curious.

Ps. Naturally I do not use swap. I'm gonna do some more experimenting though.
SDRAM will be faster than SD card, but Linux will also cache the SD card file accesses so in my opinion you'll get similar performance with "noram" thanks to OS file caching, but without dedicating a fixed chunk of memory to load the entirety of SYSTEM into RAM

Linux will use whatever RAM is available for file caching, and give that memory back when a program needs it, whereas dedicating 110MB+ of RAM to a ram disk is memory that can't be used for any other purpose.

Bear in mind also that a significant proportion of SYSTEM is made up of code that most users won't ever be using, for instance the WiFi modules and drivers will all be sat in your RAM disk even if you don't have any wifi hardware.
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.
Sorry for my edits Danish is hard to translate properly into English.

I see your very valid points but still I have not seen this go above 252MB or is it me not testing properly, will play some more with this. So would you say a noram is better than 256/256 GPU split if you do not have gfx errors. Or is GPU mem utilized in a "similar way".

Thanks in advance..

Edit: do you have some tips on measuring these things?
(2014-04-30, 07:58)tuxen Wrote: I see your very valid points but still I have not seen this go above 252MB or is it me not testing properly, will play some more with this.

Everyone is different, if you're not starved of memory then there's no reason to change. Adding "noram" is simply an option if you want a bit more physical memory for the ARM CPU.

(2014-04-30, 07:58)tuxen Wrote: So would you say a noram is better than 256/256 GPU split if you do not have gfx errors. Or is GPU mem utilized in a "similar way".

If you've got a 256/256 gpu split then effectively you're already using "noram" as there isn't enough free memory to load SYSTEM. "noram" only has an effect if your gpu_mem is 140-160MB or less, as with "noram" added you won't be dedicating 110MB+ of physical RAM to a ram disk.

(2014-04-30, 07:58)tuxen Wrote: Edit: do you have some tips on measuring these things?

Not particularly, just try it and see if you can tell any difference in terms of performance. Obviously anyone that has programs that are running out of memory, then making another 100MB of memory available with the addition of "noram" should give a very obvious benefit.
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-04-27, 15:17)bagofcrap24 Wrote:
(2014-04-27, 15:00)carmenm Wrote: Hi ,

I am (was?) a raspbmc user. Yesterday i decided to try Openelec. I went for a "boot on SD and disk on NFS".
First it works great! Amazing job on your part and thank you!
It s clearly smoother than raspbmc (is it because on raspbmc i have also "boot on NFS"?).

I obviously went for this build as i was used to raspbmc test builds!
And so i have one question. Is there any easy update process without having to remove the sdcard and update the "KERNEL to kernel.img" and SYSTEM files?
Can it be done through SSH?

Thanks again for everything

It can be done easily through smb.
Just navigate to
\\ipofyourpi\
Drop the downloaded tar into the update folder and reboot your pi.
There are issues if your boot is on NFS but as it's on SD it will work fine
Thanks i will reactivate samba then Wink
(2014-04-27, 12:12)popcornmix Wrote:
(2014-04-27, 08:38)whiffyfuzzball Wrote: I have a single USB device installed - an official Microsoft media center remote control receiver. Nothing else, I never use USB storage, everything is played via NFS. Shared library using MySQL.

What's the best way to help debug this?

It's not happening for me, so it's possibly something in your setup.
First, can you try some older builds and confirm exactly when the problem appeared.
Second, can you try playing a video locally (from sdcard or USB) to see if that also has the issue.

OK, I have it borrowed down to this so far:

Works OK: OpenELEC-RPi.arm-devel-20140330204313-r18050-g2d44624
Doesn't work: OpenELEC-RPi.arm-devel-20140402115943-r18083-g960b3b5

I'm working through the builds in between but downloads are a little slow for me right now. Once I have it narrowed down to a single build I'll try the USB test.

I've also set debug mode to 1 in advancedsettings.xml and got this log file from the last pause:

13:04:01 11041.151367 T:2694837328 DEBUG: Pause -0.05,4.67 (A:10 V:01) EOF:0 FULL:0 T:1.60
13:04:01 11041.151367 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
13:04:01 11041.275391 T:2226123856 DEBUG: Received request to serve unknown md5 ''
13:04:02 11042.358398 T:2694837328 DEBUG: Resume 1.63,8.86 (A:01 V:01) EOF:0 FULL:0 T:1.60
13:04:02 11042.361328 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
14:11:53 15113.094727 T:2694837328 DEBUG: Pause -3562.94,-3558.96 (A:10 V:10) EOF:0 FULL:0 T:3.20
14:11:53 15113.132812 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
14:11:53 15113.882812 T:2008020048 DEBUG: Received request to serve unknown md5 ''
14:11:55 15115.297852 T:2694837328 DEBUG: Resume 3.23,10.10 (A:01 V:01) EOF:0 FULL:0 T:3.20
14:11:55 15115.302734 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1

14:11 is when the video started up again.

Paul
devel-20140401220047-r18074-gfa2d8e0 not OK.

Downloading http://netlir.dk/rbej/builds/MilhouseVH/...a2d8e0.tar now but only getting 2kb/sec so could be a while...
@MilhouseVH: i have a question about your xbmc builds. Do you build TexturePackager? Could you package the TexturePackager with it?
It appears that skin are A LOT faster when compiled. I would like to automate that on my pi but i would need TexturePackager for that.

Thanks
  • 1
  • 10
  • 11
  • 12(current)
  • 13
  • 14
  • 156

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