• 1
  • 79
  • 80
  • 81(current)
  • 82
  • 83
  • 89
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2
Between OpenElec 6.0 beta 1 and beta 2 (and the corresponding test files), I found that the OpenElec still image boot screen was now terribly skewed and the video offsets no longer applied.

I narrowed the issue down to the following settings in my config.txt file. These offsets now work perfectly for my Samsung 4k TV. Unfortunately, the boot screen is still skewed...

overscan_scale=1
overscan_left=30
overscan_right=30
overscan_top=20
overscan_bottom=20
(2015-06-25, 02:42)optics Wrote: Between OpenElec 6.0 beta 1 and beta 2 (and the corresponding test files), I found that the OpenElec still image boot screen was now terribly skewed and the video offsets no longer applied.

If it's a change between Beta 1 and Beta 2 you should be able to narrow it down by working back through the test builds until you find the last build with a working boot screen.
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.
All I can say is wow for the difference with the libnfs update over wifi.

Browsing UI is faster, starting videos is no lag now, and the stream is much less likely to go out of sync/speed or stutter.

Scanning/updating library was hella faster than before, switching profiles and booting as well.

I actually saw a buffering bar for the first time in like forever, where normally it would have frozen or playback would have went bonky.

It doesn't fix my problems over wifi 100% but the difference is night and day so far.

RPi2/MySQL Central DB/Wifi RTL8192DU/Local network NFS shares in kernel mode on media server

EDIT:
https://github.com/plieven/libnfs/commit...bf53a08367 big help.
Keeping show paused for hella long and now it starts right back up and plays fine

Only time I had my previous playback speed/sync fubarishness was after a 10min skip.
I'm wired with nfs:// mounts (FreeNAS server) and when I briefly tested the latest libnfs changes I do recall thinking that video playback seemed to start quicker than before, but for some reason didn't investigate further (it's also entirely possible I could be imagining any difference).

(2015-06-25, 03:30)miigotu Wrote: RPi2/MySQL Central DB/Wifi RTL8192DU/Local network NFS shares in kernel mode on media server

Just so there's no misunderstanding, you're using nfs:// mounts rather than OS NFS mounts?

I must admit it wasn't clear what effect the libnfs changes would have but glad to hear they're positive.

Edit: I've just run some tests comparing #0623 with #0624, calculating the time difference between "CNFSFile::Open - opened" and various other playback events that follow, and there seems to be no significant difference with the updated libnfs, at least over wired anyway, with playback starting in 0.1s-0.2s in most cases (SD and HD TV episodes) and 0.9s-1.1s for HD BluRay movie rips with DTS-HDMA soundtracks. I sometimes forget how well the Pi performs that I begin imagining things!
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.
@Milhouse its something with the stability of the connection
The commit message 'As a consequence we start dropping TCP connections which are still alive.' makes alot of sense, as my mounts definitely are using tcp

Yes, I use regular nfs:// mounts (libnfs).

The issue is that the nfs reliability degrades over time, and I before I had to restart the nfs service on my server often, seemingly the nfsd instances were maxed out or some cache was maxing out and never freeing. I assume this is due to the dropped connections moted in the commit log from above, and Kodi would just create a new connection. After this happens alot the available resources on the server are depleted (not enough nfsd)

There were also some potential leak issues there in those commits that were fixed as well, maybe thats the difference.

Also, I don't think it's the initial open of the connection that is sped up. It's that there are less dropouts and random speed bottoms.
Before I would see the little waiting spinner in bottom right corner for a few seconds on any action or starting a video, now its so fast I never even see a spinner.

It's not 100%, sometimes I still get a little lag while a video is playing for a few seconds, possibly followed by a quick speedup to catch and resync audio/video.
Wireless has been hell for me on my Pi2 for the most part, with several different adapters and routers. It's just not stable enough of a connection.

Overall, very happy those commits were merged to libnfs upstream.
(2015-06-24, 12:56)popcornmix Wrote: Accurate bug reports, with logs and possibly photos of the screen will help me identify problems more quickly.

I'll investigate at the weekend when I have a bit more time on my hands and can extract and clean up the debug log and make photos - screenshots would obviosly do no good. I tested TAB and SBS, and both worked, but sometimes the projector would either not switch to 3D, or not back after stopping the movie. Thank you for your ongoing work!
Possibly silly question since I was on holiday for a week and missed all of those builds... Is the sdhost driver the default for the SD card now, ie should dtoverlay=sdhost be removed from config.txt? How do we know if we're using the new faster driver? I have the following now in dmesg:

[ 1.372836] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.425137] mmc0: new high speed SDHC card at address 59b4
[ 1.425645] mmcblk0: mmc0:59b4 SDU16 14.9 GiB

Before there was something explicit about the new driver.
(2015-06-25, 16:22)zaphod24 Wrote: Possibly silly question since I was on holiday for a week and missed all of those builds... Is the sdhost driver the default for the SD card now, ie should dtoverlay=sdhost be removed from config.txt? How do we know if we're using the new faster driver? I have the following now in dmesg:

It is still optional. Enable in config.txt.

Code:
cat /proc/device-tree/soc/mmc@7e300000/status

will identify if the old mmc driver is in use (if it reports "okay"). If disabled you will be using the new sdhost driver.
Thanks! I get disabled, so I am still using the faster new sdhost driver.

Much like user gendo, I turned the PTS timestamps back off as I was having some stuttering with news tickers watching live TV when it was enabled. With that small tweak, the latest builds are working great on my rpi2. Thanks for all the hard work!
(2015-06-25, 20:34)zaphod24 Wrote: Much like user gendo, I turned the PTS timestamps back off as I was having some stuttering with news tickers watching live TV when it was enabled. With that small tweak, the latest builds are working great on my rpi2. Thanks for all the hard work!

and @gendo - do you see this in recordings? A sample file that requires PTS to be off would be useful.
I'll upload one with a small clip tonight from CNNHD
Test environment:
  • Device: Raspberry Pi 2
  • OE/Kodi version: OpenElec 5.9.2 (Kodi 15 beta 2) and with the latest test build (#0624)
  • PVR backends: Both tvheadend and VDR backends running on the Pi 2.
  • Receivers: Multiple DVB-T dongles (all of which run on RTL2832).
Test results:
  • Both of the mentioned backends work perfectly well with my DVB-T dongles when running on OpenElec 5.0.8.
  • Neither of them work with OpenElec 5.9.2 or with build #624.
    They seem to identify the device, but are unable to find channels or otherwise interact with it.

I don't know how helpful this post is, since I don't have a lot of information to go with it yet.
Just thought I'd point that out FWIW.
@Halastra: Thanks for the report but this will need to be handled by the OpenELEC team, presumably there is an issue with the RTL2832 hardware and latest 4.x kernel (it's supported by the 4.1 kernel so should be working). I'd suggest opening a thread on the OpenELEC forum.
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.
(2015-06-25, 00:59)Milhouse Wrote: You'd normally disable the Kodi splash by adding <splash>false</splash> to advancedsettings.xml - maybe your as.xml has gone AWOL?

That is indeed what happened. my advancedsettings file somehow went missing. All is well now. Thanks. Didn't think of check it
New OpenELEC Isengard build #0625: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.1.0 #1 Thu Jun 25 21:03:20 BST 2015 armv6l GNU/Linux

# vcgencmd version
Jun 23 2015 18:20:38
Copyright (c) 2012 Broadcom
version 144b1da894429d00352f650408d9b1a436302f7d (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150625210232-#0625-g275b1e7 [Build #0625]

# vcdbg log msg 2>&1 | grep DTOK
001568.637: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (275b1e7a, changelog) and tip of XBMC master (6f9dfa48, changelog) with the following modifications: Build Highlights:
  1. Potentially improved database access through string key reuse
Build Details:
  1. OpenELEC:
    • linux: fix TechnoTrend S2-4600 DVB-S receiver (PR:4212, 1 commit, 1 file changed)
    • linux: add patch for Hauppauge HVR-2205/2215/2255 support (PR:4214, 1 commit, 1 file changed)
    • mpfr: update to mpfr-3.1.3 (8b98f122)
    • libinput: update to libinput-0.18.0 (a719434f)
    • curl: update to curl-7.43.0 (ef23bf30)
  2. XBMC:
    • fixed: Don't do GetLength() off-thread is it may be (b)locked by a pe… (PR:7334, 1 commit, 2 files changed)
    • [pvr] bump pvr.vbox to 1.3.4 (PR:7341, 1 commit, 1 file changed)
  3. pvr.vbox:
    • changed LogGuideStatistics() usage to not require holding the lock (e5545572)
    • use StringUtils::CompareNoCase() the proper way (fixes #73) (0a31aa63)
    • split RetrieveExternalGuide() into separate methods (0d1e0295)
    • don't call Initialize() in the constructor, call it explicitly to (ce0fa969)
    • always load a default channel map before attempting to load any stored (a2d5c789)
    • unify the variable naming scheme in GuideChannelMapper (eb26d57a)
    • bump version to 1.3.4 (729feff1)
  4. newclock4:
    • New commits in this build:
      • force repository update in post-install/uninstall (744f821b)
      • changed: Don't blindly enable filecache for any internet stream. If it is required for specific situations, it should be hinted there (3bcaece2)
      • optional speedup of ResultQueries using string key reuse (207a57fb)
    • Commits no longer in build:
      • [libnfs] Add streaming cache (d21672c0)
      • force empty repository refresh on browse (9fdc1796)
      • fixed: Don't do GetLength() off-thread is it may be (b)locked by a pending read() (fixes #16046) (5ccadbd1)
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.
  • 1
  • 79
  • 80
  • 81(current)
  • 82
  • 83
  • 89

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 214