[slack3r]

What build did the problem start with? It seems inconclusive (unless I've missed a post)

Oh OK, I thought it had been decided it was #1005, but I missed the edit, so agreed - still no idea when the problem started.

Ok, I've found a "range":
build #0908 works fine, #0929 does stuttering.

I got it! The "bad guy" is #0921.

[popcornmix]

I got it! The "bad guy" is #0921.

The list of changes doesn't indicate anything obviously responsible.
You're very sure that #920 is good and #921 is bad?

[Solo0815]

Did some testing, #0923 and #0925 stutters and I got a lot of this errors while stuttering appears.

Code:

14:32:36 223.267624 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Pause 6.00,0.06 (A:00 V:10) EOF:0 FULL:0 T:16.00
14:32:36 223.267944 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
14:32:36 223.294617 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Resume 6.00,0.14 (A:00 V:00) EOF:0 FULL:1 T:16.00
14:32:36 223.295074 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
14:32:36 223.467239 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Pause 6.00,0.09 (A:00 V:10) EOF:0 FULL:0 T:16.00
14:32:36 223.467743 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
14:32:36 223.521164 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Resume 6.00,0.13 (A:00 V:00) EOF:0 FULL:1 T:16.00
14:32:36 223.521606 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
14:32:37 224.437851 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Pause 6.11,0.09 (A:00 V:10) EOF:0 FULL:0 T:16.00
14:32:37 224.438354 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
14:32:37 224.484512 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Resume 6.11,0.13 (A:00 V:00) EOF:0 FULL:1 T:16.00
14:32:37 224.485428 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
14:32:38 225.086823 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Pause 6.01,0.07 (A:00 V:10) EOF:0 FULL:0 T:16.00
14:32:38 225.087357 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1
14:32:38 225.108582 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Resume 6.01,0.11 (A:00 V:00) EOF:0 FULL:1 T:16.00
14:32:38 225.108978 T:2754634832   DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
14:32:38 225.280167 T:2754634832   DEBUG: CDVDPlayer::OMXDoProcessing Pause 6.01,0.06 (A:00 V:10) EOF:0 FULL:0 T:16.00

and:

Code:

14:40:37 104.000572 T:2786915408   DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
14:40:37 104.150200 T:2747266128 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
14:40:37 104.152702 T:2786915408   DEBUG: CDVDPlayer::OMXDoProcessing Pause 6.12,0.06 (A:00 V:10) EOF:0 FULL:0 T:16.00

[slack3r]

The list of changes doesn't indicate anything obviously responsible.
You're very sure that #920 is good and #921 is bad?

I can not say "very sure", but I am pretty sure. I get stuttering with #0921, not with #0920. Stuttering can be forced by seeking backward/forward - after subititle is loaded. I tested with same stream, same sub, same settings. So, the answer is yes, I'm sure - pretty sure: #0921 does evident stuttering, #0920 not.

Tonight I can do more testing.

Did some testing and #0925 stutters and I got a lot of this errors while stuttering appears.

Hi,
can you test build #0920 and #0921?
Thanks

[bastos]

I'm using the last build and the HD channels are working good but on SD channels I can't get video just audio. If I disable "allow hardware acceleration (OMXPLayer)" I can get video but it becomes laggy, almost unwatchable.

[Solo0815]

I can confirm the findings:
#0920 is not stuttering, no entries in the log like this: http://forum.xbmc.org/showthread.php?tid...pid1821622
#0921 and above are stuttering with the mentioned log-entries

[popcornmix]

I'm using the last build and the HD channels are working good but on SD channels I can't get video just audio. If I disable "allow hardware acceleration (OMXPLayer)" I can get video but it becomes laggy, almost unwatchable.

Sounds like no MPEG2 licence. A log file would confirm this.

[popcornmix]

I can not say "very sure", but I am pretty sure. I get stuttering with #0921, not with #0920. Stuttering can be forced by seeking backward/forward - after subititle is loaded. I tested with same stream, same sub, same settings. So, the answer is yes, I'm sure - pretty sure: #0921 does evident stuttering, #0920 not.

I don't think anything in newclock4 will be responsible. This appeared in #921:
https://github.com/xbmc/xbmc/pull/5370

which, while not directly affecting omxplayer may subtly change behaviour (number of render buffers used does potentially change).
I'll see if I can reproduce and if reverting parts of that PR has an effect.

EDIT: seems the bitcoin URL is no longer active so I can't reproduce. If anyone has another public link that shows the problem I can test.
Otherwise I may just may a guess at what to revert.

EDIT2: I've made a commit with my guess...

[bastos]

I'm using the last build and the HD channels are working good but on SD channels I can't get video just audio. If I disable "allow hardware acceleration (OMXPLayer)" I can get video but it becomes laggy, almost unwatchable.

Sounds like no MPEG2 licence. A log file would confirm this.

Thank you @popcornmix adding MPEG 2 license solved the problem.

[slack3r]

If anyone has another public link that shows the problem I can test.
Otherwise I may just may a guess at what to revert.

First one: many thanks for your great work ^^

About the link: I have sent you a private message.

[Milhouse]

New OpenELEC Helix build: #1025
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 3.17.1 #1 PREEMPT Sat Oct 25 21:03:08 BST 2014 armv6l GNU/Linux

# vcgencmd version
Oct 17 2014 17:56:05
Copyright (c) 2012 Broadcom
version 845092531e360acd37f2f1964157f8079c77edfb (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20141025210157-r19455-g0a37f62 [Build #1025]

Based on tip of OpenELEC master (0a37f62e, changelog) and tip of XBMC master (ea81a856, changelog) with the following modifications:

• Includes newclock4 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock4
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-3.17.y
  
• Excludes the OpenELEC xbmc-001-newclock4 patch in favour of sourcing these and possibly more recent patches directly from newclock4 branch
  
• Default setting for "Show RSS Feed" changed to disabled
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Adapted service.openelec.settings to take advantage of PR5217
  
• Includes latest libnfs master (ab1af695)
  
• Includes latest opdenkamp libcec-2.2.0 branch (b5d801b8)
  
• Includes latest xbmc-pvr-addons master (067befe6)
  
• Includes latest xbmc-addon-xvdr master (2bf2563c)
  
• Increase scan interval of PeripBusCEC from 5000 to 60000, reducing CPU loading by about 2% (1GHz Pi) every 5 seconds (even when CEC is "disabled")
  
• Includes CONFIG_COREDUMP=y to allow creation of coredumps (see here)
  
• Includes additional ffmpeg codecs/muxers enabled for testing/benchmarking purposes. See patch
  
• Includes PR:5312: dvdplayer: do a seek after having changed subtitle stream
  
• Includes PR:5416: added: POC mp4 movie/episode tag support
  
• Includes PR:5524: Respect parent path decision when cleaning paths.
  
• Includes PR:5573: webserver: improved caching control (see discussion)
  

Build Highlights:

1. Switch libcec package to opdenkamp/libcec/libcec-2.2.0 with the following updates:
   • return HDMI physical address using EDID data retrieved from X11 randr extension
     
   • fix indentation and a few typos
     
   • Add support for Exynos HDMI
     
   • fix RPI POLL during LA address negotiation
     
   • fix assertion on XBMC exit
     
   • this solves problem with device dissapearing from TV's menu
     
   • RPI updates with fixes
     
   • probably ugly hack to help with some
     
   • Added another id for vendor Harman/Kardon (0x001950)
     
   • Fixed CCECCommandHandler::HasSpecificHandler implementation to include vendor TOSHIBA, TOSHIBA2, ONKYO.
     
   • Added support for user control codes TOP_MENU, DVD_MENU, SELECT_BROADCAST_TYPE, SELECT_SOUND_PRESENTATION, NUMBER_ENTRY_MODE, NUMBER11, NUMBER12.
     
   • Fix typo in rejecting invalid keycodes
     
   • bump to v2.2.0
     
2. newclock4: Potential fix for subtitle induced stuttering
   

Build Details:

1. OpenELEC:
   • scripts/addon: add option to test if addon() fails
     
2. XBMC:
   • [ios] - add support for compiling with Xcode 6 and iOS 8 SDK (PR:5403, 9 commits, 15 files changed)
     
   • runscript: make sure to get the correct extension point to run (PR:5563, 1 commit, 1 file changed)
     
   • [wip] redact username/password when logging (PR:5568, 4 commits, 3 files changed)
     
   • [pvr] Fix unexpected sub channel merge in EPG grid (PR:5564, 1 commit, 1 file changed)
     
   • [wip] CHG: [droid] refactor packaging to allow obb google extension apk (PR:5108, 1 commit, 5 files changed)
     
   • [rebrand] fix minor @echo @APP_NAME@ intead of kodi/xbmc (PR:5553, 1 commit, 1 file changed)
     
3. newclock4:
   • Renderer: Force queue size to at least 3
     
4. Custom:
   • Add PR:5573: webserver: improved caching control (see discussion)
     

[Milhouse]

The double-key suppression fix for Panasonic TVs will be restored in the next build - I mistakenly dropped it along with the libcec patches that are now merged in libcec-2.2.0.

[Forage]

The double-key suppression fix for Panasonic TVs will be restored in the next build - I mistakenly dropped it along with the libcec patches that are now merged in libcec-2.2.0.

Thanks for keeping this one in. I'll wait for the next build than.
I am, however, a bit concerned with the "this solves problem with device dissapearing from TV's menu" commit in libcec-2.2.0 because of the "needs fix on adapter side" part. Is it backwards compatible with adapters still having 2.1.4?
I'm hoping this update will allow us to update the adapter's firmware as well if it's not backwards compatible with 2.1.4. I'm expecting people reporting issues if it's not backwards compatible and people can't or didn't update the firmware. So it would be good to keep an eye on that.

[popcornmix]

Thanks for keeping this one in. I'll wait for the next build than.
I am, however, a bit concerned with the "this solves problem with device dissapearing from TV's menu" commit in libcec-2.2.0 because of the "needs fix on adapter side" part. Is it backwards compatible with adapters still having 2.1.4?
I'm hoping this update will allow us to update the adapter's firmware as well if it's not backwards compatible with 2.1.4. I'm expecting people reporting issues if it's not backwards compatible and people can't or didn't update the firmware. So it would be good to keep an eye on that.

There is no CEC adapter firmware on the Pi - I guess this is referring to the Pulse Eight USB device, and probably doesn't apply to the Pi.
However that's why we want these patches in the test builds. If there are any problems, best to identify them before an official release.

[Forage]

Thanks for keeping this one in. I'll wait for the next build than.
I am, however, a bit concerned with the "this solves problem with device dissapearing from TV's menu" commit in libcec-2.2.0 because of the "needs fix on adapter side" part. Is it backwards compatible with adapters still having 2.1.4?
I'm hoping this update will allow us to update the adapter's firmware as well if it's not backwards compatible with 2.1.4. I'm expecting people reporting issues if it's not backwards compatible and people can't or didn't update the firmware. So it would be good to keep an eye on that.

There is no CEC adapter firmware on the Pi - I guess this is referring to the Pulse Eight USB device, and probably doesn't apply to the Pi.
However that's why we want these patches in the test builds. If there are any problems, best to identify them before an official release.

I was referring to the Pulse Eight USB-CEC adapter as well, as I'm one of the users having one ;-)