Kodi Community Forum

(2015-05-24, 04:35)nickr Wrote: [ -> ]

(2015-05-24, 04:22)kisas Wrote: [ -> ]anyone can use Raspberry Pi2 as an airplay target?

Please, you only asked your question a couple of hours ago.

My apology, I saw more people posted here.


I have been working on this issue for 3 weeks. But I haven't figured it out. Tried many versions. Very frustrated. I hope at least I should know if anyone has successfully used airplay on their Raspberry Pi.

(2015-05-24, 04:37)wchick132 Wrote: [ -> ]

(2015-05-24, 04:22)kisas Wrote: [ -> ]anyone can use Raspberry Pi2 as an airplay target?

Yes, test only with iPad 3 with iOS 6, YouTube App is not working despite it shows AirPlay device is available. Also screen mirroring is not possible.

I guess the airplay codes on Raspberry XBMC is quite old. Hope someone can update it soon.

using #0523c , overclocked using kodi's recommended modest settings.

sample vid: https://drive.google.com/file/d/0B_5gfDC...sp=sharing

encode settings: 720p, constant quality 20, constant framerate, fast decode checked.

playback quality: video still stutters..though parts of the sample clip played a lot smoother compared to earlier builds..so there are improvements..

Running #517 on my v2, I left it showing the EPG with debug logging enabled for a day, maybe a bit more and when I looked at it this morning, it was locked up and unresponsive, although the log still seems to be recognising the remote keypresses.

There's a lot of errors towards the end of the log, from around 22:03 last night, referring to

Tvheadend HTSP Client: pvr.hts - failed to write (Invalid argument)
Tvheadend HTSP Client: pvr.hts - failed to transmit

so maybe that's what brought it down, although perhaps Kodi could be made more robust so that a problem with TvH doesn't crash the whole thing. If they only fault is in TvH though, please let me know and I'll report it in the appropriate place.

The log came to 177MB, so I've zipped it down to 10MB and uploaded it here: https://drive.google.com/file/d/0B1fDI89...sp=sharing

HEVC decoding is better in #523c.

some previous videos that stutters are now smooth. Some continue to stutters but less if the bitrate is too high ( CRF < 22 for example ) CRF 23 seems to be the limit for my samples. I haven't try preset > medium, psy-rd and others settings yet but will take a look latter.

The cpu usage is also really lower with this version. When samples with previous version have cpu usage between 80 and 90% now it's rather between 65 and 80%.

I also see videos that stutters but have cpu usage under 85%. Perhaps some bottlenecks in the VPU or GPU ?

(2015-05-24, 05:49)kisas Wrote: [ -> ]

(2015-05-24, 04:35)nickr Wrote: [ -> ]

(2015-05-24, 04:22)kisas Wrote: [ -> ]anyone can use Raspberry Pi2 as an airplay target?

Please, you only asked your question a couple of hours ago.

My apology, I saw more people posted here.


I have been working on this issue for 3 weeks. But I haven't figured it out. Tried many versions. Very frustrated. I hope at least I should know if anyone has successfully used airplay on their Raspberry Pi.

Video doesn't work which has been known for a long time.
I can successfully send music to the pi2 via airplay from;
My nexus 5 (android 5.1.1) using the allstream app.
A relatives iPhone 6 (iOS 8) using the os' built in airplay

So it seems the issue is more on your end.

(2015-05-24, 05:54)kisas Wrote: [ -> ]I guess the airplay codes on Raspberry XBMC is quite old. Hope someone can update it soon.

These build use top-of-tree code. There is no newer airplay code.
Airplay should support music and videos from non-DRM sources.
This means no Youtube app (but youtube from safari is okay), and no mirroring.

(2015-05-24, 08:39)doveman2 Wrote: [ -> ]There's a lot of errors towards the end of the log, from around 22:03 last night, referring to

Tvheadend HTSP Client: pvr.hts - failed to write (Invalid argument)
Tvheadend HTSP Client: pvr.hts - failed to transmit

You'll need to run this past the tvheadend maintainer.

(2015-05-24, 04:57)Milhouse Wrote: [ -> ]See bcmstat results - this is a Pi2 with gpu_mem=320. On the first play of Sintel_1080p_27qp_24fps_1aud_9subs.mkv the GPU mem drops to 191MB but returns to 249MB when playback is stopped. When playback is started a second time, GPU mem now drops to 180MB. When playback is stopped a second time at 02:38:34, the reloc memory is reported as 661MB... This isn't reproducible 100% of the time, but I have seen it happen 3 or 4 times so far while testing #0523c.

Not caught it so far in my dev environment (after 10 start/stops).
If you get this state again, can you report output of:
Run it twice to try to get a consistent result.

Also stop kodi and run those commands again. I'd like to know if the heap is permanently broken.

Try this hevc sample:
https://docs.google.com/uc?id=0B9YhsPfRT...t=download

I get some stutters and video artifacts (at the end of playback).

Encoded with ffmpeg-2.6.3 + libx265-1.6, crf=26, other settings at default.

No overclock.

(2015-05-24, 18:46)popcornmix Wrote: [ -> ]If you get this state again, can you report output of:

Code:

vcgencmd cache_flush && vcdbg reloc

Run it twice to try to get a consistent result.

Also stop kodi and run those commands again. I'd like to know if the heap is permanently broken.

I've run some more tests. It's not easy to reproduce the memory problem, but it is fairly easy to reproduce some sort of odd behaviour. Playing Sintel 720p for a few seconds - ie. stopping playback at 45 seconds when the fight starts - followed by Sintel 1080p for another 45 seconds, and possibly repeating playback of Sintel 1080p a second time will usually provoke some kind of problem - either unrealistic GPU mem > 600MB, a complete system freeze, or briefly frozen playback followed by very severe visual artefacts (blue/green pixelation). Quite often a system crash may occur when stopping playback once the pixelation is visible, either when stopping the video in which the pixelation first appeared, or a subsequent video.

If you see no problem after playing Sintel 1080p the first time (for 45 seconds), you'll almost certainly have problems playing it a subsequent time (either crash, or visual artefacts). Try Sintel 720p, Sintel 1080, Sintel 720, Sintel 1080 in that order (playing each for 10 seconds) and you should eventually experience abnormal behaviour.

Here's bcmstat showing GPU Mem at 705MB (@18:59:49) after alternating playback of Sintel 720p/1080p then finally terminating playback of Sintel 1080p at which point the GPU memory becomes abnormal.

These are the corresponding vcgencmd cache_flush && vcdbg reloc once the memory became abnormal, run three times: #1, #2, and #3 (in that order). The kodi.log - sorry, not debug - is here (note that the time in kodi is BST, or UTC+1, while the system time shown in bcmstat is UTC).

I then shut down kodi, and captured three more vcdbg reloc: #4, #5 and #6. bcmstat continued to show abnormal GPU memory after shutting down kodi.bin.

The above tests were performed with no overlock other than for sdhost, using this config.txt.

These are the two Sintel files I'm testing with:
Sintel 720p: Dropbox, 66MB
Sintel 1080p: Dropbox, 113MB

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


Based on tip of OpenELEC master (4c129658, changelog) and tip of XBMC master (0f1aea5f, 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 (23c84f00, ahead +13)
  
• Includes latest kodi-platform master (33b6390b, ahead +1)
  
• Includes latest libcec master (18555911, ahead +5)
  
• Includes latest libnfs master (7121bc3b, ahead +14)
  
• Includes latest platform master (aafa6e9f)
  
• Includes latest addons: pvr.argustv (cffc8b6b, +1), pvr.demo (9c400e19, +1), pvr.dvblink (7f515436), pvr.dvbviewer (05e76da7, +1), pvr.filmon (8c02f43d), pvr.hts (86eb1cc2, +1), pvr.iptvsimple (191972cf, +1), pvr.mediaportal.tvserver (bcfb46f9, +1), pvr.mythtv (6fb769da, +1), pvr.nextpvr (74168dc9, +1), pvr.njoy (9aa05103, +1), pvr.pctv (804dc37c, +1), pvr.stalker (0d6a5d8b, +1), pvr.vbox (375eab31), pvr.vdr.vnsi (244b893c), pvr.vuplus (cdc1d0e3, +2), pvr.wmc (42fb669d, +1)
  
• Includes commits from shairplay/master, ahead +17 (juhovh)
  
• Exclude kodi-999.20-PR7102.patch: Temporarily revert dcadec settings and use newclock4 version
  
• Exclude kodi-999.21-configure.ac-dont-break-if-dcadec-is-missing-dcadec-.patch: Temporarily revert due to breakage
  
• Include patch: Enable vcsm kernel options for HEVC optimisations
  
• Include patch: Enable the mailbox driver (new kernel options)
  
• 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
  

Build Highlights:

1. Various small changes
   

Build Details:

1. OpenELEC:
   • libfslvpuwrap: update to libfslvpuwrap-1.0.58 (6b8df0b9)
     
   • imx-vpu: update to imx-vpu-5.4.28 (00ee931a)
     
   • firmware-imx: update to firmware-imx-3.14.28-1.0.0 (1d81a9fa)
     
   • udevil: update to udevil-0.4.4 (e7016aed)
     
   • udevil: fix build (ad3fb0cd)
     
   • xf86-video-intel: fix build (32b3cf43)
     
   • gdb: update to gdb-7.9.1 (82fd73ce)
     
   • glib: update to glib-2.44.1 (acbe0685)
     
   • dbus: update to dbus-1.8.18 (4c129658)
     
2. XBMC:
   • FIX: [audiotrack] proper detection of supported sample rates (PR:7131, 1 commit, 2 files changed)
     
   • always use the DialogOK with the textbox input instead of separate lines (PR:7112, 1 commit, 29 files changed)
     
   • [win32] Fix crash after 8e1f62cc1b80918d723edc40e7b2a903cbef96e2 due … (PR:7181, 1 commit, 1 file changed)
     
   • Fixed makefile ARCH install bug (PR:6942, 1 commit, 1 file changed)
     
   • [input] drop fallback window configuration for fullscreeninfo dialog (PR:7170, 1 commit, 1 file changed)
     
   • fix kaitoast dialog loading the previous icon instead of the default … (PR:7182, 1 commit, 1 file changed)
     
   • [addons] fix toast dialog showing wrong icon on install errors (PR:7180, 1 commit, 1 file changed)
     
   • [addons] add thumb support for info provider group (PR:7109, 1 commit, 2 files changed)
     
   • [win32][gtest] fixed gtest build that broke with kissfft (PR:7185, 1 commit, 2 files changed)
     
3. libnfs:
   • UTILS: add nfs-cat utility (4b1de15b)
     
   • FUSE: use nfs_stat64() not nfs_stat() (6f272746)
     
   • EXAMPLES: convert remaining nfs_[f]stat to nfs_[f]stat64 (ec3a3afe)
     
   • UTILS: move nfs-cp from examples to utils (eadef4f7)
     
   • UTILS: move nfs-cp from examples to utils (08ea9a31)
     
4. newclock4:
   • New commits in this build:
     • Revert "temp: don't reset codec when running behind" (00dba755)
       
     • [players] Fix for SetPriority calls being ignored (f5353c62)
       
     • [rbp] Only avoid increasing audio thread priority with omxplayer (e20e38dc)
       

Another test with #0524 - I played Sintel 720 for a few seconds, then Sintel 1080 three times for a few seconds each, and the GPU mem free (vcgencmd get_mem reloc) became an impossible 4091MB - bcmstat output. Unfortunately the system totally froze (network connection lost) and it required power cycling.

I now think that running bcmstat.sh is a crucial step required to trigger abnormal behaviour - it seems harder to cause abnormal behaviour when bcmstat is *not* running, although corruption still seems to be occurring as when not running bcmstat.sh, after playing Sintel 720/1080 a few times without any obvious error, trying to run "/usr/bin/vcgencmd get_mem reloc_total" produces the following error:

In fact, it's no longer possible to load any shared library on a system that is in this state:

dmesg is clean.

As a minimal test, the following should be sufficient to see when memory corruption has occurred without running the whole bcmstat.sh:

While running the above code, play Sintel 720p and Sintel 1080 in sequence, for 10-20 seconds each, until the reported reloc amount becomes abnormal.

Interesting. I had caught a corrupt heap with Sintel on OE and I was running bcmstat (but hadn't guessed it might make it more likely). Not reproduced it in debug env, but will try using bcmstat.

(2015-05-24, 14:51)Milhouse Wrote: [ -> ]You'll need to run this past the tvheadend maintainer.

Thanks, I'll do that.