[vdr] Re: prblems with xine plugin 0.0.2, xine exiting often

[Reinhard Nissl <rnissl@gmx.de>]

Hi,

Onno wrote:

> First i must say that i realy like this plugin,
> it gives a hughe boost to dvb on linux :-)
Well, as a start, I works quite well already. But there are a lot of things to 
improve, especially in xine :-)

> but i have some trouble with the display in xine, xine
> has problems with format changes on switching and after
> ending a recoding replay.
I've realized that too, but hadn't had time to look into that issue. I think, 
that I do something wrong when demuxing the fifo data and therefore run into 
an error case, where I return -1 which means "end of stream". For now, just 
hit "play" in the xine GUI and it should be ok again.

> most times the problems occour an channels broadcasting
> in 480x576, like sat1 and some music channels.
>
> the most likely error is a chopy, slideshow like display,
> with no sound, the othererror os that from time to time
> xine completly exits, this happens mostly on the exit
> from playback of recordings, but not only.
>
> the first error can most times be recovered by switching
> to the channel several times, or by switching to one of
> the more stable channels, like rtl.
Do you really use release 0.0.2, because below you mention 0.0.1? I've 
improved channel switching a bit in 0.0.2, but the mentioned behaviour can 
still happen, but not that often anymore.

The cause is a buffer underrun, as xine eats data to quickly to keep the 
metronom running like on the previous switched channel. But the satellite is a 
fixed rate source and cannot deliver more data on demand ;-)

xine currently doesn't handle fixed rate streams very well. The only thing I 
can do for now is to wait a few milli seconds on a channel switch to have VDR 
fill its ring buffer a little bit, so that xine "never" runs out of data.

Since release 0.0.2, there is a delay of 500 ms for the above reason. Other 
products buffer even more, but I don't like waiting two seconds on a channel 
switch. If you like to experiment, grep the source for '::usleep(500000)' and 
choose a higher value. Don't go to high, to not have VDR's ring buffer overflow.

Sometimes, there is still not enough data buffered. In that case, just hit 
pause in xine's GUI and after a second press play again. That should lead to a 
smooth playback.

> the fact that the osd is overlaying itself when the x axis
> is smaller than ~640 does look like a known limitation,
> but i have so far not read about it, so i mention it.
That's a matter of xine too. xine blends the OSD data into the stream image at 
it's native resolution and then scales the picture to the correct aspect 
ratio. That's why the OSD appears at different widths for different channels. 
That the OSD wraps is a bug in the xine's blending code. I've already sent a 
patch to the xine developers, that also improves color blending (see 
http://home.vr-web.de/~rnissl/device0-4.png for an example), but the patch is 
currently in review.

> i'm using: vdr 1.2.1/1.2.2, xine-lib-cvs and xine-ui-cvs
> from the first xine plugin 0.0.1 release day, dvb-1.0.0
You really should update to vdr-1.2.5 and dvb-2003.09.05. Especially the later 
has fixes for broken recordings like http://home.vr-web.de/~rnissl/001-1.png.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.