Tvheadend

John Törnblom wrote:

linuxtv_muxes.h seems a bit out of date.

Initial report can be found here: https://github.com/tvheadend/tvheadend/pull/50

I still do not understand why you do not use w_scan output or create your own parser based on tvheaedend. All TV set do a full scan first. Windows media layer also. I never got correct intial transponder frequency size I started using tvheadend...
And they have chnaged already four times.

Eric,

if you know a transponder frequency and your provider is using a correctly configures dvb network then I agree, there is no need to use these pre-configured list of muxes. Based on the first mux you manually enter, tvheadend will find all others. So for you and me, there is usually no need to use them.

But most users are not like you and me and they would like to receive some help with finding the various muxes. The ability to just select a network from a list that a user can relate to helps them a lot (at least .. that is the feedback we are getting)

A TV like full scan might work fine for dvb-t based networks because of the limited set of frequencies that needs to be scanned. But for some dvb-c networks where the providers are using weird offsets and other frequencies that do not fall in a "standard" list of frequencies having a initial tuning file helps a lot. And for DVB-S based networks, it is even more important to have these initial tuning lists.

Doing a TV like full scan for dvb-t can already be done with the current list because the full list of all the "allowed" frequencies is already included in tvheadend under the "auto" category. And combined with the latest patch to remove all the muxes that can not be tuned .. might also help people getting rid of muxes that are "useless".

Now the other question that can be asked .... should we have this "build into" tvheadend or should we run a program to look for these initial tuning file on the server where tvheadend is running an include these in the list of selectable networks. But .. that is a future feature request that I would like to see implemented. (You are always welcome to submit a pull request implementing such a feature or any other "solution" that can be implemented to help users select a good initial set of muxes)

For now ... we are stuck of this structure .. so if there is an update to dvb-apps initial tuning files ... we will update the code in tvheadend.

There is another pull request with updated muxes at https://github.com/tvheadend/tvheadend/pull/105

I can't seem to find them in the dvb-apps tree at the moment.

Hein Rigolo wrote:

Now the other question that can be asked .... should we have this "build into" tvheadend or should we run a program to look for these initial tuning file on the server where tvheadend is running an include these in the list of selectable networks. But .. that is a future feature request that I would like to see implemented. (You are always welcome to submit a pull request implementing such a feature or any other "solution" that can be implemented to help users select a good initial set of muxes)

For now ... we are stuck of this structure .. so if there is an update to dvb-apps initial tuning files ... we will update the code in tvheadend.

Some comments:
1) VDR, VLC, mplayer, kaffeine, xine do use w-scan to do their initial config,
2) Indeed they expect the tuning config file be generated,
3) As said, I never got a working/complete version of inititail transponder frequency in Rennes,

Of course, I do not mind having helpers that reduce scanning time but we should provide a default scanner for the case the "prerecorder" initial list is broken. The auto solution you mention is an overkill for me. w_scan -x is rather fast at generating dvb-t initial transponder list.