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

[Onno <onnok@web.de>]

Hi Reinhard,

Reinhard Nissl schrieb:

[..]
 > 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.
thanks for that tip, i will keep that in mind.

[..]
> 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.
yes it is 0.0.2, i know because i never had 0.0.1 on the new mandrake
system, and it is happening not so seldom; my signal is always between
62 and 78, the s/nr values are always above 75%, just in case yours
is better, one might take that also into account...

[..]
> 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.
nice to know, since i don't use it for daily tv zapping, but rather
for cutting and timer programming, i will increase it to 2 sec, like
some old dvb stb's also do :-) and report the effects, i guess,
tomorrow evening.

> 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.
ok, i will try that too, before patching, just to know the difference.

> > 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.
where to send begging mails to ? :-) (just kidding)

> > 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.
ok i didn't say it, but i changed to DVB from cvs, 15.09.2003 because i
also read about fixes for nova cards, but like other people i didn't see
any benefit until now, yet i still use them, they wont be worse...

i will consider upgrading vdr as soon as i figure out which patches
are (still) required for me, and if they are available for 1.2.5.
i know that's not a good reason, but ElchiAIO is now bundled with
rec_lenght_diplay patch, which i consider a performance penalty due to
heavy i/o on opening the recordings menu. is there a significant reason
to switch to vdr-1.2.5 for the xine plugin ?
(i have applied most of the patches from the vdr ml, which came from
Klaus, or he at least commented too, so i hope my 1.2.2 has no known bugs)

Regards Onno

P.S. hope it's nice to know your spare time is spend well




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