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



RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-02-22

(2013-02-22, 12:27)MilhouseVH Wrote: So for me, it looks like the seek_before_zero patch is the culprit. The patch is applying cleanly, with no obvious build issues:

Okay, that's useful to know. I did leave a 2 minute SD video looping overnight and that does have a grey screen now.
Took 25 runs before it failed, so not easy for me to reproduce, but possible.
From the debugger I can see we seem to have come out of buffering (incorrectly) with video queue empty.

May be quicker for me to give you a potential fix if I find something suspicious.

Actually can you try commenting out (in OMXPlayer.cpp):
Code:
// handle situation that we get no data on one stream
    if(m_CurrentAudio.id >= 0 && m_CurrentVideo.id >= 0)
    {
      if ((!m_player_audio.AcceptsData() && !m_CurrentVideo.started)
      ||  (!m_player_video.AcceptsData() && !m_CurrentAudio.started))
      {
        caching = CACHESTATE_DONE;
      }
    }
I've a suspicion that is incorrectly taking us out of buffering.


RE: OpenELEC Testbuilds for RaspberryPi - nuttypro69 - 2013-02-22

Hey guys can we get a fix build with out the seek-before-zero patch or do we have to wait for a fix to have all 5 patches .Thanks you guys are great .


RE: OpenELEC Testbuilds for RaspberryPi - Jeilong - 2013-02-22

Does OE 2.99.3 (3.0 RC3) or any recent test build fix the black screen issue when watching LiveTV from a Tvheadend server? Both SD and HD viewing fails in all builds I tried the last few months. I have the MPEG2 license and my Tvheadend works fine with OE on my ION-based HTPC, but has been broken for months on the Raspberry Pi.


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-02-22

(2013-02-22, 13:57)popcornmix Wrote: May be quicker for me to give you a potential fix if I find something suspicious.

Sure - patches (diffs) would be best (if possible)! Smile

(2013-02-22, 13:57)popcornmix Wrote: Actually can you try commenting out (in OMXPlayer.cpp):
Code:
// handle situation that we get no data on one stream
    if(m_CurrentAudio.id >= 0 && m_CurrentVideo.id >= 0)
    {
      if ((!m_player_audio.AcceptsData() && !m_CurrentVideo.started)
      ||  (!m_player_video.AcceptsData() && !m_CurrentAudio.started))
      {
        caching = CACHESTATE_DONE;
      }
    }
I've a suspicion that is incorrectly taking us out of buffering.

OK, I created a patch so that line 1538 in OMXPlayer.cpp became:
Code:
// handle situation that we get no data on one stream
/*
    if(m_CurrentAudio.id >= 0 && m_CurrentVideo.id >= 0)
    {
      if ((!m_player_audio.AcceptsData() && !m_CurrentVideo.started)
      ||  (!m_player_video.AcceptsData() && !m_CurrentAudio.started))
      {
        caching = CACHESTATE_DONE;
      }
    }
*/

However this had little, if any effect - a few movies played (might have been luck), but most of my tv shows were of the grey background/no playback variety - one episode did play, but after I rebooted and tried it again, it refused to play.

(2013-02-22, 14:00)nuttypro69 Wrote: Hey guys can we get a fix build with out the seek-before-zero patch or do we have to wait for a fix to have all 5 patches .Thanks you guys are great .

I won't be publishing any builds - I don't have the webspace (or an account somewhere that does). Hopefully normal service will be resumed in a day or so.


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-02-22

@rbej/MilhouseVH

https://github.com/xbmc/xbmc/pull/2249
is worth testing. It makes SSA/ASS subs and video overlay updates smoother. (include all the commits in the patch, even though are not Pi specific)

Might be worth testing a build with this in (also include this https://github.com/xbmc/xbmc/pull/2273 which is well worthwhile).

Leave out the "seek-before-zero" and "new stall" patches until we get a solution.


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-02-22

The 2249 patch (this) doesn't apply cleanly, it fails on DVDPlayerVideo.cpp... what's your suggestion?

Code:
patching file xbmc/cores/dvdplayer/DVDPlayerVideo.cpp
Hunk #4 FAILED at 472.
Hunk #5 succeeded at 506 (offset -13 lines).
Hunk #6 succeeded at 537 (offset -13 lines).
Hunk #7 succeeded at 585 (offset -13 lines).
Hunk #8 succeeded at 1278 (offset -13 lines).
Hunk #9 succeeded at 1662 (offset -13 lines).
1 out of 9 hunks FAILED -- saving rejects to file xbmc/cores/dvdplayer/DVDPlayerVideo.cpp.rej

This is the content of DVDPlayerVideo.cpp.rej:

Code:
--- xbmc/cores/dvdplayer/DVDPlayerVideo.cpp
+++ xbmc/cores/dvdplayer/DVDPlayerVideo.cpp
@@ -472,8 +476,11 @@
       m_speed = static_cast<CDVDMsgInt*>(pMsg)->m_value;
       if(m_speed == DVD_PLAYSPEED_PAUSE)
         m_iNrOfPicturesNotToSkip = 0;
+
       if (m_pVideoCodec)
         m_pVideoCodec->SetSpeed(m_speed);
+
+      m_droppingStats.Reset();
     }
     else if (pMsg->IsType(CDVDMsg::PLAYER_STARTED))
     {



RE: OpenELEC Testbuilds for RaspberryPi - hpbaxxter - 2013-02-22

(2013-02-22, 16:03)popcornmix Wrote: Leave out the "seek-before-zero" and "new stall" patches until we get a solution.

I think the "new stall" patch didn't cause problems except the minor one I described here:
http://forum.xbmc.org/showthread.php?tid=140518&pid=1343957#pid1343957

Maybe MilhouseVH could check/confirm if movies start playing with the "new stall" patch?


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2013-02-22

(2013-02-22, 16:38)MilhouseVH Wrote: The 2249 patch (this) doesn't apply cleanly, it fails on DVDPlayerVideo.cpp... what's your suggestion?

Well DVDPlayer.cpp is not used on Pi, so anything that compiles will do.

Possibly patching this first will fix it:
https://github.com/xbmc/xbmc/commit/a558c00406ef884095bba33d0eb41509177abecb


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-02-22

(2013-02-22, 16:42)hpbaxxter Wrote:
(2013-02-22, 16:03)popcornmix Wrote: Leave out the "seek-before-zero" and "new stall" patches until we get a solution.

I think the "new stall" patch didn't cause problems except the minor one I described here:
http://forum.xbmc.org/showthread.php?tid=140518&pid=1343957#pid1343957

Maybe MilhouseVH could check/confirm if movies start playing with the "new stall" patch?

I can't say I've ever noticed the problem myself, so perhaps unlikely. Though I really just wanted to help get to the bottom of the non-playing media rather than begin testing other features (I should probably mention, I have no SSA/ASS subs here). As that's a bit of a show-stopper I'm not sure if throwing more patches into the mix is necessarily helpful.

(2013-02-22, 16:47)popcornmix Wrote:
(2013-02-22, 16:38)MilhouseVH Wrote: The 2249 patch (this) doesn't apply cleanly, it fails on DVDPlayerVideo.cpp... what's your suggestion?

Well DVDPlayer.cpp is not used on Pi, so anything that compiles will do.

Possibly patching this first will fix it:
https://github.com/xbmc/xbmc/commit/a558c00406ef884095bba33d0eb41509177abecb

OK, thats fixed the 2249 patch, but now the resolution_changes.patch has failed on OMXPlayerVideo.cpp - do we need this patch?

Code:
APPLY PATCH (project):   /home/neil/myOpenELEC/OpenELEC.tv/projects/RPi/patches/xbmc/resolution_changes.patch
patching file xbmc/cores/omxplayer/OMXPlayerVideo.cpp
Hunk #2 succeeded at 103 with fuzz 1 (offset 8 lines).
Hunk #3 succeeded at 235 (offset 10 lines).
Hunk #4 succeeded at 254 (offset 10 lines).
Hunk #5 FAILED at 303.
Hunk #6 succeeded at 719 (offset 3 lines).
Hunk #7 succeeded at 855 (offset 3 lines).
1 out of 7 hunks FAILED -- saving rejects to file xbmc/cores/omxplayer/OMXPlayerVideo.cpp.rej

OMXPlayerVideo.cpp.rej:

Code:
--- xbmc/cores/omxplayer/OMXPlayerVideo.cpp
+++ xbmc/cores/omxplayer/OMXPlayerVideo.cpp
@@ -303,63 +295,6 @@

void OMXPlayerVideo::Output(int iGroupId, double pts, bool bDropPacket)
{
-
-  if (!g_renderManager.IsConfigured()
-    || m_video_width != m_width
-    || m_video_height != m_height
-    || m_fps != m_fFrameRate)
-  {
-    m_width   = m_video_width;
-    m_height  = m_video_height;
-    m_fps     = m_fFrameRate;
-
-    unsigned flags = 0;
-    ERenderFormat format = RENDER_FMT_BYPASS;
-
-    if(m_bAllowFullscreen)
-    {
-      flags |= CONF_FLAGS_FULLSCREEN;
-      m_bAllowFullscreen = false; // only allow on first configure
-    }
-
-    if(m_flags & CONF_FLAGS_FORMAT_SBS)
-    {
-      if(g_Windowing.Support3D(m_video_width, m_video_height, D3DPRESENTFLAG_MODE3DSBS))
-      {
-        CLog::Log(LOGNOTICE, "3DSBS movie found");
-        flags |= CONF_FLAGS_FORMAT_SBS;
-      }
-    }
-    else if(m_flags & CONF_FLAGS_FORMAT_TB)
-    {
-      if(g_Windowing.Support3D(m_video_width, m_video_height, D3DPRESENTFLAG_MODE3DTB))
-      {
-        CLog::Log(LOGNOTICE, "3DTB movie found");
-        flags |= CONF_FLAGS_FORMAT_TB;
-      }
-    }
-
-    unsigned int iDisplayWidth  = m_hints.width;
-    unsigned int iDisplayHeight = m_hints.height;
-
-    /* use forced aspect if any */
-    if( m_fForcedAspectRatio != 0.0f )
-      iDisplayWidth = (int) (iDisplayHeight * m_fForcedAspectRatio);
-
-    CLog::Log(LOGDEBUG,"%s - change configuration. %dx%d. framerate: %4.2f. %dx%x format: BYPASS",
-        __FUNCTION__, m_width, m_height, m_fps, iDisplayWidth, iDisplayHeight);
-
-    if(!g_renderManager.Configure(m_hints.width, m_hints.height,
-          iDisplayWidth, iDisplayHeight, m_fps, flags, format, 0,
-          m_hints.orientation))
-    {
-      CLog::Log(LOGERROR, "%s - failed to configure renderer", __FUNCTION__);
-      return;
-    }
-
-    g_renderManager.RegisterRenderUpdateCallBack((const void*)this, RenderUpdateCallBack);
-  }
-
   if (!g_renderManager.IsStarted()) {
     CLog::Log(LOGERROR, "%s - renderer not started", __FUNCTION__);
     return;



RE: OpenELEC Testbuilds for RaspberryPi - hpbaxxter - 2013-02-22

(2013-02-21, 14:08)rbej Wrote: For me (Rpi 256mb) the best working version with this patch:

[rbp] Fix for stuttery video when seeking before zero
[rbp] [wip] new scheme for handling stalling and buffering
[rbp] Handle resolution changes during video stream.

and without this patch:

[rbp]Check free memory, and if plenty use full size buffers for reading files
"new Network Cache" (alwaysforcebuffer)

http://www.mediafire.com/?dx2947u48a654ku

As MilhouseVH could identify the patch "[rbp] Fix for stuttery video when seeking before zero" causing the movies not playing issue, the others should be ok.

Edit: Milhouse already tested it, see http://forum.xbmc.org/showthread.php?tid=140518&pid=1344744#pid1344744


RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2013-02-22

I get time to compile 3 test build

without seek and big buffer

without seek

without seek and new scheme buffering

All 3 build include https://github.com/xbmc/xbmc/pull/2273 (fix ass subs for GLES)

PLEASE TEST

http://www.mediafire.com/?el1zhe01fq22z

Which is the best working for you??


RE: OpenELEC Testbuilds for RaspberryPi - hpbaxxter - 2013-02-23

With the "without seek" build, sometimes directly after booting, the first attempt to play a movie fails with black screen, counter at zero. When paused, the time passed is indicated correctly, when playing, 0:00:00 is indicated. A second and further tries always play the video correctly. I have a 256 MB RPi and it's the same with gpu_mem=100 and gpu_mem=128.

No problems with build "without seek and big buffer" so far, same with "without seek and new scheme buffering". All builds are playing Die Hard remux (1080p, dts, ntfs hdd via usb) fine at stock rates which is a very good performance, and stop for very short moments while watching Die Hard IV with menu and codec info displayed.

To be honest, for me all builds are working well and the problem with the first tested build ("without seek") is difficult to reproduce, so may also occur occasionally with other builds. Slight advantage, however, for the build "without seek and new scheme buffering" on my part, as it behaves better when stressing the cpu while watching a movie ... which is not really a decisive use case for sure ;-)


RE: OpenELEC Testbuilds for RaspberryPi - LehighBri - 2013-02-23

I haven't tried any of the custom builds, but I tried the official build r13360 and am getting audio/video out of sync about 2 seconds into a show. Is that what a lot of the buffering and patches that I'm reading about may fix once they stabilize?


RE: OpenELEC Testbuilds for RaspberryPi - hpbaxxter - 2013-02-23

After a bit more testing, the above mentioned error with the "without seek" build also occured with the "without seek and big buffer" build. So this may be caused by the new scheme buffering.

Another issue is that subtitles are delayed for about one to two seconds with Pulp Fiction remux compared to vlc media player, both pgs and vob subtitles. It's the same with the official rc3 build thogh. I don't know if it's due to limited performance, as the delay varies. This time the rpi was overclocked to cpu 900, core 333, ram 500, and it plays the same movie at stock rates, too.


RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2013-02-23

(2013-02-23, 02:59)hpbaxxter Wrote: After a bit more testing, the above mentioned error with the "without seek" build also occured with the "without seek and big buffer" build. So this may be caused by the new scheme buffering.

Another issue is that subtitles are delayed for about one to two seconds with Pulp Fiction remux compared to vlc media player, both pgs and vob subtitles. It's the same with the official rc3 build thogh. I don't know if it's due to limited performance, as the delay varies. This time the rpi was overclocked to cpu 900, core 333, ram 500, and it plays the same movie at stock rates, too.

On bulid without new scheme and no seek everything is ok and no audio sync issue??