Thibaut Mattern wrote:
The time taken for the tune_it function to complete is long. I'll got
it down from
1. Its slow to tune
What do you mean ? the engine latency is high ?
The net_buf_ctrl stuff has been designed to be tweakable by input
plugins. I can easily reintroduce this feature and allow input plugins
to set the buffering length (1 second instead of the default 5).
around 5 seconds to 2. I removed the net_buf_ctrl to get the video to
I've fixed the hang in initial tuning by adding a configurable timeout
2. xine_stop hangs if it fails to tune in initialy
3. xine_stop hangs if you unplug the arial (lost signal)
see _x_io stuff
the tune_it function.
I've not looked at (3) very mush. Can you tell me a bit more about
It was an easy fix.
4. Debug code core dumps xine
should be easy to fix
Yes. I've added a config item prevent any of it from being called.
5. It's got a UI!
the osd stuff ?
Indeed that's what I did.
6. Cannot configure where to find the channels.conf file
a config entry should be enough
It was easy to fix.
7. Leaks FILE's
should not be too complicated to fix
I see what you are saying. With DVB the clocking must use the incoming
8. Output stops or output stammers
maybe there is not clock management in this plugin, so there might be
an underrun (all frames are too late) or an overrun (i don't know what
i see two ways to fix this :
1 - a SCR plugin, using the system time included into the stream
2 - adjust the clock speed to keep the same amount of data in the
fifos (iirc that's what the pvr plugin does).
as the master. Using internal clocking will always go wrong after
Does the net_buf_cttl code have any effect on this problem? Was I wrong
remove it? I'll look at the pvr plugin and see what it does aout clock