Project

General

Profile

Bug #320

al

Added by Eric Valette almost 9 years ago. Updated almost 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Category:
General
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Found in version:
Affected Versions:

Description

As I saw that bug related to EAC3 support had been fixed, I decided to give a shot at the snapshot. Compiled it, started it (I had again to figure out the -C option) and then tried to configure channles once again.

And once again it failed because the frequency transponder have changed again. I wonder why you do not use w-scan that does it automagicaly...

History

#1

Updated by Hein Rigolo almost 9 years ago

  • Status changed from New to Fixed
  • Found in version set to invalid

Tvheadend does not force you to use the "included" set of DVB networks. They are there to help you. When the information for those DVB networks is not updated with the main repository of these "initial scanning files" then Tvheadend does not know they have changed.

If you find that the information is not correct then you can send and update to the linux-media mailing list with an updated initial tuning file.

And you can manually enter the frequencies into Tvheadend. If Tvheadend has one frequency it should be able to find all other frequencies also (in a well configured DVB network)

w_scan does a " brute force" scan on every possible frequency that it knows about. So it is a tool to find the one single frequency that you need. But in the spirit of keeping things simple this script can be used stand alone and there is no need to include it into Tvheadend.

#2

Updated by Eric Valette almost 9 years ago

Too bad you do not want to simplify user life! The tuning takes only 7 minutes and is always exact.

BTW, I do not receive you chnage by mail.

#3

Updated by Eric Valette almost 9 years ago

The real problem is that you do not use a file format that other tools can generate (e.g vdr channels.conf) and by relying on things that are most of the time obsolete you force the end user to run w_scan anyway and feed you file with its own result.

#4

Updated by Hein Rigolo almost 9 years ago

The idea behind Tvheadend is that there is no need for a "file format", just like any regular STB that you can buy off the shelves.

By including a set of predefined DVB networks the idea was that it would make it easier for people to add DVB networks. If a network was not in that list people could still manually add one (or more) frequencies from their network manually (just like on a standard STB)

The included list is actually compiled directly into the Tvheadend binary it self. As you an other used have found out, this list is not always up to date and actually changing the list would require a new Tvheadend binary. Ticket #72 was created to remove this compiled list and use a file format. This has not been implemented yet. Some discussion has been taken place about what format would be ideal, but nothing has been formalized yet.

So it is not that we do not want to simplify user life, but including a brute force scanning tool like w_scan (or similair option) is not they way forward.

#5

Updated by Eric Valette almost 9 years ago

I find your STB analogy (or even HDTV internal DVB-T decoder) quite amusing: they just do brute forcescan and nobody is against that. So It think for DVB-T, this IS the way to go. This is what kaffeine, vdr, mplayer rely upon.

I do not care if you do a script that parse the output of w_scan (any form of generated channel.conf you prefer) or even if you use w_scan -x just to find the transponder. I do mind having always obsolete data and having to use w_sacn to find the transponder anyway.

Also available in: Atom PDF