[sunnyhero]

I am started having some issues from yesterday on pi2... when ever i am trying to install Milhouse new test build the openelec dev update addon showing invalid custom source url. I am trying to update form build #0902 to # 0911'
i never ever had this issue before and always had able to update.How this can be fixed?
Thanks in advance

Go into the add-on settings and disable the custom source.

Did the trick.....thank you Sir...

[Milhouse]

Running "bcmstat.sh -cxgpd10" during a movie might help confirm if there is a leak, either of GPU memory or RAM - keep an eye on the "GPUMem Free" and "Memory Free/Used" columns.

I've updated bcmstat.sh with a "D" option to show GPU (reloc) and ARM available memory deltas. This will be in the next build (or grab the latest version from github).

ASS subtitles are known to leak memory, but interestingly GPU memory seems to be leaking too with ASS subs. The GPU is losing 1,048,576 bytes whenever a multi-line (eg. 2 line) subtitle is shown, or it could be coincidence that the chunk of memory being allocated always happens whenever a multi-line sub is displayed - perhaps it's the length of the subtitle that triggers the leak (with multi-line subs typically being longer than single lines). Small ARM memory allocations are more or less constant, with no obvious correlation between single and multi-line subs.

Edit: The GPU memory leak is real in #0912 - at <10MB reloc available the subtitles are shown as blocks, and after ending playback the GPU memory isn't freed with textures (eg. bubbles background) no longer displayed. In #0907 with either mmal or omx the same 1,048,576 block is being allocated but is paired with a corresponding free, so effectively no memory loss. With build #0908+ there are only allocates and no frees, resulting in the GPU leak.

[bagofcrap24]

I believe there might be memory leaks and causing corruption of the fonts.

Running "bcmstat.sh -cxgpd10" during a movie might help confirm if there is a leak, either of GPU memory or RAM - keep an eye on the "GPUMem Free" and "Memory Free/Used" columns.

I'm also seeing similar breakage.
Subtitles have turned into a solid white box with black shadow and OSD does not display (keeps flashing white bars)
I have left the command above running and can confirm GPU Memory runs down to 0. it went from full almost full 384MB to 0 over the course of 5x anime episodes.
These use ASS subtitles which are known to leak memory. My Pi reboots daily on a cron job and I have never got to the point of Out of Memory issues even while watching 10-20 anime episodes (using ASS) in a day.
currently Im getting between 4-5 epioses before running out of GPU memory.

Here is the bcmstat.sh -cxgpd10 output
http://pastebin.com/fxLpQrzm

[Milhouse]

New OpenELEC Jarvis build #0913: RPi / RPi2
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 4.1.6 #1 Sun Sep 13 21:48:08 BST 2015 armv6l GNU/Linux

# vcgencmd version
Sep  9 2015 23:05:32
Copyright (c) 2012 Broadcom
version de72f07669414925f3fde745fb860bc5d4d193d8 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150913214719-#0913-g43d5606 [Build #0913]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (43d56068, changelog) and tip of XBMC master (1007adfb, changelog) with the following modifications:

• Includes newclock5 patches
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.1.y_rebase
  
• 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 (2a9186e3, ahead +34)
  
• Includes latest kodi-platform master (15edaf78)
  
• Includes latest libcec master (e8506b3d, ahead +29)
  
• Includes latest libnfs master (e453431d, ahead +43)
  
• Includes latest platform master (feafe68e, ahead +4)
  
• Includes latest addons: adsp.basic (da6ee5dd), adsp.biquad.filters (d940a0d1, +1), adsp.freesurround (0bc31e26, +1), asplib (ab13a4fa, +26), pvr.argustv (52a06d00), pvr.demo (039972ea), pvr.dvblink (79cc2d3c), pvr.dvbviewer (2af87049), pvr.filmon (8c444dc5), pvr.hts (d2763613), pvr.iptvsimple (14e2d589), pvr.mediaportal.tvserver (4e4b0f4e), pvr.mythtv (01147ef0, +50), pvr.nextpvr (c09bc2ab), pvr.njoy (91fdbd98), pvr.pctv (d00d5f8d), pvr.stalker (36fec36f), pvr.vbox (5273f25f), pvr.vdr.vnsi (73de793a), pvr.vuplus (11529b2e), pvr.wmc (2974ec38)
  
• Exclude kodi-999.99-IMX-increase-render-buffers.patch: Conflict with newclock5
  
• Exclude linux-999.20-mt7601u-support.patch: Reverted as patching order conflicts with rpi-4.1.y commits - continue using rpi-4.1.y equivalent
  
• Include e85044c6: mesa: Bump to 10.6.6 (add r8 and GR88 transfer methods)
  
• Include f2932a88: VAAPI: Bump driver and lib to 1.6.1 (enable EGL)
  
• Include 6d895e39: ffmpeg: Add hevc fix
  
• Include 65305aa7: mesa: Bump to 11.0.0 (del r8 and GR88 transfer methods)
  
• Include 5d756bf1b7eb2ca5163aaf7034cf850b18f5ff1a...stefansaraev: Kodi 16 updates
  
• Include patch: Add kernel SDIO support
  
• Include patch: Fix for PR:113 (libcec)
  
• Include patch: Fix x86 Get() references
  
• Include patch: Add ffmpeg dependency and includes for HEVC optimisations
  
• Include patch: Add experimental splash video
  
• Include patch: Enable pvr addons, disable PVR updates
  
• Include patch: Add RapidJSON package
  
• Include patch: Enable RapidJSON, drop YASL
  
• Include patch: kodi: Add patch to allow resolution switch for e.g. 4k files v3
  
• Include PR:125: Fix for holding buttons on remotes of Philips TVs (libcec)
  
• Include PR:4266: [systemd] update to systemd-224
  
• Include PR:4284: [Python] update to 2.7.10
  
• Include PR:4286: remove unused python stuff
  
• Include PR:7783: [binary addons] use TARGET_LINKER_FILE_NAME as library filename
  
• Include PR:8008: JSON: replace YAJL with RapidJSON
  
• Revert d0f7dba3: Reason: Not bumping mesa 10.6.7 yet
  
• Revert 06e44c38: Reason: mesa 10.6.7 makes a mistake when reverting an i965 patch
  
• Revert patch: #Fix xcode after videoplayer before PR8008
  
• Revert PR:7885: [binary addons] fix android by using TARGET_LINKER_FILE_NAME instead of TARGET_FILE_NAME
  

Build Highlights:

1. Kodi updates
   
2. Replace YAJL with RapidJSON
   
3. Latest HEVC/4K x86 updates from @fritsch
   

Build Details:

1. XBMC:
   • [pvr] Sort included files alphabetical (PR:7263, 1 commit, 56 files changed)
     
   • [pictures] minor settings cleanup (PR:7992, 2 commits, 15 files changed)
     
   • remove zip operation log spam (PR:8041, 1 commit, 1 file changed)
     
   • Unify music library and files view (PR:8011, 25 commits, 20 files changed)
     
   • ffmpeg: Bump to 2.8.0-Jarvis-alpha3-HEVC (PR:8035, 1 commit, 1 file changed)
     
2. Additional commits/pull requests/changes not yet merged upstream:
   • Added: 65305aa7: mesa: Bump to 11.0.0 (del r8 and GR88 transfer methods)
     
   • Added: patch: kodi: Add patch to allow resolution switch for e.g. 4k files v3
     
   • Added: patch: Add RapidJSON package
     
   • Added: patch: Enable RapidJSON, drop YASL
     
   • Added: PR:8008: JSON: replace YAJL with RapidJSON
     
   • Reverted: patch: #Fix xcode after videoplayer before PR8008
     

[Milhouse]

Here is the bcmstat.sh -cxgpd10 output
http://pastebin.com/fxLpQrzm

Yes, that's what I'm seeing since #0908. With v0.3.3 of bcmstat.sh you should also see the GPU memory leaking in 1MB allocations by enabling the "D" option (a widescreen monitor helps to see it all on one line - or drop the "p"/"x" options).

(I've just pushed v0.3.4 which will include both GPU and ARM stats when using only the D option, negating the requirement for g and x options resulting in a more compact display)

Question: bcmstat.sh is reporting your sdram_freq @ 400MHz (default on Pi2 is 450MHz) - have you applied the default Pi1 sdram_freq of 400MHz on your Pi2? Or is this a detection error in bcmstat.sh, can you paste your config.txt?

[popcornmix]

Okay, for the gpu mem leak. Are subs essential? Does an external subtitle file leak whatever video it is played with?
If so, can someone upload a sub file that is known to leak.

Ideally one that leaks quicky (I wonder if the sub can be edited to just contain repeated multi-line subs if that is what causes the probem).

Once gpu mem gets low, does a "systemctl restart kodi" recover the gpu mem, or does it require a reboot?
If gpu memory doesn't recover, then I'd be interested in output of "vcdbg reloc" after a "systemctl stop kodi" to see the names of the leaked items.

[Milhouse]

I'm only seeing it with external ASS so far - but then I don't have any muxed ASS files to test with as all my MKVs are muxed with SRT or non-ASS subs (PGS etc.). With muxed subs I'm not seeing any leakage so far. I'll try muxing my test ASS file with a video and see what happens.

The ASS file I'm testing with is here - it's just a random file someone posted a while back when first reporting the leak with ASS. Drop it alongside any video and play it with subs enabled and I'm pretty sure you'll see leakage of both GPU and ARM memory. This file will leak quite quickly - you'll see numerous 1,048,576 GPU allocations in the first few minutes, and it's possible to exhaust 320MB of GPU mem in about an hour or so with this subtitle file when playing an SD video.

All the GPU memory is returned when Kodi is restarted (doesn't require a Pi reboot).

[Milhouse]

Same 1,048,576 allocations without frees when playing an MKV with muxed ASS sub.

I've now tested another MKV video file with embedded PGS subs, and that too seems to be allocating 1,048,576 bytes of GPU memory without any corresponding free, so this isn't ASS specific.

An MKV with embedded VOBSUB subtitle also has this problem, but is leaking 1,048,576 bytes of GPU memory at a much slower rate than PGS/ASS.

An MKV with SRT subtitles also has this1,048,576 GPU leak problem, again at a much slower rate than PGS/ASS (ie. fairly infrequent, but it's there).

[Milhouse]

Here's the output of "bcmstast,sh Dd1" (v0.3.4) when playing an SD video with the test ASS file (external): http://pastebin.com/raw.php?i=GNDj7eq9

Playback starts at 12:18:29 and appears to leak 10-11MB of GPU memory during the first 2 minutes.

[grayback]

Hello,

I'm using testbuilds in order to test my 3D MVC MKV and I have some problems with the PGS subtitles. I have an LG TV with passive 3D and sometimes I have only the half of the subtitle on the screen.

Here is a screenshot in 3D with framepacked enabled :
http://i.imgur.com/M9Cy3r0.jpg

Here is a screenshot in 2D :
http://i.imgur.com/oKSuAdw.jpg

Here is a screenshot in 2D with VLC : (the subtitle is complete)
http://i.imgur.com/QfbIUAb.jpg

Here is a screenshot of the extract from the sup file :
http://i.imgur.com/96airki.png

I suspect a problem with the resolution of the subtitle, because only the large ones are affected.
I made a test to convert PGS subtitle to SUB/IDX but I have the same problem.
Do you have an idea of the problem?

Have a good week-end

I ran into similar but not the same problem with PGS subtitles, not with 3D videos but my own Bluray x264 2D rip.

It started from build #0908, both build #0907 and v5.95.5 didn't exhibit that PGS subtitle problem. It usually won't happen during the first half hour of playback. I guess it depends on how many dialogue (or subtitles) needs to be displayed. When the problem happens, the area that subtitles supposed to be displayed are filled with black, video and audio kept going smoothly though. Once the 'Pause' button was pressed, the video info will be flashing. When 'STOP' button was pressed and returned to the menu, all characters (Confluence skin with Arial font) except file size on the menu were a mess (not readable) and needs to reboot.

I believe there might be memory leaks and causing corruption of the fonts.

Hello,
I think, my PGS subtitle problem is not due to memory leaks, because it's always the same line and the next subtitles are good. Only the large ones make problem.
What can I do to identify the problem?

[Milhouse]

@popcornmix - I've uploaded a script here which will generate an ASS file based on various parameters - as written it will generate an ASS file (test.ass) that displays a 3 line subtitle twice a second. With the default 3-line ASS file generated by this script, I'm leaking 1,048,576 to 2,097,152 bytes of GPU memory every second - GPU memory is exhausted within 4 minutes (gpu_mem=320).

Edit: Script updated to allow sub-second intervals - GPU leaks even faster.

[Milhouse]

Also I lied - once the GPU memory is leaked, restarting Kodi does not always recover the GPU memory and the Pi needs a reboot. However sometimes it doesn't need a reboot to recover the memory, and a Kodi restart is sufficient. Weird.

[popcornmix]

Thanks for subtitle script.
I've updated newclock4 and confirmed the leak doesn't occur. The only difference between newclock4 and newclock5 are the VideoPlayer commits, so it is one of those. I'll see if I can narrow further.

[popcornmix]

I think, my PGS subtitle problem is not due to memory leaks, because it's always the same line and the next subtitles are good. Only the large ones make problem.
What can I do to identify the problem?

Can you test on another kodi platform? E.g. a nightly build on windows or linux. Would be useful to know if it's an upstream kodi issue.

[wchick132]

Hello,
I think, my PGS subtitle problem is not due to memory leaks, because it's always the same line and the next subtitles are good. Only the large ones make problem.
What can I do to identify the problem?

Test your video with build #0907 or earlier, if it doesn't happen then probably it's your PGS subtitle.