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



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - delinend - 2014-01-30

Yes. It's an old problem/bug. I have also tryed an old Rbej build from 2/10-2013, that behave in the same way.

The only reason I discoveret this, whas that I tryed my Pi, on an Old Samsung TV, that have som 25Hz problems from a Pi. But that's another thing..

I have tryed to insert the override refreshrate in my advancedsettings.xml, and that works for me. Also on my other TV's the playback of PAL25 to 50Hz, is more flawles :-)


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - da-anda - 2014-01-30

I just did a quick test with latest Millhouse build and set DVDplayer as default. Didn't investigate why exactly (CEC sucks on my TV, not many keys are forwarded) but I also had choppy playback and sometimes random green frames. This happened for videos from chefkoch.de Addon using DVDplayer. Using OMXPlayer there was no stutter or anything. Test was done on a 256MB model.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - janaha - 2014-01-30

(2014-01-20, 19:39)janaha Wrote: 2.
Most of my 1080 movies and tv shows with DTS lags with passthrough enabled, but plays fine when disabled.

3.
Local subs have a hard time enabling.Must toggle multiple times and adjust sync to get it enabled.
Downloaded subs work fine.

Looks like DVDPlayer is the cure for me here.
All the previous files I've played with DTS passthrough lag, is now lag free!

However, I still have a hard time enabling local subs (toggle enable passthrough works)

Latest Milhouse build


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - xbs08 - 2014-01-30

DVDPlayer codec info Windowing reports the same fps as the movie played while OMX reports the much lower UI fps.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - evanspae - 2014-01-30

Quote:MilhouseVH I think you have it here Going as far back as mid December, all of my Gotham builds have this same 25Hz in, 25Hz out behaviour (or 29.970/30Hz in, 30Hz out). 24Hz in is output at 24Hz. So this is not a recent problem.

I then created a build without any newclock3 patches (but still using the latest Jan 28 firmware), and now 25Hz material is being output at 50Hz (and 30Hz material at 60Hz), so it's definitely a newclock3 patch that is causing this difference in video refresh rate behaviour.

I proceeded to build Gotham with just the following newlock3 patch, and the 25Hz in, 25Hz out and 30Hz in, 30Hz out behaviour returned:
Code:
popcornmix/xbmc/commit/a674b64876f81813036485de22fe15de95d5ed58 [3D] Support switching to 3D resolutions

so that would appear to be the culprit.

Personally I'm not even sure this new behaviour should be classed as "wrong", it seems more logical to me but if it causes juddering on some setups (and doubling the frame rate doesn't) then I guess using the higher frame rate is the way to go...

Here's a debug log, without the 3D switching patch, when playing 24Hz, 25Hz and 29.970Hz material (output at 24Hz, 50Hz and 60Hz respectively).
Here's a debug log, WITH the 3D switching patch, playing the same 24Hz, 25Hz and 29.970Hz material (output at 24Hz, 25Hz and 30Hz respectively).

Regardless of peoples opinion should the acid test be simple:- record a live broadcast source, play it back and it should have the same frame rate/video refresh rate as the original anything else is a fudge. This may be necessary to conserve RPI resources, but you have now passed the problem, back to the display device as to whether or not it can handle it. It should also be borne in mind that 3D functionality although desirable is probably not required by the vast majority of users.Huh


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-01-30

New OpenELEC Gotham build: #0130b
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.13.0 #1 PREEMPT Thu Jan 30 03:12:31 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Jan 28 2014 18:56:53
Copyright (c) 2012 Broadcom
version 8966c433ecd9358a1cdab717d2a1b89999464b10 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140130171121-r17182-g6d01e5f

Based on tip of XBMC master (86b108c, changelog) and tip of OpenELEC master (6d01e5f, changelog) with the following modifications:
  • Includes newclock3 commits (except for f096daf which I've replaced with a static spinner)
  • Excludes the OpenELEC fernetmenta patches (due to conflict with newclock3)
Build Higlights:
  1. The 3D Switching patch has been updated, removing the change to pick the smallest multiple of framerate rather than largest, so now 25Hz/50Hz etc. behaviour is restored, albeit at the cost of slightly increased load. Many thanks Popcornmix.

Additional Testing Notes:
  1. Testers should try adding the following entry to their advancedsettings.xml:
    Code:
    <advancedsettings>
      <video>
        <defaultplayer>dvdplayer</defaultplayer>
        <defaultdvdplayer>dvdplayer</defaultdvdplayer>
      </video>
    </advancedsettings>
    and report if it is better/worse than omxplayer. You can still play files with omxplayer using the context-menu "Play using... OMXPlayer".

  2. The following settings are no longer required in config.txt and should be removed:
    Code:
    no_hdmi_resample=1
    hdmi_stream_channels=1
    no_resample_audio is now a default, and hdmi_stream_channels is switched based on audio content. For the time being when using passthrough, 2.0 speaker layout should continue to be used (you will still get 5.1 with AC3/DTS).



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - SSC_Jarod - 2014-01-30

Hi Millhouse,

Sorry to be prophet of 3D-Doom in autoswitching. Wink But with this build its gone, sadly.
It works with r17171.

Greetz,
J


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-01-30

(2014-01-30, 21:34)SSC_Jarod Wrote: Sorry to be prophet of 3D-Doom in autoswitching. Wink But with this build its gone, sadly.
It works with r17171.

Unfortunately I can't explain that, nor can I test it as I have no 3D hardware. The only change in this latest build is to not favour lower refresh frequencies:
Code:
$ diff old3dswitching.patch new3dswitching.patch
1c1
< From a674b64876f81813036485de22fe15de95d5ed58 Mon Sep 17 00:00:00 2001
---
> From 4cb5006af21147d9237e1d2629423c039c461a4c Mon Sep 17 00:00:00 2001
12,13c12,13
<  xbmc/cores/VideoRenderers/BaseRenderer.cpp | 51 +++++++++++-------------------
<  1 file changed, 19 insertions(+), 32 deletions(-)
---
>  xbmc/cores/VideoRenderers/BaseRenderer.cpp | 48 +++++++++++-------------------
>  1 file changed, 17 insertions(+), 31 deletions(-)
16c16
< index 970b822..1f7843d 100644
---
> index 970b822..d1279d9 100644
31c31
< @@ -237,49 +240,33 @@ RESOLUTION CBaseRenderer::FindClosestResolution(float fps, float multiplier, RES
---
> @@ -237,44 +240,27 @@ RESOLUTION CBaseRenderer::FindClosestResolution(float fps, float multiplier, RES
89,103d88
<
<  //distance of refresh to the closest multiple of fps (multiple is 1 or higher), as a multiplier of fps
< +//make higher multiples score slightly worse
<  float CBaseRenderer::RefreshWeight(float refresh, float fps)
<  {
<    float div   = refresh / fps;
< @@ -288,7 +275,7 @@ float CBaseRenderer::RefreshWeight(float refresh, float fps)
<    if (round < 1)
<      return (fps - refresh) / fps;
<    else
< -    return (float)fabs(div / round - 1.0);
< +    return (float)fabs(div / round - 1.0) + round*1e-3f;
<  }
<
<  RESOLUTION CBaseRenderer::GetResolution() const

The new patch simply doesn't include the change to "make higher multiples score slightly worse". Why that should affect 3D autoswitching I've no idea, unless your 3D TV modes are only available at lower frequencies - frequencies that are no longer being selected because higher frequencies are now favoured?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Dimitriss - 2014-01-30

Just installed the latest build and although i'm getting the correct 50hz on 25p content there are still green frames in the video. Everything else looks fine.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - craigbeat - 2014-01-30

Thanks for the hard work. I can confirm that the 'correct' refresh rate is now working.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2014-01-30

Good job, i have a lot of 1080i 50hz Dreambox .ts files, now it running correct with 1080p 50hz!

A old problem is the .ts files starting slow!

I use the standardplayer!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - cognitive alien - 2014-01-31

I'm new to this but looks like something weird with lircd hogging loads of cpu
Load average: 5.35 5.02 3.36 3/96 403
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
271 1 root R 538m144.4 0 72.2 /usr/lib/xbmc/xbmc.bin --standalone -fs --lircdev /var/run/lirc/lircd

This is the latest build above.....

PS should add using cec on the tv remote, dunno if that causing issues....


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - sunwarming - 2014-01-31

Hi guys,
I have been using openelec on my model B Raspberry PI, for about 8 months but always with the stable versions. I now installed the latest MilhouseVH version of gotham. Great stuf!!

I Just have 2 problems, first is sometimes when i switch on my PI there is a loud buzzing sound coming from the TV, but when i play a video or audio file, the buzzing stops and the sounds goes back to normal. i have the PI linked by HDMI. Anyone know why this happens?

The other issue is when a menu or something in loading in openelec in the bottom right corner comes up "Processing" or "working" and a white wheel comes up next to it, but the wheel isn't moving like in xbmc 12. It is static and looks like the PI has frozen, but it hasn't in reality.

If anyone could help me with these issues i would be very gratefull!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tuxen - 2014-01-31

(2014-01-30, 07:40)delinend Wrote:
(2014-01-30, 01:21)MilhouseVH Wrote: I guess the thing to do would be to check what a non-Pi build of Gotham does with the same material and display.

Hi Milhouse.

I have just installed Gotham Nightly build for Windows (XBMCSetup-20140128-56c2654-master.exe ) on my Laptop, with HDMI to my screen in 1920x1080p60. To test 25p/50p on that version.

My only setting in XBMC: Video->Playback->Adjust display refresh rate to match video = Always
No change in advancedsettings.xml !!!

When playing 24p movies, the display switch to 1920x1080p24
When playing PAL25p movies, the display switch to 1920x1080p50 !!

The Windows Gotham build, do the same as Frodo, switching 25p to 50p. And that look's good.

It look's like the problem is only on Pi-build :-(

Best regards

Just a thought; are you sure your laptop can output 25p? Not many gfx cards can.
My PC for example can not output 25p or 30p only 24p.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - nola mike - 2014-01-31

Kind of a dumb question, but I'm trying to use stable releases the easy way--saw that I can just dump the tar file in the .update folder, but I can't seem to find it?