Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - 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 Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-12-22

(2013-12-21, 21:01)postdeath Wrote: Is anyone else seeing Pi lockups after leaving video on pause for an extended (15min+) length of time?

If it is streaming from an internet site, then it will be too high a cache buffer.
The cache keeps expanding while paused and you will crash when memory is exhausted.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Cy4n1d3 - 2013-12-22

I'm playing local files here, it also doesn't matter if it's 720p, 1080p, DTS, AC3.

The last lines in log before crash are:
Code:
11:55:48 276.983948 T:3044516368   DEBUG: OnKey: 230 (0xe6) pressed, action is Pause
11:55:49 277.100403 T:2734146640   DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:0
11:55:49 277.100677 T:2734146640   DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
11:55:49 277.101562 T:2734146640   DEBUG: COMXPlayer - CDVDMsg::PLAYER_SETSPEED speed : 0
11:55:49 277.134857 T:3044516368   DEBUG: CAnnouncementManager - Announcement: OnPause from xbmc
11:55:49 277.135376 T:3044516368   DEBUG: GOT ANNOUNCEMENT, type: 1, from xbmc, message OnPause
11:55:49 277.176239 T:3044516368   DEBUG: ------ Window Init (DialogSeekBar.xml) ------
11:55:50 278.444061 T:3044504656 WARNING: CActiveAE::StateMachine - signal: 18 from port: timer not handled for state: 5
Nothing suspicious I think?

What's interesting though: it's not the whole RPi crashing, it looks more like a 'hotboot' where only the xbmc interface gets re-initialized.
I'm going mild overclock here, but it does not look like total freeze like I know it from overclocking desktop pcs so I guess that's not the problem.

€dit: it seems to be related to overclocking in my case.
As soon as I pause playback, cpu utilization goes up to 100% (is that intended?) and stuff freezes sooner or later.
I removed all overclocking-related things from my config and now the 'hot-reboots' are gone.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2013-12-22

I don't know if something changed in the kernel/firmware but with the latest MilhouseVH image I'm getting the best results ever with dvb-t dongle connected directly to the Pi.
On my previous tests (latest probably about 2 months ago) with all the tuners I've tried I got bad results (I've a nice collection because of the Pi).

Today I've tried a generic RTL2832 device, Ezcap WandTV (IT9135 based) and a Generic It9135 device (don't have time to test all my devices).
I had no issues with the first two but the third acted horribly (as usual) and this is a device that I use 24x7 on my regular pvr server.

Anyway, I just thought this is related to the development builds, I probably need to find time to test all my usb dvb-t collection with the Raspberry Pi on standard distribuition set a PVR server only and start a new thread but darn I'm too lazy.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-12-22

(2013-12-22, 14:40)dhead Wrote: I don't know if something changed in the kernel/firmware but with the latest MilhouseVH image I'm getting the best results ever with dvb-t dongle connected directly to the Pi.

If you pay attention to the OpenELEC github you'll see that the kernel is updated very frequently...
Code:
ae306f2 2013-12-21 16:53:03 +0100 linux: update to linux-3.12.6
0e754c9 2013-12-13 00:06:11 -0500 linux: update to linux-3.12.5
7907569 2013-12-12 13:53:52 +0100 linux: update to linux-3.12.5
ce268cd 2013-12-08 21:18:46 +0100 linux: update to linux-3.12.4
a83f5a3 2013-12-05 04:17:12 +0100 linux: update to linux-3.12.3
53c1450 2013-11-30 19:35:08 -0500 linux: update to linux-3.12.2
f382a12 2013-11-22 20:15:18 -0500 linux: update to linux-3.12.1
22b9efa 2013-11-10 13:26:03 +0200 projects/RPi: update to linux-3.12. cleanup linux-3.11
f613297 2013-11-07 17:39:19 +0200 Revert "projects/RPi: update to linux-3.12"
a4b1d2b 2013-11-06 22:54:20 +0200 projects/ATV: update to linux-3.12
92a8b79 2013-11-05 12:43:58 +0200 projects/RPi: update to linux-3.12
11fda5c 2013-11-04 16:56:56 +0200 linux: update to linux-3.12
0bccbb3 2013-10-18 21:06:12 -0400 linux: update to linux-3.11.6
fa627eb 2013-10-14 13:13:14 +0300 linux: update to linux-3.11.5
a23aa85 2013-10-05 10:51:24 -0400 linux: update to linux-3.11.4
b267925 2013-10-03 00:49:04 +0200 linux: update to linux-3.11.3
8e0f873 2013-09-29 18:19:18 +0200 linux: update to linux-3.11.2
82cfa87 2013-09-15 23:18:13 +0300 linux: update to linux-3.11.1
325902a 2013-09-08 21:30:45 +0200 linux: update to linux-3.10.11
225f9a5 2013-09-04 00:55:04 +0200 linux: update to linux-3.11
195119e 2013-08-30 16:38:35 +0200 linux: update to linux-3.10.10
e5a6e2e 2013-08-22 04:43:07 +0200 linux: update to linux-3.10.9
6b36c7c 2013-08-17 13:52:32 +0200 linux: update to linux-3.10.7
3dfb9a5 2013-08-17 13:44:05 +0200 linux: update to linux-3.10.7

Problems will come, and problems will go. Sometimes in a matter of days... Smile

So in the last two months there have been many changes, not least the kernel and firmware.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-12-22

Talking of kernel/firmware updates, I realised the other day that I've been running my remote receiver and tuner plugged into the second half of my hub (it's seven ports, with four of them cascaded off the first chip internally). Several months ago, these ports were unusable, so I think something must have been changed in the kernel to fix this, which is cool Smile

With the recent build, I can start a channel from the EPG normally again but there's some new bugs which are causing some entries in the EPG to be blank (it seems to be long programmes which are near the end, maybe 75% and the text showing the title is missing, so maybe the bug is that these titles are "sticking" at the start time of the programme and not being shifted to still show when the EPG current time is near the end of the programme). It's also allowing me to go backwards in the timeline to the start of the day, whereas before it would stop at the current time and bring up the popup menu instead.

Also, the advancedsettings.xml tweak below that makes clicking OK start the programme instead of showing the Info and then having to select Switch to this Channel isn't working with this build, which is a bit of a pain.

<pvr>
<showepginfoonselect>false</showepginfoonselect>
</pvr>

EDIT: This tweak is working again now. Not sure why it wasn't earlier but nevermind Smile


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - javaboyuk - 2013-12-22

Guys
Having issue with latest MilHouse and rbej bulid when playing Blu-ray image or .mkv file.

The image will freeze at just over 54 mins (about half way) for both builds on the iso image
and I have proven the issue with Popcornmix on 2 cut down .mkv files of that period.
I was then given a new start.elf file called start_dts.elf that I installed.

If I use the start_dts.elf file from Popcornmix (see post from popcornmix .here ) then the mkv files nolonger
freeze but there is a slight frame jump at arround the old frame freeze point (tested with rbej build)

However the iso file will crash xbmc about 2 minutes in on the Milhouse build, I have some logs of that for:
So this is the debug with the xbmc restarting at the end.
100655

On the rbej build the picture will do sort of a fast "catchup" of ~1 sec about 4 secs before the old freeze point with the iso file.

Thanks


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - TBCdevil - 2013-12-23

I think it's worth noting that f2fs can be best tested on bottleneck areas of the pi. Areas where there are lots of cpu and disk io is compacted into one task like the full library scan. We could split them up into a first scan and an update. Scans can be done over nfs shares or local but need to be noted. Also note when you're using USB or sd. The test itself should be something like scan 50 movies so everyone has similar results.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Swifty - 2013-12-23

@TBCdevil - Exactly what I was thinking, more accurately I have been wondering if it would help with the PVR feature as that does a bunch of EPG reads / writes everytime XBMC fires up (which for ~120 channels can take a while on the Pi)

Will hopefully get some time to do a bit of testing with that over the next few days..


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2013-12-23

(2013-12-18, 19:49)gummibaum Wrote:
(2013-12-18, 11:18)xbs08 Wrote: Interesting benchmarks...

http://www.phoronix.com/scan.php?page=news_item&px=MTQ1OTE

http://www.solid-run.com/phpbb/viewtopic.php?f=2&t=1373

well,
the results may be interesting, but:

  1. The first link goes to an article which did some "cherry picking" from the complete results provided here.
    There you'll see, that F2FS may be ways worse than EXT4.
  2. The second linked document shows, that F2FS is faster when writing, but does provide (near) zero improvement for reads.
    In everyday life, reads account for >> 90% of "disk" accesses
    (and I'm pretty confident this is the case with XBMC as well).
So: no need to hurry implementing F2FS.


Mathias

Actually.. Speaking of the system itself, depending on the situation alot more writing occurs and not so much read to the sdcard, if you have a 512MB board and set your gpusplit to max 132MB or the normal 128MB the entire SYSTEM image ie. archlinux plus XBMC is run entirely from ram.

That leaves the plugins and the library functions. Many addons gather metadata and caches it in a database nowadays (plus all the art thumbs constantly created) this means the first time the addon bumps into a media file it needs to gather metadata for the item and write it to the "cache" database used for this. Read speeds are about the same so reading the metadata back is not really a bottleneck, so you might waste more time gathering metadata. And from this perspective and ofcause which addons used it actually means that it is slower overall. At least for me.

Its exactly the same when scanning media for the library(s) for example let me give you a rough example:
My library has around 500 movies and around 15 tv-shows they are located on a external self powered 3TB harddrive connected directly to the RPi.
Anyway, on a class 10 sdcard it took well over 2hours+ if not more to scan it, and I don't know how long to extract the movie info and make thumbs afterwards. Database file is only ~5MB.

Switching to a fast USB3 stick and the scan took around 20mins! About as fast as my PC. Consistantly.

Not only that, browsing my media afterwards the fanart and covers where now loaded instantly, literary as fast as I can move the "cursor" up and down, no more waiting 1/2 a sec to 1 or two.

I realize this has nothing to do with file systems, but it says a lot about where the bottleneck lies; the sdcard memory technology so anything that can speed this up without breaking any stability is more than welcome IMHO.

I am overclocked though at 1025/500/500/+4 and force_turbo=1 its been running like that for almost a year now and I never had any sdcard corruption problems I hear about now and then, setting anything higher just makes it crash or not boot. Funny thing is when I switched to USB storage I actually had to clock down 25Mhz because it was drawing more power, setting overvolt higher than +4 didn't help.

I have 2 RPi's, one from UK and one from China both 512MB (I had 256MB board also but donated it to a friend), oh and 2 cl10 sdcard's, and 1 cl6. All combos give same results and overclocking limits (settings) are the same, no.#1 runs runs latest official OE, no.#2 RPi runs raspbian btw. At the moment the XBMC RPi uses a 1.8" harddrive, raspbian a 32GB Kingston mini sdcard.

This is just sharing my experience thanks for reading if you did Smile Hope some of it is useful.
Rgds tuxen


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-23

Before doing the scan test export your library or it will fetch from inet.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - TBCdevil - 2013-12-23

Hey guys, I will also try to plan some tests after Christmas. To busy atm. Please document your tests as good as possible. I'll make a spreadsheet of all the findings.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Doktor-X - 2013-12-23

i'm using latest OpenELEC "Gotham-RPi.arm-devel-20131220135623-r16601-g3ded391" and have storage on usb 2.0 flash drive formated to f2fs file system but for some unknow reason my setting constantly restart itself


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-12-23

f2fs is buggy - i have the same problem with f2fs


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2013-12-23

After a proper shutdown/reboot?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-12-23

It's crash and after a reboot the settings are lost.

I have a problem in one movie - in one position the movie hangs always! When i switch before do english audio DTS( no HD MA) the movie running with no problem. On windows pc with XBMC i have no problem.

Quote:ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 2h 1mn
Bit rate mode : Variable
Bit rate : Unknown / 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossless / Lossy
Title : Deutsch DTS-HD-MA 5.1 @ 1841 Kbps
Language : German
Default : Yes
Forced : No



This forum uses Lukasz Tkacz MyBB addons.