[carmenm]

New newclock3 patch that fixes jpeg decoder hangs, needs to be checked for regressions:

I wouldn't mind getting new commit on newclock3 in a test build:
https://github.com/popcornmix/xbmc/commi...9acd3155e7

Seems to fix three different "jpeg hang" bug reports. I'd like to be sure it doesn't cause any regressions before adding to gotham branch.

In the latest builds i had a crash after playing videos (using omx) for about 10 min. First the audio would stop then XBMC would just hang.
I did not report it cause i did not find the time to get an actual log of it
This happens in a lot of builds after r18473 (tested with r18610 and r18622 at least)
Could that be the "jpeg hang" bug?

Right now i am staying on r18473 as it is the most stable build i had.

Thanks

[popcornmix]

In the latest builds i had a crash after playing videos (using omx) for about 10 min. First the audio would stop then XBMC would just hang.
I did not report it cause i did not find the time to get an actual log of it
This happens in a lot of builds after r18473 (tested with r18610 and r18622 at least)
Could that be the "jpeg hang" bug?

During video playback there should be no jpeg decodes going on, so the "jpeg hang" commit should have no effect.
Do all videos hang? Are these streamed from local network, internet, tv backend?

You say r18473 is stable. Was following build (r18478) unstable? Would be useful to identify the exact build that broke.

[carmenm]

In the latest builds i had a crash after playing videos (using omx) for about 10 min. First the audio would stop then XBMC would just hang.
I did not report it cause i did not find the time to get an actual log of it
This happens in a lot of builds after r18473 (tested with r18610 and r18622 at least)
Could that be the "jpeg hang" bug?

During video playback there should be no jpeg decodes going on, so the "jpeg hang" commit should have no effect.
Do all videos hang? Are these streamed from local network, internet, tv backend?

You say r18473 is stable. Was following build (r18478) unstable? Would be useful to identify the exact build that broke.

I would need to do a lot more testing. But for sure it was happening on all my movies, so i would say 1080p for sure. Movies are played through NFS
Sadly i can't say that r18478 "broke" it as i jumped it.
Will try to reproduce it and get a log with the latest one.
What log level do you want for this?

[Milhouse]

It would help if you used the build numbers (eg #0701b) when referring to a specific build, as r18478 or whatever can be meaningless since it's not unique - it could be (and often is) the same on two totally different builds. The rnnnnn number reflects only the OpenELEC revision which may not always change from one build to the next, yet these builds may have different firmware, kernel, XBMC and other patches.

[carmenm]

It would help if you used the build numbers (eg #0701b) when referring to a specific build, as r18478 or whatever can be meaningless since it's not unique - it could be (and often is) the same on two totally different builds. The rnnnnn number reflects only the OpenELEC revision which may not always change from one build to the next, yet these builds may have different firmware, kernel, XBMC and other patches.

Sorry i did not have them as the build number is not in the filename and it was not easy to get it from the first page. But in the filename have the date which is unique
The build which works is "OpenELEC_Helix-RPi.arm-Milhouse-20140526200520-r18473-gd1c84e1"
builds which crashed "OpenELEC_Helix-RPi.arm-Milhouse-20140616212007-r18610-g27d4fac" and "OpenELEC_Helix-RPi.arm-Milhouse-20140619192050-r18622-g3f9dd58"

[popcornmix]

What log level do you want for this?

Just enable debug logging in settings/system/debug.

[Milhouse]

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

Code:

# uname -a
Linux rpi512 3.15.3 #1 PREEMPT Thu Jul 3 03:18:35 BST 2014 armv6l GNU/Linux

# vcgencmd version
Jun 30 2014 22:01:00
Copyright (c) 2012 Broadcom
version 87aee38aa98517e53651d3400bf9261beb20c3e7 (clean) (release)

# lsb_release
OpenELEC_Helix (Milhouse) - Version: devel-20140703031244-r18668-g07f2d2f

Based on tip of OpenELEC master (07f2d2f, changelog) and tip of XBMC master (bb3554c, changelog) with the following modifications:

• Includes newclock3 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock3
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-3.15.y
  
• Excludes the OpenELEC xbmc-master-newclock3 patch in favour of sourcing these and possibly more recent patches directly from newclock3 branch
  
• Default setting for "Show RSS Feed" changed to disabled
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• ALSA is enabled and any suitable hardware should be available in XBMC Audio Settings
  
• FIQ FSM is enabled by default. See initial post for more details.
  
• Includes RPi-specific libCEC commits from mk01/libcec. See build #0527 for details. Also double-key suppression.
  
• 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 libnfs master with directory caching support
  

Build Highlights:

New kernel 3.15.3.
Additional newclock3 commits to reduce jpeg/texture memory consumption:

I've added a couple of schemes to limit number of textures.
When gpu reloc free memory is low, unused textures are discarded immediately rather than after 5 seconds. I didn't see much effect from this, but it's something that theoretically should help.

Previously, quite a log of jpeg jobs could be submitted to gpu at once. I think there are 5 background loader threads, the app thread and possibly some re-encodes.
They will all block eventually on GPU due to the single jpeg hardware block, but while blocked on GPU, there are buffers allocated consuming GPU memory.
We don't want to only submit one job at a time, as you do get some overlap of jpeg work and vchiq message transfer.
So, the new commit limits number of jobs to 3 which is almost optimal for speed, but should save some memory.

I've also changed the last jpeg hang commit to only do the idle/flush calls when an error occurred. This should be a little quicker and less likely to cause problems in the usual success case.

1. OpenELEC:
   • lzo: update to lzo-2.08
     
   • linux: update to linux-3.15.3
     
   • alsa-utils: dont install default ALSA restore rule, to avoid overwriting our own mixer settings with default values.
     
   • busybox: add upstream patches
     
   • simplejson: update to simplejson-3.5.3
     
2. XBMC:
   • [AE/osxsink] refactor the device enumeration for the osx sink (PR:4890, 6 commits, 12 files changed)
     
   • [ios] - support XCode 5.1.1 with iOS SDK 7.1 (PR:4958, 6 commits, 7 files changed)
     
   • [ios] - backports from linusyang (PR:4957, 7 commits, 9 files changed)
     
   • Remove CDVDMessageTracker (PR:4862, 1 commit, 10 files changed)
     
   • Xml attribute tidy up (PR:4971, 13 commits, 29 files changed)
     
   • Stdstring removal part 0 (PR:4968, 6 commits, 26 files changed)
     
   • Fixes to VobSub subtitles loading (PR:1505, 2 commits, 4 files changed)
     
   • [posixdirectory] added missing IsAliasShortcut handling (PR:4972, 1 commit, 1 file changed)
     
   • automatic versioning (PR:4866, 5 commits, 25 files changed)
     
   • More efficient info label assembling (PR:4919, 8 commits, 11 files changed)
     
   • Use File::LoadFile() instead of custom implementaions (PR:4961, 17 commits, 29 files changed)
     
   • [win32] Implement new Win32SMBDirectory (PR:4952, 2 commits, 5 files changed)
     
   • [music] allow SortByYear to sort by year, album, track, then label (PR:4918, 1 commit, 1 file changed)
     
3. newclock3:
   • [settings] Add update flag to omx acceleration
     
   • [pi] Reduce time textures are held for when memory is low
     
   • [omx] Restrict the number of outstanding jpeg calls to gpu
     

[FAMMAR]

This build is fast in loading fanart or am I crazy?..

[Mafarricos]

#0701b feels slower than 27 Jun release. Navigation and loading images.

Any errors in log?

No errors to report, but now with #0703 seems faster than #701b.

[doveman2]

My brother's been running the 0611 build and tells me he's had three problems:

1) Not being able to wake it from dimmed screen state

2) Videos stopping suddenly and the RPi rebooting. Apparently this happens randomly, sometimes after a few seconds and other times half-way through the video and on the next try, they can play from the problem point OK.

3) Videos suddenly becoming choppy and the sound breaking up, before stopping. This sounds like a buffering issue (these are local videos on the PC, not streamed though).

I've updated him to the 0703 build but has there been any changes since the 0611 one that might fix these problems? I've told him to try the alternate player if he still has problems (Default is set to dvdplayer).

[Mafarricos]

My brother's been running the 0611 build and tells me he's had three problems:

1) Not being able to wake it from dimmed screen state

2) Videos stopping suddenly and the RPi rebooting. Apparently this happens randomly, sometimes after a few seconds and other times half-way through the video and on the next try, they can play from the problem point OK.

3) Videos suddenly becoming choppy and the sound breaking up, before stopping. This sounds like a buffering issue (these are local videos on the PC, not streamed though).

I've updated him to the 0703 build but has there been any changes since the 0611 one that might fix these problems? I've told him to try the alternate player if he still has problems (Default is set to dvdplayer).

1) How does he wakes the Rpi? Via HDMI-CEC or a wireless keyboard, or mouse? I think the dims can break the CEC, so you can only wake up with a physical device.
2) and 3) Did you already tried to disable fiq_fsm, probably can be that, check the additional notes on first post: http://forum.xbmc.org/showthread.php?tid...pid1682865

[calcon79]

I ended up giving up on deinterlacing completely. It seems the DVDPlayer gives no video just audio when deinterlacing is enabled on all of my mpeg-2 videos. Looking back through this thread I can see other people have had this issue. I can also say that using OMXPlayer there are still issues with deinterlacing enabled. The audio drops out randomly and the screen blinks black for a second. It seems completely random. I can rewind the video and it won't happen at the same spot. I am also experiencing lock ups after playing 1080i .ts mpeg-2 files for a while. When disabling deinterlacing, ALL of these issues are gone. Deinterlacing used to work before Openelec 4.0 for me.

I saw a previous post where popcorn mix recommended increasing the gpu_mem to 256 for a 512MB Pi. I have this setting already so I'm not sure how else to work around this. It seems with the new gpu hardware acceleration there is some sort of limitation being reached on the Pi. Could it be that even more gpu_mem is needed? Can I safely go above 256MB?

[Milhouse]

@calcon79: Upload a sample video that demonstrates the problem so that it can be investigated, it's the best way to work towards a fix. Did you ever upload a sample of the Power90 DVD?

[calcon79]

Ok I uploaded it to dropbox. Hope it helps. If I try to play with DVDPlayer and deinterlacing enabled I get no video but audio. If I play with deinterlacing enabled with OMXPlayer I get the flickering audio dropouts and video screen blinks. I am playing this over and NFS share.

https://dl.dropboxusercontent.com/u/4895...0Patrol.ts

[popcornmix]

I ended up giving up on deinterlacing completely. It seems the DVDPlayer gives no video just audio when deinterlacing is enabled on all of my mpeg-2 videos. Looking back through this thread I can see other people have had this issue. I can also say that using OMXPlayer there are still issues with deinterlacing enabled. The audio drops out randomly and the screen blinks black for a second.

It could be a memory bandwidth issue. Increasing sdram_freq or core_freq may help.
You could also try increasing the display's memory priority. Add to config.txt

Code:

hvs_priority=0x32ff

I saw a previous post where popcorn mix recommended increasing the gpu_mem to 256 for a 512MB Pi. I have this setting already so I'm not sure how else to work around this. It seems with the new gpu hardware acceleration there is some sort of limitation being reached on the Pi. Could it be that even more gpu_mem is needed? Can I safely go above 256MB?

Yes, you can try going higher. Evenetually you may find the arm runs out of memory, but give 320 or even 352 a go.