Tvheadend

Flole Systems wrote:

I am using an AVM FritzBox 6490 as SAT-IP Server. When I have 2 Channels on the same Tuner then I am getting dropouts. So what I am requesting is an option to force an individual Stream getting it's own tuner, so when I receive 4 Channels on for example 533Mhz, then there should also be 4 Tuners used for that.

Great idea!

Several SAT>IP servers has a limit in the output bitrate (most around 10-25Mbps). So with this "simple" option new subscriptions will use new tuners.

I hope Jaroslav will consider to move this request with a target priority to 4.4
Regards.

Simple in UI does not mean that it's simple in the implementation. The DVB input side expects that the whole mux can be received in one stream (the problem is mainly with the shared SI tables like PMT/EPG etc.).

I would love the same thing, but with a difference. That it was a modifiable box (int). In the case of my SAT>IP (Triax TSS 400) it allows more than 1, in particular 5, execeding that mean you will have a packet loss.

The perfect implementation would be with a modifiable box of "maximum number of channels per adapter".

Hi,

Any improvement in this area will make current "low cost" SAT>IP tuners a good alternative.

Thank you Jaroslav to comment about this issue!

From my view, the implementation should be like this - we should use 'slave' tuner for A/V PIDs when a limit is crossed including PMT/PCR. In this case, the sync should be fine.

I dont know if to use PIDs is the best idea; Because some channels have more or less PIDs than others: teletext, dvbsub, audios, etc.

I think a better solution is to count "video PIDs" or so. As I has found that the limitation is the video not the other low weight pids.

All PIDs for one service should be handled per tuner.

Jaroslav Kysela wrote:

All PIDs for one service should be handled per tuner.

Hi, I have a "similar" request here: https://tvheadend.org/boards/13/topics/34461

All PIDs per tuner is not really my wish. Like described in the forum, some CI modules can only handle 2-3 simultaneous decryptions of channels.
So, it would be awesome to limit the amount of recordings or streams from a single tuner. Not that the tuner cannot handle it, or a connection to oscam or whatever. In my case, the limitation is my provider's cam.

I don't know if limiting the amount of video PID's like Pablo R describes would solve my problem too?

On the other hand... a DVBViewer dev suggested that the limitation should come from the minisatip server and not from the backend. So, would this rather be a "feature" for minisatip for example or for tvheadend?

Yep, this is a nice idea, but we can probably link together multiple tuners (merge the input data from two or more tuners) before they are handled in the tvh, too. It may be simplier than handling this in the upper levels (service etc.).

Jaroslav Kysela wrote:

Yep, this is a nice idea, but we can probably link together multiple tuners (merge the input data from two or more tuners) before they are handled in the tvh, too. It may be simplier than handling this in the upper levels (service etc.).

Why would you link the tuners together?

Isn't it more easy to implement a "maximum video PID's" option in the advanced settings of the TV adapter? If you would set this to 1, it could force the tuner to tune only into 1 channel at the same time. So when trying to stream another channel on the same frequency, TVH can use another free tuner? This would solve Flole Systems' problem and and mine as well :)

I would set it to 3 so I can use the limit of my CI module (descrambling max 3 simultaneous channels) optimally. When I want to record a third channel on the same mux, it can use another free tuner. (I'm also using a sat>ip server as hardware input)

Whether it's recording by TVH or streaming by TVH to clients, this setting can be multifunctional?

What do you think about it?

Guys, I know that you see only the value with the limit in web ui for this, but I need really think about to run multiple instances of one mux on different tuners and it's impact to the whole tvh input processing. Some duplicated information will be received with this scheme and there are some presumptions in the code (for example for EPG handling, service scanning etc.). So things are not easy.

Any updates on this??

No, if you want to work on this feel free to do so though.