Opened 13 months ago

Last modified 5 months ago

#15039 new Bugs

Video tearing on MacMini running OS X 10.9.2

Reported by: Ecco Owned by: davilla
Priority: 4 - Normal Milestone: Future / Pending
Component: Mac OS X specific feature Version: 13.0 "Gotham" Alpha10
Severity: Normal Keywords:
Cc: Montellese, Blocked By:
Blocking: Platform: All


When using XBMC 13.0 beta 2 on a MacMini running OS X 10.9.2, there is a lot of tearing in any video I play. It looks a lot like the vsync isn't actually enabled, even if the settings says so. It is very annoying. The issue wasn't present on the same machine using XBMC v12 on OS X 10.8.

I attached a debug log, and a system profile of said machine.

This problem has also been reported by other users here : It seems like this happens on all machines using the nVidia 320m chip.

Attachments (3)

xbmc.log (1.5 MB) - added by Ecco 13 months ago.
XBMC debug log
system_profile.txt (2.1 MB) - added by Ecco 13 months ago.
System profile
guisettings.xml (32.4 KB) - added by Ecco 13 months ago.

Change History (13)

Changed 13 months ago by Ecco

XBMC debug log

Changed 13 months ago by Ecco

System profile

comment:1 Changed 13 months ago by jmarshall

Mind adding your guisettings.xml to the ticket? In particular we're interested in the videoscreen.vsync setting.

comment:2 Changed 13 months ago by Ecco

Sure. Note that I reinstalled XBMC and deleted its settings folder (~/Library/Application\ Support/XBMC) before doing my test. So hopefully "guisettings.xml" should be the default one. Here it is anyway.

A quick grep seems to show that the value you're asking for is 3 : <vsync>3</vsync>

Last edited 13 months ago by Ecco (previous) (diff)

Changed 13 months ago by Ecco

comment:3 Changed 13 months ago by jmarshall

Ok, make sure XBMC is not loaded, change that to 2, load XBMC, and try again.

comment:4 Changed 13 months ago by Ecco

Well, very good news: that seems to have fixed it! I just watched ~10 minutes of various videos, and so far, so good.

I don't know what is the proper fix now, so if you need any more testing, just let me know.

Meanwhile, I'm posting on the forum to ask if it fixes things for other people who reported the issue.

Thanks a lot!

comment:5 Changed 13 months ago by jmarshall

Excellent - thanks for testing.

@Montellese any ideas? I have a PR switching the default to the correct value of 2 - I don't think we can do more than that (I assume that the setting is validated then dropped to the minimum on load when it's set to 3)?

comment:6 Changed 13 months ago by jmarshall

  • Cc Montellese added

comment:7 Changed 13 months ago by Montellese

@jmarshall: I have no clue about how the vsync setting is interpreted. It defaults to 3 but e.g. on win32 it defaults to 2. I'm sure there is someone else who can elaborate on which default makes most sense for which platform and then we can overwrite the default on a per-platform basis.

But remember that changing the default value in the settings XML doesn't change the value of the setting in an existing installation because we can't know if the currently stored value has been manually set by the user or is still the default value.

comment:8 Changed 13 months ago by davilla

drawin should be sync, same for android. I suspect that it does not really matter under android as GLES is a layer under Android windowing and it will update the frame when it wants.

comment:9 Changed 13 months ago by davilla

Oh, for arm embedded linux, it should be sync too as there is no 'window manager' behind it.

comment:10 Changed 5 months ago by Martijn

could you test if this still happens with latest nightly build and see if this still happens (remember to backup your userdata folder)?

we need to know if it's still happening with current code so we could possibly fix it for next release.

Note: See TracTickets for help on using tickets.