fritsch, please don't confound me with somebody else again :-)
the sync problems seems to be introduced after r21577. r21577 don't show the issue at all. later releases have sync problems. with the same settings. i have my own xorg.conf in .config only for tearfree. nothing more.
the 25fps problems discussed here don't seems to be a problem for me. as i have written, i need to enable tearfree because of chromium. vsync is also always on.
sync problems seems to be only exists with audio passthrough. mp2 audio has no sync problems for me.
Quote:xorg.conf in .config only for tearfree. nothing more.
This was proven to exactly cause those sync issues - as we cannot trust the vblank anymore. It is reverted (*) in the latest build I uploaded that morning.
* I was convinced by the developer that this would "not cause" any issues - while still blocking like a vblank aware setup ... the field test (pre latest build) has heavily shown the issues.
but why r21577 don't have this issue? even with tearfree on?
no it don't.
Quote:OpenELEC (unofficial) Version: devel-20151202082538-r21587-g8581404
OpenELEC git: 8581404bbf15a91d17d17e6fa7b407ce70970d39
OpenELEC:~ # cat /var/log/Xorg.0.log | grep TearFree
[1644758.642] (**) intel(0): Option "TearFree" "true"
[1644758.645] (**) intel(0): TearFree enabled
but it works with:
Quote:OpenELEC (unofficial) Version: devel-20151118073930-r21577-g3a1af3a
OpenELEC git: 3a1af3a231316402ceaa7ae1b38d0f0cc41f4f3a
OpenELEC:~ # cat /var/log/Xorg.0.log | grep TearFree
[1646656.747] (**) intel(0): Option "TearFree" "true"
[1646656.751] (**) intel(0): TearFree enabled
as i said: there is something else changed. TearFree might be a trigger for this issue but i doubt the root source.
i have also seen, if i set cacheinvideoplayer to false in advancedsettings the latest release will crash kodi very likely.
That's your personal TearFree setting then ... cause I shipped it only once.
The change that might cause (kodi wise) is:
https://github.com/FernetMenta/xbmc/comm...4ca9c43692
Please try _without_ TearFree (your self set Tearfree). It only happens with passthrough? or also without passthrough?
The above commit changes the delay estimation for the passthrough case and was the last one that was added.
yes that is true. my own xorg.conf because of tearings with chromium browser this setting is necessary for me.
Quote:OpenELEC (unofficial) Version: devel-20151202082538-r21587-g8581404
OpenELEC git: 8581404bbf15a91d17d17e6fa7b407ce70970d39
OpenELEC:~ # cat /var/log/Xorg.0.log | grep TearFree
[1648564.325] (==) intel(0): TearFree disabled
sync problem still exists.
pcm or mp2 audio seems always fine. only with passthrough. very much with 2.0 dolby (>1000 ms) and hard to notice with 5.1. In all cases audio is out of sync if transport stream has some picture errors.
Okay - that makes sense - thx. then the passthrough delay estimation has a little bug somewhere.
I too am having audio sync issues for anything after the devel-20151118073930-r21577-g3a1af3a build while using passthrough. For me, it is even noticeable for 5.1 audio streams. I will test today's build now.
Today's testbuild won't repair the passthrough sync issues - they just repair general audio / video sync issue introduced by testing intel's "TearFree" option ...
since build OpenELEC-Generic.x86_64-6.0-devel-20151202120423-r21589-gcf0c417.tar
i'm having a lot of handshake problem (black screen, hdmi lost)
my setup is: chromebox>avr>tv
avr is in standby
i will post a debug log asap (my son goes to bed)
edit:maybe i found using sync to playback function problem solved
Not a single change in that regard ...
(2015-12-02, 21:31)Roby77 Wrote: [ -> ]since build OpenELEC-Generic.x86_64-6.0-devel-20151202120423-r21589-gcf0c417.tar
i'm having a lot of handshake problem (black screen, hdmi lost)
my setup is: chromebox>avr>tv
avr is in standby
i will post a debug log asap (my son goes to bed)
edit:maybe i found using sync to playback function problem solved
I am experiencing similar issues on OpenELEC-Generic.x86_64-6.0-devel-20151128110533-r21582-g0c46ef7. When waking my AVR and display from standby it sometimes takes approximately 60 seconds for anything to register on the display. I just started using these testbuilds so I can't comment if this issues existed in older builds but I will try to replicate the issue and post some logs tonight.
Quote:OpenELEC-Generic.x86_64-6.0-devel-20151128110533
This version's drivers are run by some thousand chromebox users ... not a single complaint concerning AVR/display/on/off until now. Btw. suspend / resume is not supported - it's a kernel thing and kodi has minimalistic support for that.
(2015-12-02, 21:32)fritsch Wrote: [ -> ]Not a single change in that regard ...
thank you i will try resetting avr cpu