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



RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - MONSTA - 2015-05-17

(2015-05-17, 06:56)miigotu Wrote: Yes, it is very noticeable. For example, simply entering tvshow library takes like 3 seconds on yours, and is almost instant on his. Starting a video with his is about 3 seconds, and yours sometimes can be up to 15 seconds or more, but usually in the 8ish range.

Yep. System loading 4-5 seconds faster. Probably because there is no splash video at starting. Thank you for information.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

(2015-05-17, 06:56)miigotu Wrote: Yes, it is very noticeable. For example, simply entering tvshow library takes like 3 seconds on yours, and is almost instant on his. Starting a video with his is about 3 seconds, and yours sometimes can be up to 15 seconds or more, but usually in the 8ish range.

I would suggest performing a variety of tasks with a Chris Swan (aka Chimney) build, then perform the exact same tasks with the latest test build, and then upload both debug logs - determining when/where the delays are occurring might be enough for a smart developer to produce a fix.

Although more likely it will require identification of the exact build when the delays first started.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

(2015-05-17, 07:21)MONSTA Wrote: Yep. System loading 4-5 seconds faster. Probably because there is no splash video at starting. Thank you for information.

Quite possibly, as depending on the length of the splash video Kodi will wait until it has played out.

Code:
touch /storage/.config/splash.disable

will disable the splash video.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - miigotu - 2015-05-17

Milhouse, awhile back, I reported about auto play next file having issues, thats when things started going downhill for me, between ~418 and 422. BTW, OMXPlayer is explicitly enabled in my guisettings.xml, so both yours and CS builds are using OMX, because with dvdplayer I almost cannot play anything decently.

I also had an issue similar awhile back, and I had to change the way my NFS shares were defined on my host. When did nfs4 come into play entirely? It's also possible that a change to my nfs exports could be defined better.

/export is defined with thes flags:
rw,sync,no_root_squash,no_subtree_check,insecure,nohide,crossmnt

everything under /export (videos,music,pictures,downloads) is mounted with these flags:
rw,sync,no_root_squash,no_subtree_check,insecure


Re: RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

(2015-05-17, 07:46)miigotu Wrote: Milhouse, awhile back, I reported about auto play next file having issues, thats when things started going downhill for me, between ~418 and 422.

Yes, a problem not reproducible by anybody else, and after this request to try a wired connection in place of WiFi (as the problem seemed to be network related) I can't find any further replies on the subject from you.

So maybe start from there, try a wired connection. Though why there should be a difference between a Chimney build and test builds in terms of WiFi performance I've no idea, since they're virtually identical in that respect - the vast majority of changes are to Kodi, with no WiFi related changes, and I doubt any of the kernel differences will be impacting on WiFi (though maybe it's not impossible...)


Re: RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

(2015-05-17, 07:46)miigotu Wrote: I also had an issue similar awhile back, and I had to change the way my NFS shares were defined on my host. When did nfs4 come into play entirely? It's also possible that a change to my nfs exports could be defined better.

Not sure about nfs4, but both Chimney and test builds are using basically the same version of libnfs (1.9.7). You could always test with an OS NFS mount and eliminate libnfs as a variable.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - miigotu - 2015-05-17

(2015-05-17, 08:01)Milhouse Wrote:
(2015-05-17, 07:46)miigotu Wrote: Milhouse, awhile back, I reported about auto play next file having issues, thats when things started going downhill for me, between ~418 and 422.

Yes, a problem not reproducible by anybody else, and after this request to try a wired connection in place of WiFi (as the problem seemed to be network related) I can't find any further replies on the subject from you.

So maybe start from there, try a wired connection. Though why there should be a difference between a Chimney build and test builds in terms of WiFi performance I've no idea, since they're virtually identical in that respect - the vast majority of changes are to Kodi, with no WiFi related changes, and I doubt any of the kernel differences will be impacting on WiFi (though maybe it's not impossible...)

Yeah I running it over eth is not an option for me (even to test it, because I would have to unmount my tv from the wall and take it in my bedroom, lol), but after I enabled 'NO ACK' the connection became stable enough to at least play videos, even if it was slower than before, and there were no other reports so I left it alone. I also had some SD corruption around that time, and once I re-imaged the SD completely instead of a .update. it helped some as well.

Anyways, I don't know how else to create nfs shares besides defining them in /etc/exports and using nfs-kernel-server. my /export/Videos for example is a bind mount to /media/2TB/Videos (just as every nfs v4 guide I can find says).

It would seem the difference would have to be wireless related, (even though it doesnt make sense since the driver for my dongle hasn't been updated in OE for 2 years) as just navigating the gui wouldn't be affected by nfs shares issues, but the gui would be slowed because of mysql querying issues. If it is having difficulty getting results back from the db, it would take longer to switch library windows. Starting/changing video could be affected by nfs shares, but more likely wireless since wireless must be the issue for the gui slowness. And it cant be the mysql alone because that wouldnt cause slow starting of videos.

Anyways, I'll try some tests tonight. Just figured out about the paste command in OE, makes it easier. Honestly, I'm not great at being a tester, since I tend to find a way to ameliorate the issue and avoid intentionally going back and breaking my system, because it irritates the wife lol.

EDIT:
I have improved my nfs export definitions, which should eliminate any possible problems there. this is a much better/simpler approach than the guide on the wiki or the ubuntu wiki. Details here: https://gist.github.com/miigotu/c7df712997cd8745bd7a

crossmnt and nohide on the top /export are especially important, fsid=0 important for NFSv4.
Without crossmnt and nohide, clients need to mount each sub-mount independantly, and kodi expects to be able to traverse these folders without remounting.
From man exports:
Quote:However, some NFS clients do not cope well with this situation as, for instance, it is then possible for two files in the one apparent filesystem to have the same inode number.

Which both guides mislead you to do.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

Presumably you don't have a PC display into which you could temporarily plug the Pi while connecting with wired ethernet? Or a very long ethernet cable? Smile

Something to check over WiFi would be iperf (available in Unofficial repo) - this would allow you to measure your tcp bandwidth over the network link between your Pi and a computer on the "other end" of the network link (ie., your Ubuntu server) to see if your WiFi bandwidth has changed between a Chimney build and a test build. You can also measure your udp bandwidth with iperf, as NFS might use udp depending on whether you're using OS or nfs:// (libnfs) mounts on the Pi.

It's always possible a Connman update (or similar) has knackered something, but this wouldn't really explain the difference between Chimney and test builds as we're both in sync as far as Connman is concerned....

To be honest your server exports aren't that important (assuming they're actually working), it's how you're accessing the export(s) from OpenELEC which is likely to have more of a bearing on your NFS performance, as OS mounts are generally considered to be better performing (and more configurable, you can choose tcp or udp, window size etc.) than libnfs nfs:// mounts.

I've also just tested the latest Chimney build "OpenELEC-RPi2.arm-6.0-devel-20150516171755-r20889-ge756b7c.tar.bz2" on a Pi2 (wired, nfs://, MySQL, stock Confluence) and I can't see any obvious difference in performance - time to start a movie and entering movie/tvshow/music libraries is all comparable with that of a test build (#0516).


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

(2015-05-17, 09:15)miigotu Wrote: EDIT:
I have improved my nfs export definitions, which should eliminate any possible problems there. this is a much better/simpler approach than the guide on the wiki or the ubuntu wiki. Details here: https://gist.github.com/miigotu/c7df712997cd8745bd7a

crossmnt and nohide on the top /export are especially important, fsid=0 important for NFSv4.

You need to explain if you're using OS mounts in OpenELEC, or libnfs nfs:// mounts in Kodi (on OpenELEC).

libnfs doesn't support NFSv4, and will connect using NFSv3.

I'm not even sure if OpenELEC supports NFSv4 "natively", as an OS mount, and you may need to use mount.nfs4 installed from Unofficial (see: PR67), so you could be wasting your time (or simply causing yourself more grief) by trying to use NFSv4 exports - just stick with NFSv3, as this works no problem...

Edit: Reviewing your previous posts from April when you first reported the play-next issue, you were using nfs:// at the time, which is libnfs and doesn't support NFSv4... Mind you, it's the same libnfs in both Chimney and test builds, so wouldn't explain any performance difference.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - mcelliott - 2015-05-17

The 516 build is causing my RPi2 to reboot randomly.

Kodi log at

http://xbmclogs.com/pyklrqlav

shows that it is crashing. I don't have the experience to work out the problem. Happy to provide more info if needed, but I'll need to drop back to an old version pretty soon to keep the family happy!


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - popcornmix - 2015-05-17

(2015-05-17, 13:40)mcelliott Wrote: The 516 build is causing my RPi2 to reboot randomly.

Most crashes look like:
Code:
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0084a3c0 in PVR::CPVRClient::GetDriveSpace(long long*, long long*) ()
#1  0x0061cfd4 in PVR::CPVRGUIInfo::UpdateBackendCache() ()
#2  0x0061d900 in PVR::CPVRGUIInfo::Process() ()
#3  0x00956cc4 in CThread::Action() ()
#4  0x00957530 in CThread::staticThread(void*) ()
#5  0x76d14d88 in ?? () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

So looks like a PVR issue. Is #516 the first bad build and #515 is okay?


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - Milhouse - 2015-05-17

There seem to be several crashlogs in one post which makes it rather confusing... The only crash relating to #0516 (I think, as I'm looking at the humongous log on a tablet) is a SQLite access to the EPG database, so my advice would be to delete the EPG*.db files and restart Kodi.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - mcelliott - 2015-05-17

(2015-05-17, 14:13)Milhouse Wrote: There seem to be several crashlogs in one post which makes it rather confusing... The only crash relating to #0516 (I think, as I'm looking at the humongous log on a tablet) is a SQLite access to the EPG database, so my advice would be to delete the EPG*.db files and restart Kodi.

After a couple of reboots, it seems to have settled down. It is happens again, I will delete the EPG database files and see how that goes.

Best wishes,

Mark


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - zaphod24 - 2015-05-17

Same thing happened to me. I just deleted everything in the database directory and then re-enabled my TV plugin (mythtv) and went back through setting it up again. This is the second or third update where I've had to do that, somewhere between 0510 and now.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2 - MONSTA - 2015-05-17

(2015-05-17, 07:31)Milhouse Wrote:
(2015-05-17, 07:21)MONSTA Wrote: Yep. System loading 4-5 seconds faster. Probably because there is no splash video at starting. Thank you for information.

Quite possibly, as depending on the length of the splash video Kodi will wait until it has played out.

Code:
touch /storage/.config/splash.disable

will disable the splash video.
Thank you. Splash really slows system loading.