Tvheadend

Who's responsible? well you pretty much summed it up

The hardware will play a part, it all depends on its ability to stabilise clocks and lock onto signal etc...
The firmware can play a part in ensuring responsive transfer of requests and proper sequencing of hardware etc...
Tvheadend will need to quickly respond to tuning request and forward them to the firmware as well as handle the incoming data and get its own beans in a row et.c..
XBMC will need to quickly respond to user input forward it to tvh (over the network?), and when the response data comes back must handle this (including codec setup and decode etc...) as quickly as possible.

So the short answer is all of them play a part. Personally my setup zaps (DVB-S) in about 1-2 seconds as seen from XBMC. What the relative contributions are to that time I do not know, its quick enough I've never been bothered enough to find out. But in my experience XBMC is often the slowest part of the chain (when things are particularly slow, but not always).

Adam

Thanks Adam.

All them are involved, but I only can control one of them, the hardware.

Is there any performance different between linux tv cards? Someone has better support on linux? I'm talking about chanel change speed, but I have read that some cards has other problems like initialization times for about 25 secs.

I honestly couldn't say as I have no DVB-T devices and I'm still fairly new to DVB. try asking in #hts though, you might get some answer in there. Or just have a look on the linuxtv web site see if there are any recommendations on there.

I did create a thread on the wiki some time ago for recommended hardware, so you could try and find that.

Adam

Sorry but, whais #hts?

and where is that recomended hardware thread? Could you link?

I also thinking to buy a DVB-S card, so I'm thinking on buy a DVB-T+S or two cards, one for satellite and other for terrestrial.

#hts is the IRC channel, another good place to ask questions about TVH. Most people visit both the forums and IRC, but sometimes the makeup is different and you might get different input from each.

https://www.lonelycoder.com/redmine/boards/5/topics/5102

Adam

Lot of thanks

I'm asking myself the same question. I'd like to have very fast channel changing.

I was convinced that it was a tuning issue but you say that XBMC can be the most time consuming part ...
I will investigate first by changing channels that are in the same mux and see how many time it takes.
I will also experiment with mplayer.

My first idea was to buy 4 cheap dvb-t stick and a usb hub and have each tune to a different mux then the channel change should be really fast but my other concern is : will the usb hub support the bandwidth of for dvb-t muxes?

Experiences can vary, but I know that in recent builds of XBMC I've been playing with the biggest factor in time to tune has been XBMC sorting out the codec handlers for the stream.

For example I was testing with a rawts input (this is a debug mode) so there was no "tuning" involved, so TVH is essentially instantaneous (though obviously there will always be small delays while it sets things up internally).

XBMC took a noticeable (I didn't measure it) amount of time to tune the channel, whereas I also tried showtime (the frontend media system written by Andreas the original TVH author) and that was much quicker (at least to my eye).

Generally speaking on my main XBMC machine when I change channel TVH usually reports in the logs that its tuned and received the signal in <1s and XBMC appears to detect said incoming stream pretty quickly, however it still stalls a bit while getting its beans in a row (codec handlers).

But then of course, if you have a poor DVB card (or driver) then your experience may well differ. But generally speaking TVH is usually not the significant factor in either case (but doesn't mean it can't get things wrong occasionally ).

Adam

• PCI or PCIe
• Fast zapping
• Linux compatible
• I dont mind about compile kernel
• 2 tuners min
• DVB-T