• 1
  • 40
  • 41
  • 42(current)
  • 43
  • 44
  • 89
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2
(2015-05-16, 13:28)wrxtasy Wrote: Yes agreed, HEVC decoding is better than it was previously was but I see about a 1.2Mb/s limit if a clip has fast action scenes. (1Ghz Turbo Overclocked)

What is CPU usage like? I have one file that is <1 Mb/s 720p and fails to keep up and all cores are around 50%
Yet I have others that are much higher bitrate and play well (with all 4 cores around 90%)

Seems to be something in the encoding options that affects whether multithreaded decode works well or not. It's being investigated.
If you provide a sample file that doesn't play well then I can give it to Peter (who is optimising the code) to look at.
2 samples of hevc 720
https://drive.google.com/file/d/0B9_XmyO...sp=sharing
https://drive.google.com/file/d/0B9_XmyO...sp=sharing
I was having massive issues with the new shiny pfcd_hevc_optimisations.patch in my builds, kodi was just restarting if I tried to play any video (I found the culprit see below).
I'm not using Openelec, however my OS is quite similar and I'm using almost same package versions as Milhouse so I decided to post my findings so the devs see them.

First:
If kodi is running under unpreviliged user some tweaks to udev are necessary to give right permissions to the new vcio and vcsm devices:

cat /etc/udev/rules.d/10-vchiq-permissions.rules
Code:
SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"
SUBSYSTEM=="bcm2708_vcio",GROUP="video",MODE="0660"
SUBSYSTEM=="vc-sm",GROUP="video",MODE="0660"

Second I do not know if this is the intended behaviour but with pfcd_hevc_optimisations.patch ffmpeg (the binary) can now play videos on my pi2 (lol)

ffmpeg -re -y -i some_movie.mp4 -strict -2 test.mp4
The video is 1080p h264/aac.

The interesting part is:
Code:
GPU allocated at 0xfbbe8000
Allocated display 1920 1080
frame= 1334 fps= 12 q=31.0 Lsize=    8050kB time=00:00:22.33 bitrate=2952.3kbits/s    
video:8017kB audio:6kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.336678%
... ctrl +c
Closing GPU

Cpu usage was quite high, but the video looked very good on my screen Rofl
(2015-05-16, 15:19)asavah Wrote: cat /etc/udev/rules.d/10-vchiq-permissions.rules
Code:
SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"
SUBSYSTEM=="bcm2708_vcio",GROUP="video",MODE="0660"
SUBSYSTEM=="vc-sm",GROUP="video",MODE="0660"

These should be defaults on an updated raspbian image. OE runs as root so these aren't required.
If you are on another OS, then these should be added
(2015-05-16, 10:03)miigotu Wrote: Edit: Is the 'OpenELEC Dev Updater' add-on usually run a day or two behind? I only see 0513 as latest there so it may have been upgrading from 0512->0513, I'm on a Chris Swan build now so I cant check kodi.old.log -.-

Ping @Leopold: The image file name changed recently due to this PR, and the addon needs to take this into account. Sad

For now you'll need to update manually.
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-05-16, 16:40)Milhouse Wrote:
(2015-05-16, 10:03)miigotu Wrote: Edit: Is the 'OpenELEC Dev Updater' add-on usually run a day or two behind? I only see 0513 as latest there so it may have been upgrading from 0512->0513, I'm on a Chris Swan build now so I cant check kodi.old.log -.-

Ping @Leopold: The image file name changed recently due to this PR, and the addon needs to take this into account. Sad

For now you'll need to update manually.

You probably just need to check for add-on updates manually. I released an update to the add-on yesterday.
Leopold's Repository: Home of LibreELEC Dev Updater ...
(2015-05-16, 13:28)wrxtasy Wrote: As an example testing on a 1.8Ghz ARM A5 / ODROID-C1 using ffmpeg. HEVC clips that struggle on a 1Ghz Overclocked RPI2 play fine on the OC1. Those with 2Ghz or greater ARM SoC devices that support the NEON parallel processing instructions set will be happy.
The C1 has hevc hardware decoding, it does 1080p @ 60fps without issue. I'm not sure what the maximum supported bitrate is.
With build #508 on a RPi B, I couldn't get TVheadend working. tvheadend and TVheadend HTSP Client were enabled but I just got Connection Lost messages and Page Not Found for http://192.168.1.85:9981. Tried rebooting and didn't help.

Update to #515 and had the same problem. I disabled and re-enabled tvheadend and was still getting Connection Lost messages but then after a while it started loading the guide and I was able to access the config from my browser, so I don't know if that was a coincidence.

I didn't have debug logging enabled unfortunately but maybe there's something in the log that will show what was going on anyway. This is just the 01_Kodi.log, so let me know if you want to see any of the others: http://pastebin.com/m4C6yLAv

EDIT: Didn't work that well with #515 either unfortunately. As soon as I went into the TV section I just got an unresponsive black screen and eventually had to power-cycle to reboot. I'm guessing it couldn't handle the fact that I'd I deleted some channels via the browser config. After rebooting, I was able to open the EPG but starting a channel it's a jerky mess, with the overlay showing errors in the 1,000s and 10,000s of % on the S line. I did get a debug log this time: http://pastebin.com/RMQwwVm0

EDIT2: Better news on the RPi v2 front though. It seems OE have finally updated the drivers or something and now my USB tuner works with it as well. I never did get a reply on the OE forums to my bug report, so I don't know what was wrong before. Anyway, tvheadend works OK on that and I'm not getting the terrible playback that on get with the B. There is a problem in that if I toggle fullscreen back to the EPG to look for another programme and then go back to fullscreen video, the video is frozen and only the audio continues to play. It buffers when I switch back and then again a few seconds later but the only way to unfreeze the video is to stop and restart the channel. Can anyone else using tvheadend say if this has always been like this or if it's changed recently, as I've only just got it working I've got nothing to compare with.

I can't really see any benefit with deinterlacing on compared to it off. I tried manually selecting all the different modes but I still see jaggies/blurring when things like peoples hands are moving. Is there anything we can do to improve that? I'm using a plasma 720p TV but my brother will be using a CRT TV via composite, so I'm more concerned with improving it for him, as it will be his main tuner since his freeview box is dying, whereas my TV has a built-in HD tuner and I'll probably only use tvheadend occasionally for recording programmes.

I just realised the v2 was on #507 when I made the above observations but I've updated to #515 now and it's the same. I've posted a debug log where I started TV and then switched to the EPG and back as well: http://pastebin.com/xF4AUt1P
Disregard
New OpenELEC Isengard build #0516: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.0.2 #1 Sat May 16 22:27:26 BST 2015 armv6l GNU/Linux

# vcgencmd version
May 13 2015 14:58:12
Copyright (c) 2012 Broadcom
version 8e0e0dbfe92be77d6355082451280d32f5bf0ff3 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150516222637-#0516-ge756b7c [Build #0516]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (e756b7c5, changelog) and tip of XBMC master (823f85a9, changelog) with the following modifications: Build Highlights:
  1. Update libplatform
  2. Latest librtmp/KSV patches
Build Details:
  1. OpenELEC:
    • u-boot: fix compile, update patch for udoo (PR:4154, 1 commit, 3 files changed)
    • platform: update to platform-1.0.9 (1f6099e9)
    • kodi-platform: update to kodi-platform-054a42f66 (3e382c37)
    • update kodi-binary-addons (c2e7b435)
    • libssh: update to libssh-0.7.0 (7cb6abee)
    • kodi: update dcadec patch (d45d29b5)
    • kodi: dont break if built without dcadec support (7e50f948)
    • projects/*/options: enable dcadec support for all projects (1c6daf82)
    • projects/WeTek_Play/patches/kodi: add patch to force IEC958 Audio and remove temporary patch to Allow audio passthrough, recommend from @fritsch, thanks much (12609c55)
  2. XBMC:
    • [depends] fix (lib)platform build (PR:7144, 1 commit, 1 file changed)
    • [gui] fix window activation (PR:7125, 4 commits, 7 files changed)
    • renderer: fix wrong subtitle position when not fullscreen (PR:7098, 1 commit, 2 files changed)
    • ffmpeg: fix 8ch audio conversion on Windows (PR:7138, 1 commit, 1 file changed)
    • [lang] update of internal addon language files (6c647a39)
  3. pvr.hts:
    • [debian] fix packaging once more: correct install file permissions (PR:30, 1 commit, 1 file changed)
  4. newclock4:
    • New commits in this build:
      • dvdplayer: more ff/rw fixes (977976f9)
      • librtmp: Update to latest patch (79df688f)
    • Commits no longer in build:
      • add libplatform to kodi-platform depends (c4da7bec)
      • introduce new force window activation which do not check for active modals (a0fa4b8c)
      • force activate window screen calibration in CGUIDialogVideoSettings (68d9fea5)
      • force activate fullscreen window with CApplication::SwitchToFullScreen() (6e842311)
      • corrects format + indentation (320f9aa0)
      • squash: shadertoy: Fix include file path (ffeb97af)
  5. Additional commits/pull requests/changes not yet merged upstream:
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-05-16, 18:11)Leopold Wrote:
(2015-05-16, 16:40)Milhouse Wrote:
(2015-05-16, 10:03)miigotu Wrote: Edit: Is the 'OpenELEC Dev Updater' add-on usually run a day or two behind? I only see 0513 as latest there so it may have been upgrading from 0512->0513, I'm on a Chris Swan build now so I cant check kodi.old.log -.-

Ping @Leopold: The image file name changed recently due to this PR, and the addon needs to take this into account. Sad

For now you'll need to update manually.

You probably just need to check for add-on updates manually. I released an update to the add-on yesterday.

Yes, I got the update about two hours after posting that, and a few new versions popped up lol.

So for my previous report of the white screen: Due to the addon not showing the newest build, I am now not totally sure which version I was on and which I was updating to. Unless someone else reports a similar issue I'm not gonna worry about trying to do 5 or so downgrade/upgrades unless I have the issue when I swap back to latest Milhouse build from the Chris Swan one I am running now.

Not sure what the major differences are between these builds as I can't seem to find a detailed build log for Chris Swan builds, but 5/12-5/15 (that's all I've tried) Chris Swan builds are insanely fast for me compared to Milhouse and Official release and beta builds lately, in the GUI, starting videos over nfs, and seeking. i also use a central MySQL db.

Can anyone point me to detailed information about what is included in Chris Swan builds?
Chris Swan builds are nightlies of master (usually a slightly older Kodi master, with only stable newclock4 commits), so you need to look at the OpenELEC github for specific commits.

https://github.com/OpenELEC/OpenELEC.tv/commits/master

Another way to think of a Chris Swan build is that it's the same as mine, but without all of the differences that are documented in my release notes.

When you say videos start more quickly, is this comparing omxplayer with omxplayer and dvdplayer with dvdplayer - remember that dvdplayer is the default in some builds, not sure about Chris Swans, maybe you're using omxplayer in his build and dvdplayer in mine?

If you're sure there's a performance difference it would be useful to know when the test builds became so much slower, as whatever is causing the degradation may well find its way into the Chris Swan builds eventually

It should also be possible to pinpoint the delays by analysing/comparing your debug logs from both builds, for instance the elapsed time from pressing "play" to when the movie starts, which should be similar in both builds but if demonstrably slower in a test build, that would be interesting.
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-05-17, 06:03)Milhouse Wrote: Chris Swan builds are nightlies of master (usually a slightly older Kodi master, with only stable newclock4 commits), so you need to look at the OpenELEC github for specific commits.

https://github.com/OpenELEC/OpenELEC.tv/commits/master

Another way to think of a Chris Swan build is that it's the same as mine, but without all of the differences that are documented in my release notes.

When you say videos start more quickly, is this comparing omxplayer with omxplayer and dvdplayer with dvdplayer - remember that dvdplayer is the default in some builds, not sure about Chris Swans, maybe you're using omxplayer in his build and dvdplayer in mine?

If you're sure there's a performance difference it would be useful to know when the test builds became so much slower, as whatever is causing the degradation may well find its way into the Chris Swan builds eventually

It should also be possible to pinpoint the delays by analysing/comparing your debug logs from both builds, for instance the elapsed time from pressing "play" to when the movie starts, which should be similar in both builds but if demonstrably slower in a test build, that would be interesting.

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 do think there is something new included, (somewhere back around #409 or #419, can't remember I'll have to search back in this thread for my post about it) because when I first started using your builds it was insanely fast back in the beginning of april, when I moved from 5.0.5/5.0.8.

I'll try and get some testing done sometime soon, when I get a break form working on issues in SickRage. I've also been playing around with building OE myself too, and doing some test builds with an updated RTL8188EU driver, as the one in OE is almost 2 years old and the newest doesnt even need patched for the kernel OE 6.0 is using atm. How stable and quick the Chris Swan builds have been have kept me from wanting to screw with it the past few days though lol.
(2015-05-16, 19:59)doveman2 Wrote: Can anyone else using tvheadend say if this has always been like this or if it's changed recently, as I've only just got it working I've got nothing to compare with.
TVHeadend has not been running well for about the last month or so on the Isengard nightlies. Any of them in fact. Even Android and Linux nightlies are a mess. The ease of Managing channels has actually gone backwards compared to Helix. Instead of 2 steps to hide a channel it now takes a user into the channels manager. Why I ask Why revert to this difficult way of doing things when it was all so easy in Helix ? Sad

Whenever I select the EPG, Isengard instantly crashes. You can place money on the outcome everytime.
Serious bugs, time to contact the Author methinks. Sad

(2015-05-17, 06:58)wrxtasy Wrote: Whenever I select the EPG, Isengard instantly crashes. You can place money on the outcome everytime.
Serious bugs, time to contact the Author methinks. Sad

I posted download links to debug-enabled builds if you need detailed crashlogs for the tvheadend maintainer(s):

http://forum.kodi.tv/showthread.php?tid=...pid2005981
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
  • 40
  • 41
  • 42(current)
  • 43
  • 44
  • 89

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