Bug #570
closed
French muxes need to be updated
Added by Mossroy Mossroy almost 14 years ago. Updated almost 14 years ago.
0%
Description
In France, the DVB-T channels are currently moving. The file src/linuxtv_muxes.h reflects the old frequencies. I suppose it needs to be updated to reflect these changes.
The frequencies are modified region by region, with a calendar that started in late 2009, and will end on november 29th 2011 (see http://www.tousaunumerique.fr/ou-et-quand/ )
I manually modified the frequencies for my region, recompiled tvheadend, and it found my channels as it did before.
All the new channels are listed here : http://www.tousaunumerique.fr/professionnels/en-savoir-plus/documentation/categorie-doc/plans-de-frequences/ . The PDF files also lists channels that are planned to be used in the future (but are unused at the moment)
I used this formula to compute the frequencies : (306.167 + 8 * channel_number) * 1000 000 (not 100% sure that it applies everywhere, but it worked for me). I also put the future channels : tvheadend complained about "bad signal" on these ones, but it did not hurt and will allow future usage.
I would suggest to update src/linuxtv_muxes.h with all the new frequencies (including the ones that will only work by november 2011, and the unused ones)
I'd like to propose a patch for that, but it seems to be a much too huge work to do it by hand (110 different DVB-T broadcaster, with around 10 frequencies to compute for each...)
I saw that all these frequencies also appear in debian/ubuntu package dvb-apps (they are also outdated).
Do you know of other places where these frequencies would be maintained? I suppose that they already exist in a numeric form somewhere...
By the way, why does tvheadend not use the dvb-apps package to find the frequencies? It would maybe be a solution for issue https://www.lonelycoder.com/redmine/issues/547
Files
| linuxtv_muxes.h (790 KB) linuxtv_muxes.h | linuxtv_muxes.h rebuilt from dvb-apps, with fr-* removed and fr-All copied from auto-With167kHzOffsets | Mossroy Mossroy, 2011-07-02 16:01 | |
| patch_main.c.txt (125 Bytes) patch_main.c.txt | patch for file main.c to add a few necessary TLDs | Mossroy Mossroy, 2011-07-02 16:01 | |
| patch_main_with_auto_region.c.txt (468 Bytes) patch_main_with_auto_region.c.txt | patch for file main.c to add a few necessary TLDs, and handle auto-* files | Mossroy Mossroy, 2011-07-02 18:06 | |
| linuxtv_muxes.h (772 KB) linuxtv_muxes.h | linuxtv_muxes.h rebuilt from dvb-apps, with fr-* removed, and auto-* files recognized as a generic region | Mossroy Mossroy, 2011-07-02 18:06 |
Updated by Hein Rigolo almost 14 years ago
the dvb initial tuning files are maintained by the maintainers of dvb-apps. Any update that is needed should be emailed to the linux-media mailing list (linux-media@vger.kernel.org).
Periodically these initial tuning files are converted in the required source files for tvheadend. There are bugs/feature requests open to change this to directly use the initial tuning files (or some other method)
Hein
Updated by Eric Valette almost 14 years ago
Hein Rigolo wrote:
the dvb initial tuning files are maintained by the maintainers of dvb-apps. Any update that is needed should be emailed to the linux-media mailing list (linux-media@vger.kernel.org).
As I already voiced, w-scan can perform initial tuning quite well, why reinvent the wheel. Any TV does a scan when you install it.
Updated by Mossroy Mossroy almost 14 years ago
I wrote on linux-media mailing-list : http://www.mail-archive.com/linux-media@vger.kernel.org/msg33394.html
Modifying by hand the frequencies town by town, based on the PDF files, seems unfeasable to me.
I called the organism that created the website, and asked for a numeric file of all frequencies. But I think I have very low chances to have an answer.
As I wrote on the mailing-list, I was wondering if having one set of frequencies for all the country would be enough (I did not have an answer so far)
There seems to be "only" 57 frequencies available all over the country.
I suppose tvheadend would simply take longer to scan all these frequencies (instead of about 10) : it seems to ignore the frequencies where it does not find anything.
On the other hand, it would in the future be able to find the TV channels that will appear on the currently unused frequencies, without a need to update the frequencies again.
I agree with Eric Valette that using w-scan to discover the channels would be much better.
But, before it's done, we should find a way to re-enable TV for French users.
What's your opinion?
Updated by Hein Rigolo almost 14 years ago
For the DVB-C initial tuning file here in .nl I did something similar. There are many different frequencies that are used depending on your location, but it turned out that there are only 3 "main" frequencies where at least one is used at each location. So the initial tuning file for nl-Ziggo only contains those 3 frequencies. All the other frequencies can be taken from the DVB network information that is transmitted.
So you might not even need all 57 but even less, and then the other frequencies will be found automatically.
You can test/see this happening when you only manually add one transponder frequency in tvheadend and enable "Autodetect muxes". Based on the information that is broadcasted on that first inital transponder all the other frequencies can be found.
But, there is absolutly no problem with adding all 57. But you might end up with lots of muxes that do not have a signal.
Updated by Mossroy Mossroy almost 14 years ago
Based on the answers in the linux-media mailing-list and here, it seems a good idea to have only one set of frequencies for all the country.
I'd like to test, and then propose a patch for tvheadend.
But there are some extra info in linuxtv_muxes.h that I don't know : besides each frequency, there are some fields called bw, constellation, fechp, feclp, tmode, guard and hierarchy. How should I fill them?
I'd like to generate it from the frequencies here : http://linuxtv.org/hg/dvb-apps/file/148ede2a6809/util/scan/dvb-t/auto-With167kHzOffsets
If linuxtv_muxes.h is periodically generated from this kind of file, there must be a way.
About the "autodetect muxes" feature, it should help in case some extra frequencies are not listed, but there is unfortunately no frequency that EVERY region uses (based on http://www.tousaunumerique.fr/professionnels/en-savoir-plus/documentation/categorie-doc/plans-de-frequences/). So I think I won't have another option than put all the frequencies (there are around 150 because each fequency needs to be duplicated with the offsets -167 and +167)
Updated by Hein Rigolo almost 14 years ago
But there are some extra info in linuxtv_muxes.h that I don't know : besides each frequency, there are some fields called bw, constellation, fechp, feclp, tmode, guard and hierarchy. How should I fill them?
If you look at the dvb-t file you point to you will see in the header the following string:
#T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
That tells you the order and format of the following lines. Based on that you can also make the mapping to the fields in linuxtv_muxes.h.
Now the good thing is that this has already been done by andoma and put into a script/program. You can find that program here:
/ src / muxbuilder
In the main.c is all the logic to convert the initial tuning files to a linuxtv_muxes.h file. what you also can see from that program is that these auto-xxxx files are not converted, because they do not have a country code as the starting characters of the tuning file.
If you say that the auto-With167kHzOffsets file contains the correct information, then you can copy that to fr-All. Then the muxbuilder program will find the file, and will add it to linuxtv_muxes.h for you. Like the hr-All and cz-All file currently. You might even want to make it really france specific by populating the correct values for the fec high/low, modualtion etc .. in the fr-All file instead of the AUTO option that is currently there. But this might not be really neccesary as Christoph Pfister says on the mailing list.
What you also can do/ask is to add "auto" as a valid region code (generic dvb-t .. similair to geo used in dvb-c) so all the other "auto" files are also picked up. Not sure if that is realy what we want to have .... but it might be an option.
Hein
Updated by Mossroy Mossroy almost 14 years ago
- File linuxtv_muxes.h linuxtv_muxes.h added
- File patch_main.c.txt patch_main.c.txt added
Now the good thing is that this has already been done by andoma and put into a script/program. You can find that program here:
/ src / muxbuilder
In the main.c is all the logic to convert the initial tuning files to a linuxtv_muxes.h file. what you also can see from that program is that these auto-xxxx files are not converted, because they do not have a country code as the starting characters of the tuning file.
If you say that the auto-With167kHzOffsets file contains the correct information, then you can copy that to fr-All. Then the muxbuilder program will find the file, and will add it to linuxtv_muxes.h for you. Like the hr-All and cz-All file currently. You might even want to make it really france specific by populating the correct values for the fec high/low, modualtion etc .. in the fr-All file instead of the AUTO option that is currently there. But this might not be really neccesary as Christoph Pfister says on the mailing list.
Great!
I tried what you suggested :
- I downloaded the latest frequencies from dvb-apps : http://linuxtv.org/hg/dvb-apps/file/148ede2a6809/util/scan/dvb-t/
- I removed the fr-* files, and copied auto-With167kHzOffsets to fr-All (without modifications)
- I also had to patch src/muxbuilder/main.c to make it recognize a few more tlds (see attached patch)
- I ran muxbuilder, with the build.sh script, and overwrote the linuxtv_muxes.h in tvheadend src folder (see attached file)
- I recompiled tvheadend, restarted it, removed my current multiplexes, and added the DVB networks from "France->Auto"
Tvheadend scanned all these new frequencies : it took around 50 minutes (20s per frequency). I find that a bit long compared to how long a standard TV takes to scan (mine takes around one minute to find all the channels)
It found all my channels on frequencies with a +0 offset. So maybe the +167 and -167 offsets are unnecessary... but I can not say for sure.
What you also can do/ask is to add "auto" as a valid region code (generic dvb-t .. similair to geo used in dvb-c) so all the other "auto" files are also picked up. Not sure if that is realy what we want to have .... but it might be an option.
I find that this would be really relevant.
In fact the auto-* files are included in the attached linuxtv_muxes.h files, but they are associated to Australia country. This is because "auto" starts with "au", which is the country code of Australia (see line 374 and following of main.c). The main.c file expects a 2-letters country code.
If I manage to resurrect my very-ancient C bases, I might try to create another patch to handle the "auto" country code, instead of creating a duplicate "fr-All" set of frequencies
Note : tha attached files work for me, but I don't think they should be commited as is. It is still a work in progress
Updated by Mossroy Mossroy almost 14 years ago
- File patch_main_with_auto_region.c.txt patch_main_with_auto_region.c.txt added
- File linuxtv_muxes.h linuxtv_muxes.h added
OK I now can propose a patch for inclusion in tvheadend, based on the proposals of Hein Rigolo.
Anyway, I'm not a C expert so maybe my code is not very good.
You'll find attached a patch for main.c so that it can handle the latest dvb-apps files, including the auto-* files (I have put them in a region called "--Generic--" so that it appears first in the list : feel free to rename it if necessary).
You'll also find the generated linuxtv_muxes.h that correspond to the latest dvb-apps files (http://linuxtv.org/hg/dvb-apps/file/148ede2a6809/util/scan/dvb-t/ ), on which I deleted the fr-* files
I've already proposed to delete these fr-* files in dvb-apps mailing-list. I'll propose to commit that upstream.
With this patch on tvheadend, using the auto-Default frequencies is sufficient to find all my channels (but that might depend on your location. If it's not enough, you might use auto-With167kHzOffsets)
These frequency sets might be used in France, but also in any country that does not have specific frequencies.
Scanning time on my hardware :
auto-Default : 19 minutes
auto-With167kHzOffsets : 50 minutes
Updated by Hein Rigolo almost 14 years ago
Good work ....
as stated on the overview page:
The code is hosted at github https://github.com/andoma/tvheadend.
Please use github's features if you want to provide patches.
Then it is easier for andoma to review and include them. You can then send andoma a request to pull in your changes.
Now that you know all the frequencies that are really used at your location .. can you do a test:
Remove them all, and then manually add a single transponder. enable "Autodetect muxes" and see how quickly tvheadend finds all your relevant transponders ... that should be about as quick as your TV I would guess.
Hein
Updated by Mossroy Mossroy almost 14 years ago
I created the pull request :
https://github.com/andoma/tvheadend/pull/33
Updated by Mossroy Mossroy almost 14 years ago
The pull request has been commited by Andoma
Updated by
Updated by Mossroy Mossroy almost 14 years ago
Hein Rigolo wrote:
Now that you know all the frequencies that are really used at your location .. can you do a test:
Remove them all, and then manually add a single transponder. enable "Autodetect muxes" and see how quickly tvheadend finds all your relevant transponders ... that should be about as quick as your TV I would guess.
I did your test, but it did not guess the other multiplexes, even with "Autodetect muxes" enabled. Maybe this feature is not used by the multiplexes in my location...
Updated by Hein Rigolo almost 14 years ago
I did your test, but it did not guess the other multiplexes, even with "Autodetect muxes" enabled. Maybe this feature is not used by the multiplexes in my location...
Well ... reading this page:
http://forums.dvbowners.com/lofiversion/index.php/t9065.html
there it is describe why it does not work ... because .. just like you said .. the information is not transmitted correctly in France ...
So .. you really need to have all the muxes in order to get all channels and then delete the not needed one's.
So .. hopefully this might change in the future ....
Hein
Updated by Mossroy Mossroy almost 14 years ago
The deletion of the fr-* files has been commited upstream. See http://www.mail-archive.com/linux-media@vger.kernel.org/msg34519.html