•   
  • 1
  • 74
  • 75
  • 76(current)
  • 77
  • 78
  • 168
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
(2015-09-13, 01:58)Leopold Wrote:
(2015-09-12, 18:47)sunnyhero Wrote: 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...
(2015-09-13, 18:47)Milhouse Wrote: 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.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-09-13, 18:47)Milhouse Wrote:
(2015-09-13, 18:01)wchick132 Wrote: 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

Image
Image
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: 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
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-09-13, 22:20)bagofcrap24 Wrote: 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?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
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.
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).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
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).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
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.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-09-13, 18:01)wchick132 Wrote:
(2015-09-11, 19:40)grayback Wrote: 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?
@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.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
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.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
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.
(2015-09-14, 13:47)grayback Wrote: 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.
(2015-09-14, 13:47)grayback Wrote: 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.
  •   
  • 1
  • 74
  • 75
  • 76(current)
  • 77
  • 78
  • 168
  •   
  Thread Closed
 
Thread Rating:
  • 10 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)510