Login at Kodi Home

mylle · 2014-09-29, 08:27

Hi,

Tried out build 0927 last night to see how far the PVR integration has come and how it performs on the PI. I was very pleasantly surprised to see how well it ran against my Mediaportal TV-server. channel switching times were acceptable and picture quality was great. Still one big showstopper though. Audio and video drift is bad and after 15 minutes of watching tv its way of Sad

Is this a know issue. Am i doing something wrong?

Regards
Jacob

**popcornmix** · 2014-09-29, 14:10

(2014-09-29, 08:27)mylle Wrote: Tried out build 0927 last night to see how far the PVR integration has come and how it performs on the PI. I was very pleasantly surprised to see how well it ran against my Mediaportal TV-server. channel switching times were acceptable and picture quality was great. Still one big showstopper though. Audio and video drift is bad and after 15 minutes of watching tv its way of

Are you getting visible errors (e.g. due to low signal strength). I think there may be an issue if a corrupt packet comes through with an invalid timestamp which throws off the timing, but it's something that's hard to reproduce (it only seems to affect live TV - a recording of the same channel seems to have perfect sync).

How does it behave if you disable omxplayer acceleration in settings/video/acceleration?

mylle · 2014-09-29, 14:31

Hi Popcornmix,

Thanks for your reply.

I will look at it again today and see if there are any visible errors. I also use a mediaportal client in the main tv room and I have no issues here. I will also try the omx acceleration suggestion.

/Jacob

Jönke · 2014-09-29, 21:54

Same here with tvheadend and audioclock as sync method! But solved by choosing videoclock and drop/dupe.

**popcornmix** · 2014-09-29, 22:11

(2014-09-29, 21:54)Jönke Wrote: Same here with tvheadend and audioclock as sync method! But solved by choosing videoclock and drop/dupe.

Interesting. I would like to reproduce this - I don't suppose you ever get the out of sync behaviour from a file?

Does it fail with SD TV? Can you provoke the probem quickly?
I do have a patch that allows dumping the raw data but it's no feasible for HD data rates, but would possibly work for SD.

Jönke · 2014-09-29, 22:44

Yes it fails on Sd live tv , havent checked recordings. Will do that tomorrow

**popcornmix** · 2014-09-29, 23:33

(2014-09-29, 22:44)Jönke Wrote: Yes it fails on Sd live tv , havent checked recordings. Will do that tomorrow

If you can get me a sample recording that goes out of sync with audioclock and stays in sync with videoclock, then there's a good chance I can fix this.

mylle · 2014-09-30, 07:30

Tested a litle more last night. It change resolution from 1280x720 60hz to 1280x720 50hz which seems to have made a difference. A test on the same channel for 2 hours did not drift. This was just on a random HD channel that i picked. That particular channel seems to work fine whereas 2 other channel i tested yesterdag (also HD) have problems even getting started without video and audio being out of sync right from the start.

pootler · (This post was last modified: 2014-09-30, 21:23 by pootler.)

hello mylle and Jonke,

I am an extensive user of live tv.
Its interesting to see your comments.
I had been suffering a lot from audio/video sync issues.
My Pi is on 24/7, and quite often a TV channel is left to run all night.
I find this a great way of checking sync, by looking in the morning.
I do find that a lot of my sync issues ( as explained by popcorn mix) can come from small 'micro' disruptions in the reception which if they continue, can add an increasing amount of drift which eventually becomes noticeable.
I am very sensitive to sync issues, so it doesn't have to drift much Smile

I have noticed less of this in the more recent builds, in fact I haven't seen it all recently.

I am based in UK and use two hauppauge dvb-t tuners ( one single, one dual )
I use VDR and VNSI, and all the PVR stuff is on the one Pi.

I will keep an eye on this thread in case I can contribute.

by the way, I don't use any of the ' sync audio' options at all

cheers

pootler

Jönke · 2014-09-30, 21:32

(2014-09-29, 23:33)popcornmix Wrote:
(2014-09-29, 22:44)Jönke Wrote: Yes it fails on Sd live tv , havent checked recordings. Will do that tomorrow

If you can get me a sample recording that goes out of sync with audioclock and stays in sync with videoclock, then there's a good chance I can fix this.

Recordings dosen't seem to have sync issues, not in my quick test anyway.
What can i do moore to help you solve this ? If It is audio clock who is the best sync method?
(I have always used video clock before)

**popcornmix** · 2014-09-30, 21:51

(2014-09-30, 21:32)Jönke Wrote: Recordings dosen't seem to have sync issues, not in my quick test anyway.
What can i do moore to help you solve this ? If It is audio clock who is the best sync method?
(I have always used video clock before)

I've added a patch that allows packets to be dumped out for later debugging.
With the next milhouse build, enabled "Dump video frames to debug file" and "Dump audio frames to debug file" in the debugging settings.

This should produce files in .xbmc/temp called video.dat and audio.dat.

Ideally turn that on, wait for audio sync error and upload the files. However I'm not sure if dumping the data will cause a performance issue. Best to test it with an SD channel.

pootler · (This post was last modified: 2014-09-30, 23:42 by pootler.)

(2014-09-30, 21:51)popcornmix Wrote:
(2014-09-30, 21:32)Jönke Wrote: Recordings dosen't seem to have sync issues, not in my quick test anyway.
What can i do moore to help you solve this ? If It is audio clock who is the best sync method?
(I have always used video clock before)

I've added a patch that allows packets to be dumped out for later debugging.
With the next milhouse build, enabled "Dump video frames to debug file" and "Dump audio frames to debug file" in the debugging settings.

This should produce files in .xbmc/temp called video.dat and audio.dat.

Ideally turn that on, wait for audio sync error and upload the files. However I'm not sure if dumping the data will cause a performance issue. Best to test it with an SD channel.

TV recordings are in sync - but- in the current builds, if I search through a tv recording, then when I resume play, the audio/video can be out by a number of seconds?
This also applies to searching through any videos/ movies etc, in the latest builds for me.
Temp fix is to turn off omxplayer accell, but it is not ideal, as it introduces other glitches.
openelec 4.2 official does not seem to have problem - but it is slower though!

pootler

Milhouse · 2014-09-30, 23:54

(2014-09-30, 21:51)popcornmix Wrote: I've added a patch that allows packets to be dumped out for later debugging.
With the next milhouse build, enabled "Dump video frames to debug file" and "Dump audio frames to debug file" in the debugging settings.

This should produce files in .xbmc/temp called video.dat and audio.dat.

Ideally turn that on, wait for audio sync error and upload the files. However I'm not sure if dumping the data will cause a performance issue. Best to test it with an SD channel.

This is there now, with build #0930.

gendo · 2014-10-02, 09:11

posted my samples and findings here http://forum.xbmc.org/showthread.php?tid...pid1805635