[Milhouse]

I was going to do so, but as I took the target files from the official Openelec 5.0.8 stable build and "upgraded" using them and it still happened, I didn't think it was related to these test builds. Logs look ok and no crash so would e nothing in the crash logs. Do you still think it could be related to the test builds after that? If so I can roll back over the weekend - I think the last ok build was 508 but I can't be sure until I work back through them.

If it's only started happening with recent test builds, and continues to happen with 5.0.8 (when presumably it didn't before), then yes that is rather odd... I'd suggest a clean .kodi in case a setting or addon has now been screwed up. After re-upgrading to #0514, in ssh:

Code:

systemctl stop kodi
mv .kodi .kodi.bak
sync && reboot

then test your movies again (you can restore your old .kodi afterwards).

If you still have the problem after the above, upload your debug log when playing a problem movie - at the very least this will include the video/audio details which might give a clue as to what is going on. One possibility might be that your gpu_mem setting is not high enough (should be 128 for a Pi1 with 512MB, 256 for a Pi2).

[nikc0069]

I was going to do so, but as I took the target files from the official Openelec 5.0.8 stable build and "upgraded" using them and it still happened, I didn't think it was related to these test builds. Logs look ok and no crash so would e nothing in the crash logs. Do you still think it could be related to the test builds after that? If so I can roll back over the weekend - I think the last ok build was 508 but I can't be sure until I work back through them.

If it's only started happening with recent test builds, and continues to happen with 5.0.8 (when presumably it didn't before), then yes that is rather odd... I'd suggest a clean .kodi in case a setting or addon has now been screwed up. After re-upgrading to #0514, in ssh:

Code:

systemctl stop kodi
mv .kodi .kodi.bak
sync && reboot

then test your movies again (you can restore your old .kodi afterwards).

If you still have the problem after the above, upload your debug log when playing a problem movie - at the very least this will include the video/audio details which might give a clue as to what is going on. One possibility might be that your gpu_mem setting is not high enough (should be 128 for a Pi1 with 512MB, 256 for a Pi2).

Thanks Milhouse. That is very much a possibility. I'll check that out first and if it doesn't resolve it then I will do the above over the weekend and report back. As always, many thanks.

[Leopold]

Any ideas about this? I did a tail -f on the log file while watching live tv and didn't see any errors.

I was thinking more of visual glitches on screen (e.g. from a weak antenna signal). They can sometimes cause audio sync issues.
Ideally I'd like a sample that shows the problem - then I'd know exactly what the issue is, but you say recordings play fine?

In settings/system/debugging/component specific can you enable "Dump video frames to debug file" and "Dump audio frames to debug file".
You should end up with files in ~/.kodi/temp. Can you upload debug files that had the audio sync issue?

No there are no visual glitches, I am lucky to have a very strong signal so that is never a problem. Yes recordings always play fine.
I've been using #0512 for a couple of days and it's been perfect. I have upgraded to #0514 and the problem is back. I see you reverted the change so that is expected.

http://paste.ubuntu.com/11148908/
kodi.log
video.dat
audio.dat

[Leopold]

I'm getting very regular crashes with the latest builds. Here's logs for the two most recent ones.
kodi_crashlog_20150515130529.log
kodi_crashlog_20150515173241.log

Any chance of a new debug build? I have a large enough system partition to run one.

[popcornmix]

I'm getting very regular crashes with the latest builds. Here's logs for the two most recent ones.

Can you confirm exactly which is the first build with the problem? Seems to be crashing in libavcodec (without a debug build we can't see much more detail), which would make me suspect the h.265 patch. Would be useful to confirm it started with that build.

Second crash looks different:

Code:

#0  0x009495b8 in std::pair<std::_Rb_tree_iterator<std::pair<std::string const, AvahiServiceBrowser*> >, bool> std::_Rb_tree<std::string, std::pair<std::string const, AvahiServiceBrowser*>, std::_Select1st<std::pair<std::string const, AvahiServiceBrowser*> >, std::less<std::string>, std::allocator<std::pair<std::string const, AvahiServiceBrowser*> > >::_M_insert_unique<std::pair<std::string, AvahiServiceBrowser*> >(std::pair<std::string, AvahiServiceBrowser*>&&) ()

Not sure if anything has changed with that? Airtunes patch maybe?

[blubb0r]

I have tested the last 3 builds on my Pi 2.
Tested content:
m2ts or mkv with untouched BD video and DTS HD MA audio (20+ files, average file size 30GB)

Stuttering, frame drops, ...
AVR can DTS HD MA decode, so I tested Passthrough, and Passthrough with PCM. Nothing works.

Default build works fine (but only with DTS Core and AC3 instead of DTS HD MA and Dolby True HD).
3D MVC in mkv is not working as well.

All works perfect on a Surface Pro 3, Intel NUC and AMD HTPC (A8 APU). Streaming the content from a NAS (capable of providing Gbit speed) with 40TB space.


How can I help you find the issues? Logs?
Metainformation?

[fab67]

oh man...HEVC (x265) 720p works on rp2 ? that is awesome!!!

Certainly is. With this version many 720p files should play fine. There will be files with certain encoding options that may not keep up, but that is still being worked on.
We'll try an improve hevc performance futher, but it's hard to be certain what the limit will be.

For now any testing of hevc/h.265 would be useful. Of most interest is any files that play with corruption or crash (and worked before this update).
I'd be interested in any reports of successes (resolution/bitrate etc from mediainfo would be useful).
Report on any 720p (or lower) files that fail to keep and and we can look into them.

Thanks for the new HEVC decoder version. Almost all the 720p samples ( preset fast/medium and crf 20 to 23) I try works good.
But this one for example (Landscape) doesn't : https://drive.google.com/file/d/0B3hIUz8...sp=sharing
I must use -tune fastdecode with x265 to get this smooth : https://drive.google.com/file/d/0B3hIUz8...sp=sharing

And even some 1080p samples works good when I use -tune fastdecode in x265.

Thanks again for the great work.

[popcornmix]

http://paste.ubuntu.com/11148908/
kodi.log
video.dat
audio.dat

Thanks. Taken a bit of hacking, but I've got your file too play and I can see the speed speed up/down.
That's the first step to solving the problem...

[nikc0069]

I was going to do so, but as I took the target files from the official Openelec 5.0.8 stable build and "upgraded" using them and it still happened, I didn't think it was related to these test builds. Logs look ok and no crash so would e nothing in the crash logs. Do you still think it could be related to the test builds after that? If so I can roll back over the weekend - I think the last ok build was 508 but I can't be sure until I work back through them.

If it's only started happening with recent test builds, and continues to happen with 5.0.8 (when presumably it didn't before), then yes that is rather odd... I'd suggest a clean .kodi in case a setting or addon has now been screwed up. After re-upgrading to #0514, in ssh:

Code:

systemctl stop kodi
mv .kodi .kodi.bak
sync && reboot

then test your movies again (you can restore your old .kodi afterwards).

If you still have the problem after the above, upload your debug log when playing a problem movie - at the very least this will include the video/audio details which might give a clue as to what is going on. One possibility might be that your gpu_mem setting is not high enough (should be 128 for a Pi1 with 512MB, 256 for a Pi2).

Thanks Mil house it was the gpu setting. It had somehow got set to 80!

[cudencuden]

oh man...HEVC (x265) 720p works on rp2 ? that is awesome!!!

Certainly is. With this version many 720p files should play fine. There will be files with certain encoding options that may not keep up, but that is still being worked on.
We'll try an improve hevc performance futher, but it's hard to be certain what the limit will be.

For now any testing of hevc/h.265 would be useful. Of most interest is any files that play with corruption or crash (and worked before this update).
I'd be interested in any reports of successes (resolution/bitrate etc from mediainfo would be useful).
Report on any 720p (or lower) files that fail to keep and and we can look into them.

Thanks for the new HEVC decoder version. Almost all the 720p samples ( preset fast/medium and crf 20 to 23) I try works good.
But this one for example (Landscape) doesn't : https://drive.google.com/file/d/0B3hIUz8...sp=sharing
I must use -tune fastdecode with x265 to get this smooth : https://drive.google.com/file/d/0B3hIUz8...sp=sharing

And even some 1080p samples works good when I use -tune fastdecode in x265.

Thanks again for the great work.

what are you using for your encoder? I was going to use Handbrake software

[fab67]

I'm using my own ffmpeg build with lastest x265 for this samples and sometimes directly x265.exe ( with avs2yuv.exe for input )
ffmpeg -i "source" -s hd720 -c:v libx265 -preset xxx -crf xxx "target.mkv"

and for preset fast or medium, for crf between 20 and 23 and add -tune fastdecoder for some tests.

[snyft]

Will this HEVC thingy have any impact on 10bit x264?
Maybe not right place but would an intel nuc be able to play 10bit x264 without artifacts?

[popcornmix]

Will this HEVC thingy have any impact on 10bit x264?
Maybe not right place but would an intel nuc be able to play 10bit x264 without artifacts?

No connection between HEVC and 10bit h.264.
Pi will never support 10bit.
I believe a nuc would play 10 h.264 without artefacts.

[steve1977]

Any change?

Last chance to reply before the AirTunes stuff is dropped from the next build... this is a testing thread, if stuff is added by request it won't be kept unless there is a confirmed positive benefit.

Apologies, I must have missed ths. Let me try over the weekend and get back. Would be great if this was implemented!

Fantastic!!! Both features are included in the most recent built. They work well and would be great to keep in. With two features I am referring to the .png support as well as the skipping-track support. Thanks again to you and obviusly also to memphiz.

[Milhouse]

New OpenELEC Isengard build #0515: RPi / RPi2
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 4.0.2 #1 Fri May 15 23:31:58 BST 2015 armv6l GNU/Linux

# vcgencmd version
May 13 2015 14:58:12
Copyright (c) 2012 Broadcom
version 8e0e0dbfe92be77d6355082451280d32f5bf0ff3 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150515233111-#0515-g7193a10 [Build #0515]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (7193a101, changelog) and tip of XBMC master (13d01457, 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-4.0.y
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest dcadec master (37d8e689)
  
• Includes latest kodi-platform master (054a42f6)
  
• Includes latest libcec master (18555911)
  
• Includes latest libnfs master (77e3d80f)
  
• Includes latest platform master (aafa6e9f)
  
• Includes latest addons: pvr.argustv (fa84ac21), pvr.demo (34d60a1a), pvr.dvblink (6084c4ec), pvr.dvbviewer (3dd826e4), pvr.filmon (8794b9c1), pvr.hts (d038dfcb), pvr.iptvsimple (27c4221e), pvr.mediaportal.tvserver (d9bfdee5), pvr.mythtv (c8104897), pvr.nextpvr (ecc65989), pvr.njoy (2733f344), pvr.pctv (c240226a), pvr.stalker (2d65b21d), pvr.vbox (52fe59a6), pvr.vdr.vnsi (824a8a4c), pvr.vuplus (d7270912), pvr.wmc (295b2161)
  
• Includes commits from shairplay/master (juhovh)
  
• Exclude kodi-995.01-add-dcadec-support.patch: Temporarily revert dcadec settings and use newclock4 version
  
• Include patch: Enable vcsm kernel options for HEVC optimisations
  
• Include patch: Enable the mailbox driver (new kernel options)
  
• Include patch: Enable dcadec on x86
  
• Include patch: Add experimental splash video
  
• Include patch: Add ffmpeg dependency and includes for HEVC optimisations
  
• Include patch: Enable pvr addons
  
• Include PR:6732: [pvr] fixed crash when multiple add-on instances get registered
  
• Include PR:6919: added: also hide thumbs for unwatched episodes if option to show plot is off
  
• Include PR:7048: videodb: Don't allow column value length to exceed key size of unique index
  
• Include PR:7093: [AirTunes] - features
  
• Revert 47d39d71: Revert kernel 4.0.3 until raspberrypi sync
  

Build Highlights:

1. New mmc and sdhost overclock options
   Note: any experimenting with sdcard overclock could cause corruption, so only test if you are backed up.
   

   The attached patches (against rpi-4.0.y) add the overclock ability to the bcm2835-mmc and bcm2835-sdhost drivers.
   
   The mmc driver loads by default, but you can gratuitously use an overlay:
   

   Code:

   dtoverlay=mmc

   
   The sdhost driver requires an overlay to select it:
   

   Code:

   dtoverlay=sdhost

   
   To activate the overclock, use one of the following:
   

   Code:

   dtoverlay=mmc,overclock_50=63
    dtoverlay=sdhost,overclock_50=63
    dtoverlay=sdhost,overclock_50=84

   
   Supplied overclock values will be substituted when the MMC framework requests 50MHz, after rounding down to an (even, in the case of the mmc driver) integer division of 250MHz (or whatever the core clock is, if overclocking). You will get a warning message during bootup showing that the overclock is active:
   

   Code:

   rpi22:~ # dmesg | grep Overclock
[    1.518576] mmc0: Overclocking to 62500000Hz

   
   These are the results from a Rev 1.1 B+ (the mmc driver can't reach 50MHz because of the even-clock-divisor requirement):
   

   Code:

   Class 6 NOOBS:
mmc    42 -> hdparm -t=17.52MB/s, dd read=18.2MB/s, dd write=7.0MB/s
sdhost 50 -> hdparm -t=21.22MB/s, dd read=22.1MB/s, dd write=7.0MB/s (read +21%)
mmc    63 -> hdparm -t=25.07MB/s, dd read=26.0MB/s, dd write=7.0MB/s (read +43%)
sdhost 63 -> hdparm -t=25.97MB/s, dd read=27.0MB/s, dd write=7.0MB/s (read +48%)
sdhost 84 -> hdparm -t=32.95MB/s, dd read=34.0MB/s, dd write=7.0MB/s (read +87%)

Sandisk Class 10:
mmc    42 -> hdparm -t=17.83MB/s, dd read=18.6MB/s, dd write=9.7MB/s
sdhost 50 -> hdparm -t=21.27MB/s, dd read=22.1MB/s, dd write=10.0MB/s (read +18%, write +3%)
mmc    63 -> hdparm -t=25.87MB/s, dd read=26.8MB/s, dd write=10.3MB/s (read +44%, write +6%)
sdhost 63 -> hdparm -t=26.02MB/s, dd read=27.0MB/s, dd write=10.3MB/s (read +45%, write +6%)
sdhost 84 -> hdparm -t=33.31MB/s, dd read=34.4MB/s, dd write=10.5MB/s (read +85%, write +8%)

   
   Note that you can confirm the current operating state of the card using:
   

   Code:

   cat /sys/kernel/debug/mmc0/ios

   Phil

   
   These are my (@Milhouse) benchmark results when using a class 6 NOOBS 8GB SD card in a RPi2. Results are from this script:
   
   
   Code:

   Overlay config                      core_freq   turbo   overclock_50    WRITE        READ        HDPARM
dtoverlay=mmc                          250        0      41.667 Mhz    6.06 MB/s   18.21 MB/s   18.54 MB/s   [1]
dtoverlay=mmc,overclock_50=63          250        0      62.500 Mhz    5.95 MB/s   26.47 MB/s   26.58 MB/s
dtoverlay=sdhost                       250        0      50.000 Mhz    5.90 MB/s   21.49 MB/s   21.64 MB/s
dtoverlay=sdhost,overclock_50=63       250        0      62.500 Mhz    5.93 MB/s   26.34 MB/s   26.80 MB/s
dtoverlay=sdhost,overclock_50=84       250        0      83.333 MHz    5.98 MB/s   34.00 MB/s   34.87 MB/s

dtoverlay=mmc                          250        1      41.667 MHz    6.03 MB/s   18.28 MB/s   18.48 MB/s   [1]
dtoverlay=mmc,overclock_50=63          250        1      62.500 MHz    6.01 MB/s   26.61 MB/s   27.15 MB/s
dtoverlay=sdhost                       250        1      50.000 MHz    6.03 MB/s   21.50 MB/s   22.00 MB/s
dtoverlay=sdhost,overclock_50=63       250        1      62.500 MHz    6.06 MB/s   26.35 MB/s   27.15 MB/s
dtoverlay=sdhost,overclock_50=84       250        1      83.333 MHz    6.00 MB/s   34.02 MB/s   35.41 MB/s

dtoverlay=mmc                          500        0      41.667 MHz    5.89 MB/s   18.21 MB/s   18.32 MB/s
dtoverlay=mmc,overclock_50=63          500        0      62.500 MHz    5.96 MB/s   26.48 MB/s   26.58 MB/s
dtoverlay=mmc,overclock_50=84          500        0      62.500 MHz    5.90 MB/s   26.46 MB/s   26.58 MB/s   [2, 3]
dtoverlay=sdhost                       500        0      50.000 MHz    5.99 MB/s   11.25 MB/s   11.18 MB/s   [4]
dtoverlay=sdhost,overclock_50=63       500        0      62.500 MHz    5.94 MB/s   13.97 MB/s   13.91 MB/s   [4]
dtoverlay=sdhost,overclock_50=72       500        0      71.429 MHz    5.96 MB/s   15.89 MB/s   15.79 MB/s   [4]
dtoverlay=sdhost,overclock_50=84       500        0      83.333 MHz    6.01 MB/s   18.35 MB/s   18.30 MB/s   [4]
dtoverlay=sdhost,overclock_50=100      500        0     100.000 MHz    6.00 MB/s   21.78 MB/s   21.76 MB/s   [4]

dtoverlay=mmc                          500        1      41.667 MHz    6.11 MB/s   18.31 MB/s   18.48 MB/s   [1]
dtoverlay=mmc,overclock_50=63          500        1      62.500 MHz    6.14 MB/s   26.67 MB/s   27.24 MB/s
dtoverlay=mmc,overclock_50=84          500        1      62.500 MHz    6.06 MB/s   26.66 MB/s   27.24 MB/s   [2]
dtoverlay=sdhost                       500        1      50.000 MHz    6.12 MB/s   21.50 MB/s   22.01 MB/s
dtoverlay=sdhost,overclock_50=63       500        1      62.500 MHz    6.11 MB/s   26.34 MB/s   27.15 MB/s
dtoverlay=sdhost,overclock_50=72       500        1      71.429 MHz    6.05 MB/s   29.69 MB/s   30.82 MB/s
dtoverlay=sdhost,overclock_50=84       500        1      83.333 MHz    6.06 MB/s   34.01 MB/s   35.53 MB/s
dtoverlay=sdhost,overclock_50=100      500        1     100.000 MHz    6.14 MB/s   39.81 MB/s   41.72 MB/s
   Observations:
   
   1. The MMC driver with default clock won't achieve a 50MHz clock due to even divisor requirement (250/50 => 5, which isn't supported by the mmc driver). Nearest clock frequency with an even divisor (6) is 41.667MHz. However, at 500MHz core_freq, an even divisor of 10 would give 50MHz...
      
   2. The MMC driver won't accept an 84MHz overclock with core_freq=500 - this should be a divisor of 6 (even) (see explanation)
      
   3. The performance of the SDHost driver is comparable with the MMC driver at lower overclocks, however the former supports both odd/even divisors whereas the latter is limited to even divisors
      
   4. The performance of the SDHost driver suffers significantly at higher core_freq with force_turbo disabled. Probably best not to use sdhost at higher core_freq unless force_turbo is enabled. Turbo can be enabled in config.txt, or with:
      
      Code:

      echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
      (Edit: Fixed in build #0616 with the introduction of PR:4200)
      
   Possible mmc/sdhost overclocks, based on various core frequencies - adjust core frequency to enable a specific overclock_50 frequency (bracketed items may be too high/unstable):
   
   Code:

   Core     mmc            sdhost
Freq     overclock_50   overclock_50

250      63             63,84
275      63             55,69,92
300      63             60,75,100
325      63             55,65,82,(109)
350      63             59,70,88,(117)
375      63             54,63,75,94
400      63             58,67,80,100
425      63             54,61,71,85,(107)
450      63             57,65,75,90,(113)
475      63             53,60,68,80,95,(119)
500      63             56,63,72,84,100

Build Details:

1. OpenELEC:
   • linux: for imx6 include soc fan and status led packages (PR:4152, 1 commit, 1 file changed)
     
2. XBMC:
   • [Libcurl] 404 fix + misc. tweaks (PR:7137, 2 commits, 2 files changed)
     
   • Added KEY_PLAYCD and KEY_PAUSECD for linux support of BT headphones (PR:7132, 1 commit, 1 file changed)
     
   • FIX: [stf;3D] stagefright is no longer flipped in Y (PR:7140, 1 commit, 1 file changed)
     
   • [cmake] add libplatform to kodi-platform depends (PR:7069, 5 commits, 29 files changed)
     
3. dcadec:
   • Don't force 2.0 downmix with KEEP_DMIX_2CH flag alone. (bc08f9ef)
     
   • Add a test suite. (37d8e689)
     
4. newclock4:
   • New commits in this build:
     • squash: shadertoy: Fix include file path (ffeb97af)
       
     • [omxplayer] Make unsupported when ac3transcode is enabled (8b322831)
       
5. kernel 4.0.y:
   • New commits in this build:
     • bcm2835-sdhost: Error handling fix, and code clarification (63c657c6)
       
     • bcm2835-sdhost: Adding overclocking option (0dee18d8)
       
     • bcm2835-mmc: Adding overclocking option (ea47dbff)
       
     • dmaengine: bcm2708: set residue_granularity field (22374422)
       
     • Merge pull request #965 from HiassofT/dmafix-4.0 (6fc1a8cf)
       
     • BCM2708_DT: Adding starter Compute Module DTS files (125160bc)
       
     • squash: Fix up the mmc overlay (36080081)