Thibaut Mattern wrote:

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).
  
The time taken for the tune_it function to complete is long. I'll got it down from
around 5 seconds to 2. I removed the net_buf_ctrl to get the video to start sooner
as well.


  
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
  
I've fixed the hang in initial tuning by adding a configurable timeout to
the tune_it function.

I've not looked at (3) very mush. Can you tell me a bit more about _x_io stuff?
  
4. Debug code core dumps xine
    

should be easy to fix
  
It was an easy fix.

  
5. It's got a UI!
    

the osd stuff ?
  
Yes. I've added a config item prevent any of it from being called.
6. Cannot configure where to find the channels.conf file
    

a config entry should be enough
  
Indeed that's what I did.
7. Leaks FILE's
  

should not be too complicated to fix
  
It was easy to fix.
  
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
happens).
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).
  
I see what you are saying. With DVB the clocking must use the incoming stream
as the master. Using internal clocking will always go wrong after enough time.

Does the net_buf_cttl code have any effect on this problem? Was I wrong to
remove it? I'll look at the pvr plugin and see what it does aout clock adjusting.

Barry