OS X Error compiling and linking video filter shader
#16
(2014-03-20, 16:00)Memphiz Wrote: diff both guisettings.xml
A unified diff is over half a MB due to tons of skin related crap (yes I've tried lots of skins in the last year and it seems they've all left their settings behind...) and when I've tried to reproduce the problem tonight while making a diff I can't reproduce it. Confused

I have a hunch that it may only occur during low memory conditions, perhaps a graphics buffer allocation failure is triggering it. The reason I suspect that is this Mac only has 1GB ram and it has always been very tight for free memory - after launching XBMC there was only ever about 60MB memory free at most even with Frodo, sometimes dipping down to 30MB or less after playing for a while, it's always been like this.

When I used to run Aeon Nox the skin would sometimes malfunction (sub menus disappeared until rebooted) when memory was short for example running another app in the background and it became frequent enough that I abandoned Aeon Nox and eventually settled on Amber.

Well yesterday I discovered that System Update was sitting in the background all the time consuming approximately 250MB of ram at all times. Angry I knew that automatically check for updates was enabled in OS X, but I didn't realise such a memory hogging daemon was sitting in the background all the time to serve that function... so I turned off automatic updates and I now have about 300-350MB of free ram at all times with XMBC running for the first time in over a year.

So a tip to Mac OS users with only 1GB of ram - disable automatic checking for system updates!

Since then I haven't been able to reproduce the glitch, hence suspecting it may be memory related. I'll revert the Software update setting temporarily so that memory is short again and see if I can reproduce it over the next few days.

You would think that virtual memory would prevent an allocation failure but apparently not as Aeon Nox would definitely malfunction when ram was low even though XBMC would otherwise function normally.

Because Amber is such a light skin (probably lighter than even Confluence) that would make sense that the issue doesn't appear with Amber if it has lower memory requirements than the default skin.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#17
Well that video you posted looks like memory defect. I saw this when the ram on my nvidia gpu died. In case your GPU uses shared memory it can also be some damaged RAM cells.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#18
I will run a memory test to rule it out but I don't think it's faulty memory. This machine has run perfectly with no graphical glitches for over a year and still works perfectly in Frodo, and even works perfectly in Beta 2 with more free memory available or when using Amber instead of Confluence. Also no signs of any instability or graphical glitches in any other software.

More likely a bug triggered by running low on memory. It could even be an OS X bug where a video ram allocation is failing rather than a bug in XBMC. (Would a failure to allocate video memory be logged in an XBMC debug log ?) Aeon Nox used to silently break during low memory conditions, I can only assume it tried to allocate video memory to display certain UI elements and those allocations failed so it simply didn't display the missing elements.

Have there been significant changes in rendering at an OS/API level between Frodo and Gotham on Mac OS ? Is more video memory required ? etc. Remember the GMA 950 only allocates 64MB of video ram, which is not much even compared to a Raspberry Pi...

I should have more time over the weekend to try to narrow this down further.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#19
(2014-03-21, 11:07)Memphiz Wrote: Well that video you posted looks like memory defect. I saw this when the ram on my nvidia gpu died. In case your GPU uses shared memory it can also be some damaged RAM cells.
You can rule out faulty ram:

https://dl.dropboxusercontent.com/s/n4lp...LK8dJORR_g

I'll test my low memory theory over the weekend.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#20
(2014-03-21, 11:07)Memphiz Wrote: Well that video you posted looks like memory defect. I saw this when the ram on my nvidia gpu died. In case your GPU uses shared memory it can also be some damaged RAM cells.
Ok a bit of time tonight testing and I've nailed down exactly when and why this glitchy video display occurs. Smile

Now that I know what it is I can also reproduce it in Frodo, even though I never experienced this problem in nearly a year of using Frodo. So the underlying problem is not new to Gotham, however one of the default settings has changed between Frodo and Gotham exposing the issue - Vertical Blank Sync.

In Frodo the default for Vertical Blank Sync is Always. I can't reproduce any graphical glitches under any conditions in either Frodo or Gotham Beta 2 with Vertical Blank Sync always enabled - which is why I haven't seen it until now.

In Gotham Beta 2 the default for Vertical Blank Sync is now Disabled. So when I deleted the XBMC folder to test the filter/scaler error with a "clean" install Vertical Blank Sync was now Disabled and symptoms began appearing. I wasn't seeing the symptoms with my normal XBMC folder because it carried forward my original Frodo default of always enabled...

There's a further complication however - with Vertical Blank Sync disabled, I still ONLY see glitching when the amount of free memory at the time XBMC is launched is low. There is not a hard threshold (or perhaps it depends on how much is swapped to disk, and other more obscure factors in the VM system) but if free ram as reported inside XBMC is less than 60MB I *always* see the problem, if it is between 60MB and 150MB I *sometimes* see the problem, and if there is at least 150MB free I *never* see the problem.

Freeing up memory by killing background memory hogs while XBMC is already running doesn't cure glitching if it is already occurring - so it seems like some memory allocation at launch is failing through lack of ram (maybe lack of vram since its using shared memory ?) and once that allocation fails Vertical Blank Sync Disabled just doesn't work properly until XBMC is exited, sufficient memory is freed up and it is relaunched.

So as I say, this is not something new as Frodo does the exact same thing with the setting disabled, but disabled was never the default until Gotham. It could even be that this issue is a Mac OS bug revolving around the video driver and its use of shared memory on this particular graphics chipset.

So I guess my question is, was there a good reason for the change of default setting to Vertical Blank Sync Disabled - or was it more a case of it seemed a good idea at the time without knowing that on some hardware in low memory conditions it could cause problems ? As a short term fix or workaround is there any chance that the default could go back to always enabled for the final release ?

For what reason would an end user want to disable it, what are the pros and cons ? For gaming where you want maximum frame rate and don't care about a bit of tearing Vsync off makes sense, but I would have thought for video playback you would never want it turned off as we don't want tearing of video playback, and we don't need super high frame rate of the GUI either... so having it always on seems like the most sensible default.

At least I know what it is now, all I have to do is enable vsync and the problem goes away - for me, but I'm thinking about all the other potentially affected people running old Mac's when they do a fresh install of Gotham.

Comments ?

PS sorry to drag this thread a bit off topic, hopefully we can get back to the filter/scaler issue at some point too.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#21
Thanks for the heads up on the vsync default - the reason is due to the way the settings system was redesigned. We'll look into restoring the correct default (it should be always).

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#22
(2014-03-07, 22:54)Memphiz Wrote: Maybe a debug log (wiki) from frodo to compare with - my hackbook is gma950 too (10.6.8 aswell) and doesn't Show that issue ...

Does your Problem happen on lower Screen Resolution too?
Hi Memphiz,

I managed to set up a build environment on the Mac Mini which exhibits this shader error so that I can build XBMC using XCode 3.2.6 on Snow Leopard.

I spent a bit of time over the weekend doing a git bisect to find the commit that introduced this problem, and found that it's this one:

https://github.com/FernetMenta/xbmc/comm...d324cb808d

Code:
commit 1eeee8b4a0732c4ada3fb861c24e17d324cb808d
Author: Rainer Hochecker <[email protected]>
Date:   Mon Dec 9 13:01:38 2013 +0100

    LinuxRendererGL: make sure we have a shader defined
Interesting thing is it looks like a commit that was only intended to be Linux specific, with unforeseen consequences on some Macs.

Hope that helps find it. As I can now compile test builds on the Mac that has this issue if you have any fixes you want me to try I can do so.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply

Logout Mark Read Team Forum Stats Members Help
Error compiling and linking video filter shader0