•   
  • 1
  • 72
  • 73
  • 74(current)
  • 75
  • 76
  • 111
  •   
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1
(2015-03-14, 23:44)Milhouse Wrote: That's a bug in Kodi core, I believe, for which you have a ticket open - as and when a fix turns up I'll include it.

Thanks! I'm hopeful this will get sorted out sooner rather than later. I think you guys have spoiled me with quick resolutions to RPi issues and this is the first time I'm waiting on a fix for a core Kodi issue.
(2015-03-14, 23:07)ImpreZa Wrote: With my RPi 2 its all working great! And I can no longer make it get stuck on the splash on the RPi.

I had the same problem, see this post for my solution:

http://forum.kodi.tv/showthread.php?tid=...pid1954973

(2015-03-15, 04:58)zaphod24 Wrote:
(2015-03-14, 23:44)Milhouse Wrote: That's a bug in Kodi core, I believe, for which you have a ticket open - as and when a fix turns up I'll include it.

Thanks! I'm hopeful this will get sorted out sooner rather than later. I think you guys have spoiled me with quick resolutions to RPi issues and this is the first time I'm waiting on a fix for a core Kodi issue.

My ticket was closed and the fix is supposedly in https://github.com/xbmc/xbmc/pull/6729

Perhaps that can be included in the next build?
(2015-03-15, 20:40)zaphod24 Wrote: My ticket was closed and the fix is supposedly in https://github.com/xbmc/xbmc/pull/6729

Perhaps that can be included in the next build?

It's been merged, so will be in next build automatically.
(2015-03-15, 20:49)popcornmix Wrote:
(2015-03-15, 20:40)zaphod24 Wrote: My ticket was closed and the fix is supposedly in https://github.com/xbmc/xbmc/pull/6729

Perhaps that can be included in the next build?

It's been merged, so will be in next build automatically.

Cool, I can't wait to see if it fixes the similar issue in PVR WMC. I'm off to look at the patch now. I'm excited because I'm about to start my learning curve on how all the pieces of this puzzle fit together. I know it's not the ideal way to get started, but any port in a storm is OK with me. I don't suppose there's a maintenance manual on the whole package is there? Wink Seriously though, is there a wiki for wannabe developers?
Experience: It's what you get when you were expecting something else.
New OpenELEC Isengard build #0315: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.19.1 #1 Sun Mar 15 21:03:32 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Mar 15 2015 19:51:38
Copyright (c) 2012 Broadcom
version fef371701296941551f3b8375d5680a427c04f48 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150315210242-#0315-g4a8006a [Build #0315]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (4a8006aa, changelog) and tip of XBMC master (505d6812, changelog) with the following modifications: Build Highlights:
  1. New firmware, with full frame 3D support:
    popcornmix Wrote:This update adds Full HD HDMI output (frame-packing). It is enabled by default but can be disabled in video acceleration settings.
    When enabled, 3D modes will use full 1080p resolution (rather than half-SBS or half-TAB).
    This is particularly useful for MVC content where you will get the full 1080p resolution for both eyes.

    This is a first for Kodi. No other platform supports full resolution playback of 3D BluRay MVC files using Kodi's internal player.

    Currently the gui will be rendered as half-SBS or half-TAB (and expanded), but the video will be full resolution. You can confirm the 3D mode with
    "tvservice -s" which will report "3D FP" when in full resolution mode.
  2. Fix opening PVR grouped recordings/folders (@zaphod24)
  3. Fix for PVR ArgusTV crashing (@evanspae)
Build Details:
  1. Firmware (Mar 15):
    • firmware: dispmanx: Add stereoscopic flags to transform
    • firmware: Fix MMAL annotate V3 handling. See: link
    • firmware: arm_loader: Populate DT with HAT vendor info
    • firmware: arm_loader: Support boolean parameters and '.dtbo' extensions. See: link
  2. OpenELEC:
    • font-util: update to font-util-1.3.1 (e09c0e3d)
    • randrproto: update to randrproto-1.4.1 (c96f3b6f)
    • packages/linux: Update Linux kernel for WeTek Play to 3.10-16a1118 (b200637f)
    • README.md: cosmetics (8de77837)
    • wetek_play: linux: fix patch order (e18fcbe3)
    • libcec: rename imx6 patch (4a8006aa)
  3. XBMC:
    • dvdplayer: add slice threading back for most codecs - currently too many... (PR:6724, 1 commit, 2 files changed)
    • renderer: drop frames if there is no consumer (PR:6719, 2 commits, 2 files changed)
    • FIX: [droid] if a full apk is present, use it rather than obb; lower threshold to 40Mb (PR:6727, 1 commit, 1 file changed)
    • Allows choosing compiler during build of libsquish (PR:6715, 1 commit, 1 file changed)
    • [pvr] fix group member assignment (PR:6728, 1 commit, 1 file changed)
    • [cleanup] Remove check for language (codes) from language addons. (PR:6713, 2 commits, 4 files changed)
    • remove old pre-Frodo upgrade code for cached artwork (PR:6627, 1 commit, 11 files changed)
    • [pvr] fix PVR client to addon migration in PVRDatabase (PR:6706, 3 commits, 1 file changed)
    • [pvr] fix unable to open grouped recordings/folders (closes #15848) (PR:6729, 1 commit, 1 file changed)
  4. pvr.argustv:
    • Crash fix for non-Windows systems (PR:3, 2 commits, 13 files changed)
  5. pvr.dvblink:
    • [debian] adds missing dependency libtinyxml2-dev (PR:6, 1 commit, 1 file changed)
  6. pvr.mythtv:
    • version 2.0.9 (PR:3, 4 commits, 15 files changed)
  7. pvr.pctv:
    • [debian] adds missing dependency libjsoncpp-dev (PR:5, 1 commit, 1 file changed)
  8. newclock4:
    • New commits in this build:
      • [mmalrenderer] Switch to using transform flags for 3d modes (2aac616f)
    • Commits no longer in build:
      • squash me (15f8cd70)
      • renderer: cosmetics (5dce0b8d)
      • renderer: drop video frames if neither full-screen nor video control displays them (826fe9f0)
      • test: Add advancedsetting to force 3d mode (5bcf886c)
  9. 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.
Thanks! Looks like PR:6729 does indeed fix the issues with recordings in the MythTV plugin.
(2015-03-16, 01:42)Milhouse Wrote: [*]New firmware, with full frame 3D support:
popcornmix Wrote:This update adds Full HD HDMI output (frame-packing). It is enabled by default but can be disabled in video acceleration settings.
When enabled, 3D modes will use full 1080p resolution (rather than half-SBS or half-TAB).
This is particularly useful for MVC content where you will get the full 1080p resolution for both eyes.

This is a first for Kodi. No other platform supports full resolution playback of 3D BluRay MVC files using Kodi's internal player.

Currently the gui will be rendered as half-SBS or half-TAB (and expanded), but the video will be full resolution. You can confirm the 3D mode with
"tvservice -s" which will report "3D FP" when in full resolution mode.

I am excited by this, but also a little confused.

Is this just about frame packed output, or does it also signal MVC decoding as well (as they are different things of course).

I wasn't aware of any open source MVC decoding library, so perhaps this is just for FullSBS (3840x1080) or FullTAB (1920x2160)?
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
@nickr - it does playback MVC encoded streams using it's HW decoder which is capable of decoding MVC. It's NO software decoding and not opensource (as it's the HW)
(2015-03-16, 10:53)da-anda Wrote: @nickr - it does playback MVC encoded streams using it's HW decoder which is capable of decoding MVC. It's NO software decoding and not opensource (as it's the HW)

Well that is a great breakthrough for kodi. Woot.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
I'm excited, cause Nickr's excited !

Now don't go eating to many fish from all this excitement ya Fat Little Penguin Wink

Yes it is good new indeed !

Support for 3D is an excellent development. Can Pi 1 or 2 pass HD audio? I searched & found this thread, which seems to suggest no for Pi 1, but maybe possible for Pi 2?
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
My Family Room Theater
(2015-03-16, 13:53)hdmkv Wrote: Support for 3D is an excellent development. Can Pi 1 or 2 pass HD audio? I searched & found this thread, which seems to suggest no for Pi 1, but maybe possible for Pi 2?

Sorry, no HD audio passthrough. (5.1 DTS/AC3 and E-AC3 passthrough are supported).
You can get 8 channel PCM output, so TrueHD can be played losslessly (by decoding on the Pi), although you really need a Pi 2 for that.
Currently there is no support from ffmpeg for DTS-HD decode, so you can only get the 5.1 channel core.

When testing last night I played the first half of Gravity (raw BluRay rip, with MVC/framepacked output) on the Pi2.
I then switched to the older Pi1 and watched the second half, and it was also flawless. Pi1 has a standard overclock (arm_freq=100, core_freq=500, over_voltage=6).

So, if you have a Pi1 with overclock and a decent network setup (e.g. wired/nfs) then MVC/framepacked is possible.
(2015-03-16, 14:01)popcornmix Wrote:
(2015-03-16, 13:53)hdmkv Wrote: Support for 3D is an excellent development. Can Pi 1 or 2 pass HD audio? I searched & found this thread, which seems to suggest no for Pi 1, but maybe possible for Pi 2?

Sorry, no HD audio passthrough. (5.1 DTS/AC3 and E-AC3 passthrough are supported).
You can get 8 channel PCM output, so TrueHD can be played losslessly (by decoding on the Pi), although you really need a Pi 2 for that.
Currently there is no support from ffmpeg for DTS-HD decode, so you can only get the 5.1 channel core.

When testing last night I played the first half of Gravity (raw BluRay rip, with MVC/framepacked output) on the Pi2.
I then switched to the older Pi1 and watched the second half, and it was also flawless. Pi1 has a standard overclock (arm_freq=100, core_freq=500, over_voltage=6).

So, if you have a Pi1 with overclock and a decent network setup (e.g. wired/nfs) then MVC/framepacked is possible.
Do I need a special setting to decode TrueHD to PCM?
(2015-03-16, 14:23)lolli_lutscher Wrote: Do I need a special setting to decode TrueHD to PCM?

No. If you play a TrueHD track it will be decoded and downmixed to "number of channels" (from system/audio settings).
If you set "number of channels" to 8 then all 8 channels will be output as PCM.
If the file has multiple tracks you may need to switch (in OSD audio settings) to the TrueHD track.

TrueHD is quite expensive to decode, so is not recommended on Pi1. Pi2 has no trouble with it.
  •   
  • 1
  • 72
  • 73
  • 74(current)
  • 75
  • 76
  • 111
  •   



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 112
This forum uses Lukasz Tkacz MyBB addons.