•   
  • 1
  • 89
  • 90
  • 91(current)
  • 92
  • 93
  • 111
  •   
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1
Sorry if this is in the wrong place. But I'm having trouble playing ripped 3d bluray on my pi 2 running openelec 5.06. I ripped the bluray disc using makemkv and additionally selected the mvc track. When I try to playback the file I can't watch it in 3d, it plays in 2d fine, but the 3d option is like zoomed in and out of focus. I have the file named film.3d.sbs
Any help much appreciated. Thank you.
(2015-03-26, 22:41)hdmkv Wrote: I'm thinking of pushing it and trying what wrxtasy suggested; wonder if it's safe to...
Code:
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

Feel free to try. You won't cause any permanent damage you will just get crashing when you go too far.
An unfortunate crash could corrupt the sdcard so backing up is advisable before experimenting.

On Pi 2, over_voltage only goes up to 4 (it starts with a higher voltage than Pi 1).
Asking for 6 is fine but it will behave the same as 4.
(2015-03-26, 23:30)tammymiller Wrote: Sorry if this is in the wrong place. But I'm having trouble playing ripped 3d bluray on my pi 2 running openelec 5.06. I ripped the bluray disc using makemkv and additionally selected the mvc track. When I try to playback the file I can't watch it in 3d, it plays in 2d fine, but the 3d option is like zoomed in and out of focus. I have the file named film.3d.sbs
Any help much appreciated. Thank you.
You need one of the test builds from this thread.
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.)
Thanks nickr, I'll give that a try tomorrow.
(2015-03-26, 23:00)Trixster Wrote: Are you using a pi2? I find running the ram at a slightly lower 483 much more stable even with arm at 1100 and core at 500. With sdram at 500 I get occasional lockups even with core and arm dropped significantly and over volt at 6. For me, arm 1100, core 500, sdram 483 and over volt 2 is completely stable.
Yep, Pi2.
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
My Family Room Theater
(2015-03-26, 23:00)Trixster Wrote: Are you using a pi2? I find running the ram at a slightly lower 483 much more stable even with arm at 1100 and core at 500. With sdram at 500 I get occasional lockups even with core and arm dropped significantly and over volt at 6. For me, arm 1100, core 500, sdram 483 and over volt 2 is completely stable.

Thanks for the tip.
Indeed my pi2 was having issues with sdram 500.
Seems stable @480.

My b+ was stable even with sdram 800 and arm 1200, but that was on nfsroot.
With sdcards (I tried a few from different vendors) there was no way I could achieve stability with such aggressive overclocks.
But that's offtopic and another story.
New OpenELEC Isengard build #0326: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.19.2 #1 Fri Mar 27 01:10:02 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Mar 25 2015 19:09:30
Copyright (c) 2012 Broadcom
version f014c026d788d7aca1eba59371a4f7fb31136d79 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150327010910-#0326-gb87a7ed [Build #0326]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (b87a7ede, changelog) and tip of XBMC master (d79526ae, changelog) with the following modifications: Build Highlights:
  1. dcadec updates
Build Details:
  1. OpenELEC:
    • xorg-server: remove upstream patch (PR:4044, 1 commit, 1 file changed)
    • Intel: Fix EDID overriding (makes audio work) (PR:4042, 1 commit, 1 file changed)
  2. XBMC:
    • [tagloader] make TagLoaderFactory load by item (fixes #15879) (PR:6811, 1 commit, 8 files changed)
    • [confluence] Move dialog background to include (PR:6807, 1 commit, 27 files changed)
    • [confluence] add pcm, pcm_s16le and pcm_s24le audio flags (PR:6823, 1 commit, 3 files changed)
    • [jenkins/tests] - add unit test support for win32 on jenkins (PR:6815, 2 commits, 1 file changed)
    • fix htmltow test case (PR:6817, 1 commit, 10 files changed)
  3. dcadec:
    • Pre-scale floating point FIR coefficients. (79cfae43)
    • Move floating point IDCT coeffs into per-context data. (5a9239fe)
    • Make dcadec.pc a separate rule (cd8c0082)
    • Add mechanism for updating version in pkg-config file (e94bfe26)
    • Fix specifying compilers and flags (4bb67196)
  4. pvr.dvbviewer:
    • Update to 1.10.31 (PR:3, 5 commits, 11 files changed)
  5. newclock4:
    • New commits in this build:
      • squash: [omxplayer] Handle failures from FillThisBuffer (d9baf535)
  6. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: patch: Add dcadec package for DTS HD-MA support
    • Added: PR:6772: [musicdb] enable the library via xml
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-03-26, 10:51)da-anda Wrote:
(2015-03-25, 13:49)popcornmix Wrote:
(2015-03-25, 10:06)da-anda Wrote: with #0323 I have serious issues when mmal renderer is used. As soon as there is any UI overlay playback is choppy with lots of drops. This doesn't happen with omxplayer.

Is #0323 the first build with this issue? Is #0322 okay?
I had skipped a few nightlies, will try to find the build that broke it.
@popcornmix - I noticed that this only happens with mmal and Eminence skin. When I used mmal with Confluence I don't get any frame skips. CPU usage on all cores is ~25% when showing an overlay in Eminence. Any idea why a skin could cause frame skips when CPU is not even maxed out? As mentioned, using Eminence with omxplayer is working just fine. I know that mmal has some dvdplayer overhead and thus requires more resources, but I haven't noticed issues with mmal and Eminence before. I first try to find out if some change in Eminence is responsible for it because it feels a lot more choppy lately (no smooth animations/transitions).
I know it is a little off topic, but is it possible to get latest Tvheadend for rpi2 openelec. The one i am testing is 3.9.2496 but I am seeing a bug when switching channels that you have to press twice to the channel to switch.
Since 0324 there are issues skipping backwards, especially when using dvdplayer instead of omxplayer. I haven't seen an update yet that resolves what looks like was identified as a firmware issue.

In addition, I've had several cases where liveTV playback just freezes and I have to stop it (takes a bit) and then start it back. That has occurred with omxplayer enabled and disabled. When omxplayer is used, there are also occasional crashes like the one in this crash log http://sprunge.us/RFeC

Based on advice in other posts, I enabled the option "sync playback to display" and now the framerate for my HD 1080i60 channels changes to 59.94 and the SD channels change to 29.97 where both previously showed 25.
(2015-03-27, 14:44)zaphod24 Wrote: Since 0324 there are issues skipping backwards, especially when using dvdplayer instead of omxplayer. I haven't seen an update yet that resolves what looks like was identified as a firmware issue.

I've got a firmware fix for the hanging when skipping/trickplay and a fix for stuttery VC-1, shoud make tonight's build.

Quote:In addition, I've had several cases where liveTV playback just freezes and I have to stop it (takes a bit) and then start it back. That has occurred with omxplayer enabled and disabled. When omxplayer is used, there are also occasional crashes like the one in this crash log http://sprunge.us/RFeC

Can you post this log again but with debug enabled in settings? This message is solvable:
Code:
06:31:47 122147.867188 T:1563423808   ERROR: COMXAudioCodecOMX::GetData Unexpected change of size (12288->36864)

but I need to know the audio codec. Enable FFMPEG in component specific logging too.
I'll turn on debugging and specific debugging for FFMPEG and see if I can reproduce the issue. It seems to occur randomly and is ok for hours. In the meantime, I still have the liveTV file from this morning and mplayer shows this for audio/video:

VIDEO MPEG2(pid=3790) AUDIO A52(pid=3791) NO SUBS (yet)! PROGRAM N. 1
VIDEO: MPEG2 1920x1080 (aspect 3) 29.970 fps 25000.0 kbps (3125.0 kbyte/s)

Thanks for the continued hard work and progress on RPi!
(2015-03-26, 21:00)hdmkv Wrote: [*]My Pi2 crashes every so often when testing files. Must unplug, replug. An example is the Dolby ATMOS 'Amaze' clip (download here). It plays fine and sounds amazing (even with just my 7.1 system) Smile, but when I press stop before it's over, my RPi2 blanks out (no picture). Must unplug, replug.

I'm not seeing a problem here. I've tried with/without omxplayer and with/without passthrough. Can stop the file early in all cases.

Now, I do have the upcoming firmware which fixes the omxplayer seek/trickplay issue which could be relevant. Can you try again with tonight's build?
Will do. I noticed the crash go away, at least with about 15-20 minutes of testing, when using the overclock settings you suggested.
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
My Family Room Theater
Looking forward to tonight's build. I have been having problems with forward seeks in the TV / Recordings section since around Build 313. Funny enough it works fine in the Video section.
Wasn't sure if it was a pvr issue or Kodi issue.

As always, thanks for the great work.
  •   
  • 1
  • 89
  • 90
  • 91(current)
  • 92
  • 93
  • 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.