Reinhard, thansk for you response but;
>> I am having some problem with vdr xine and analogtv plugin.
>>
>> I have a client-server vdr installation based on vdr 1.3.34, xine
>> 0.7.6 plugin, when I select a DVB channel I have no problems but if I
>> select an analog channel (stream generated by analogtv plugin 0.9.37
>> with ivtv 0.4.0 and PVR 150 card) I had some sync problem: here is the
>> xine log:
>>
>> audio jump, diff=-51840
>> audio_out: inserting 27627 0-frames to fill a gap of 51815 pts
>> video jump
>> bad_frame
>> video jump
>> video jump
>> bad_frame
>> video_out: throwing away image with pts 653020 because it's too old
>> (diff : 6489
>> 9).
>> 200 frames delivered, 14 frames skipped, 1 frames discarded
>> video_out: throwing away image with pts 2753839 because it's too old
>> (diff : 418
>> 6).
>> bad_frame
>> bad_frame
>> video jump
>> bad_frame
>> bad_frame
>> audio jump, diff=-51850
>> audio_out: inserting 27655 0-frames to fill a gap of 51866 pts
>> video jump
>> bad_frame
>> video jump
>> bad_frame
>> bad_frame
>> 200 frames delivered, 7 frames skipped, 1 frames discarded
>> video_out: throwing away image with pts 5052089 because it's too old
>> (diff : 4544).
>> 200 frames delivered, 0 frames skipped, 1 frames discarded
>> bad_frame
>> audio jump, diff=-45370
>> audio_out: inserting 24197 0-frames to fill a gap of 45382 pts
>> video jump
>> video jump
>> video jump
>> bad_frame
>> video_out: throwing away image with pts 6157260 because it's too old
>> (diff : 54139).
>>
>> Searching on the vdr mailing list I found a thread ("problem
>> vdr-xine-0.7.3 plugin") that seems to be related to this issue.
>> I tried to "play" with WRAP_THRESHOLD values without good results
>>
>> Did you have any suggestion?
>
>
> Have a look into xineDevice.c, cXineDevice::PlayCommon3() and comment
> out the first "if (0)" (i. e. => "// if (0)"). This enables logging of
> PTS values on console and you can check the offset between audio and
> video PTS as well as the offset to xine's metronom.
>
> The offset to xine must allways be positive and should be around 60000
> pts (= 2/3 seconds). If it gets too small or even negative, then xine
> will get buffer underruns which may cause the above issue.
>
> Another parameter to play with is vdr-xine's prebuffer setting. If you
> enlarge the setting then the above offset to xine should enlarge, too.
> But there are some drawbacks: when VDR cannot dispose its data to the
> device, it clears the device (after consecutive poll timeouts) which
> discards the buffers and causes vdr-xine to setup the prebuffer again
> and again.
>
> Especially the analogtv plugin uses "little" buffers for the encoder and
> therefore it is likely that vdr-xine's prebuffering overflows the
> encoder buffers which are then in turn cleared. The result is that there
> is almost no buffer although vdr-xine thinks to have a reasonable sized
> one (it's on my todolist to change prebuffering to consider xine's
> metronom).
>
> For any reason (I still haven't discovered why) there is a difference in
> the achieveable buffer size when xine is already connected to vdr-xine
> and you switch to an analogtv channel respectively when xine connects to
> vdr-xine after VDR was tuned to the analogtv channel. Most often the
> latter works without the above mentioned issue.
>
I tried to "play" with buffers values and other parameters without any
good results.
However I discovered a new interesting vdr log messages :
...
vdr[7985]: cAudioRepacker(0xC0): skipped 288 bytes to sync on next audio
frame
vdr[7985]: cAudioRepacker(0xC0): skipped 288 bytes to sync on next audio
frame
...
So, the problem seems to be related to vdr AudioRepacker, did you have
any suggestion?
I tried a lot of vdr versions with the same issue.
Thanks
Cristiano
