Hi,
Am 14.02.2010 18:52, schrieb Joachim Wilke:
> I am using VDR 1.7.11 with xine / vdpau as output device. Replaying an
> audio only recording (e.g. from a radio channel) or an MP3 file (with
> mp3 plugin) leads to two strange things:
> 1.) The progress bar is always several seconds ahead - at the
> beginning of the recording it jumps instantly to ~20sec
> 2.) When pressing "exit" during playback the sound itself stops
> immediately but VDR hangs up to one minute before leaving the replay.
>
> I have no idea what the reason for this could be - does anybody of you
> have the same issue?
I do. I have configured 2300 audio input buffers in .xine/config.
In case of vdr-xine, each input buffer gets just a single audio
frame which in case of usual mpeg1 layer2 audio means 24 ms audio.
I haven't check yet, at which rate VDR generates index entries in
case of radio recordings, but some other debug output shows that
"playFrame number" (i. e. the frame which is currently transfered
to xine) is about 800 ahead of "Current" (i. e. the frame which
is currently played by xine), which is derived from STC, and
"Current" is used to draw the progress bar.
If you have a look into dvbplayer.c, you'll find this line:
#define PTSINDEX_ENTRIES 500
It looks like VDR stores only 500 historic frame to pts
associations relative to playFrame. So when you start replaying a
recording, "playFrame" will quickly run up to something like 800.
As VDR cannot find the STC value provided by vdr-xine in it's
buffer, it will stay at the beginning of it's buffer and return
something like 300 for "Current". I assume that 300 is related to
20 seconds.
I've increased the above constant for simplicity just to 5
for testing and the issue is gone at least for audio recordings,
but I haven't tested the change with mp3 plugin yet.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
