Tvheadend

this is not a bug
https://github.com/tvheadend/dtv-scan-tables
this one is not updated with are build in but linux support it also
https://git.linuxtv.org//dtv-scan-tables.git/ near dayli updates

According to the releases section, the latest stable version is 4.2.1

As far as the scan tables go for ATSC the file us-ATSC-center-frequencies-8VSB-062009, which is not region specific, has the following for mux 17:

[CHANNEL]
DELIVERY_SYSTEM = ATSC
FREQUENCY = 491028615
MODULATION = VSB/8
INVERSION = AUTO

The frequency line should read:
FREQUENCY = 491000000

The center frequency is off by 28615 which is enough to make reception marginal. Some, but not all of the region specific files do have the center frequency correct. For example the file us-CA-SF-Bay-Area has this for the first mux:
[CHANNEL]
DELIVERY_SYSTEM = ATSC
FREQUENCY = 503000000
MODULATION = VSB/8
INVERSION = AUTO

I am doing this to try and save trouble for people down the road....

Please correct it at the linuxtv repo then, if they accept it then we can do that change aswell (not for 4.2 though because as I said that version is super old).

4.2 is indeed the latest stable release but there are basically just organizational reasons for that: 4.2 was the last time when someone found the time to increase the version number. The current implementation is pretty stable and better than 4.2 in many respects, and if someone would propose a PR to move forward to 4.4/4.5 I would immediately merge it. On the other hand a project without a stable release would attract less people (and chances to get more active developers are even lower then), so that's why it's still there. I also considered adding a proper "end of support" notice but I think it's better to do it with the branching.

Nonetheless: Bug reports in any project should always be filed against the latest version, even if it's unstable. For any change to become stable it needs to be unstable for a few days/weeks/months, if everyone would file an issue for something that's already fixed and just not in a stable version yet that will just keep everyone busy and slow down the entire development (so the effect would be the opposite of what's wanted). I will add a proper notice for that though once I figured out where the best place for that would be as this is a common issues and people sometimes report issues for other builds with modifications aswell. Ultimately this all comes down to the lack of resources. If there would be more people actively developing and helping we could maintain 2 stable versions and provide support for all repositories etc., unfortunately we basically have one supporter who provides support and answers for many questions and one developer who is basically just merging pull requests that are good enough due to lack of time. Sure, the time I spent writing this essay could be spent coding but while I can just interrupt writing this text it's a lot harder to interrupt writing code as there are many things that need to be remembered and considered, so interrupting and continuing the process would mean that I'll have to start over again.

The current implementation is pretty stable and better than 4.2 in many respects, and if someone would propose a PR to move forward to 4.4/4.5 I would immediately merge it.

It's not possible to create tags or releases in Git via a PR. I've been experimenting with a clone of the repo and the process seems to be:

• Create an 'annotated tag' pointing to current Master. This doesn't seem to work in the Github GUI so I created a local clone, ran git tag -a v4.4 -m 'New Version' then pushed the change back.
• Create a release based on the new tag.
• After the first commit of the next development version, create a 'v4.5' tag.

Thanks for the advice, do you know how doozer/our build system will behave once I do that? Especially since I obviously want to retire 4.2 at the same time, that's something I am not sure about yet. How does it know which package goes into stable and which goes into unstable? I guess that's defined in the doozer config, but that's something I need to find out. Also I don't know yet how the version numbers in Tvheadend itself are set/defined, so that's something I would have to try out aswell. Creating the tag itself is not an issue, but the "special things" that are required need to be identified, and I guess that will take me an entire day and I just didn't find time for that yet as I don't want to leave everything in a broken state for a few days then.

Flole Systems wrote:

Nonetheless: Bug reports in any project should always be filed against the latest version, even if it's unstable. For any change to become stable it needs to be unstable for a few days/weeks/months, if everyone would file an issue for something that's already fixed and just not in a stable version yet that will just keep everyone busy and slow down the entire development (so the effect would be the opposite of what's wanted).

So your way ahead is to release 4.4. Then immediately start development with 4.5 and refuse to accept bug reports on 4.4 ?

Sorry : This doesn't make sense. It's far away from best-practice. It's so wrong that not even the opposite is true.

Having a "stable" version doesn't mean it's "bug-free". "Stable" means: it is "bug-free" enough for most people to use it in an production environment.

You need to have bug reports against the latest stable versions in order to iron out bugs in the codebase. Otherwise you will never know if an error is a sideeffect of new commits for a new feature in the devtree.

Besides: most people use the "stable" version - and not the "unstable" dev. But your Intention is not to use the error reports from the very big "stable" group to increase the quality. Instead you are forcing everyone to "update to latest master", because the error may already be fixed ?

So you should accept bugreports only for stable.

Yes: sometimes this means that there is double work if you are going to implement new fetures in the devtree. Too avoid this there are tools for automerging if this codearea is untouched.

The issues here is that there are too many commits between the latest stable and the latest unstable version - because there are too many new features implemented without drawing a new baseline.

Tom W wrote:

The issues here is that there are too many commits between the latest stable and the latest unstable version - because there are too many new features implemented without drawing a new baseline.

This is the crucial point here: The release of 4.4 as stable version has, for far too long, been put off and it is necessary to straighten out this matter. Especially because the "unstable" dev. version indeed is the one used by most people.
Usage of 4.2.x has been discouraged for quite some time now.

@Tom W: That's the only way this can be handled at the moment. Sure, we can accept any bug report and not care about it then but that doesn't make it any better. If issues in master are found that are considered major they will be backported.

So how do I go about correcting it at the linuxtv repo? I found https://git.linuxtv.org// but did not see TvHeadEnd there. There is a catagory for dtv-scan-tables.git do I need to add it there? The files listed there do not correspond to the ATSC files in TvHeadEnd.

The channel tables are at https://github.com/tvheadend/dtv-scan-tables. This is a fork of https://github.com/crazycat69/dtv-scan-tables; I believe at one time there were problems getting changes made hence the fork.

The ATSC frequencies in those tables are perhaps derived from https://en.wikipedia.org/wiki/Television_channel_frequencies#Americas_(most_countries),_South_Korea,_Taiwan_,_Burma_(Myanmar)_and_the_Philippines_2 (the "ISDB-T/Tb center" column).

I'm not familiar with ATSC so I don't know what frequency the tuner would use for locking - perhaps the "ATSC Pilot" on 488.31MHz? In any event I would expect the tuner to have AFC in order to compensate for manufacturing tolerances. Does the problem affect more than one tuner? Is there interference on the channel?

Donald Schlicht wrote:

So how do I go about correcting it at the linuxtv repo? I found https://git.linuxtv.org// but did not see TvHeadEnd there. There is a catagory for dtv-scan-tables.git do I need to add it there? The files listed there do not correspond to the ATSC files in TvHeadEnd.

read my first reply
Solution is to be merged both repost
then to be maked new version of TVH intall package
else install dtv-scan-tables package

I will shut upü now.

//tom

github.com/tvheadend/dtv-scan-tables does have the dtv-scan-tables I am seeing on my installation. However git.linuxtv.org//dtv-scan-tables.git does not have any that match. I am willing to make up a corrected file, but how do I copy it to github.com/tvheadend/dtv-scan-tables? I am a total noob at this.

To propose changes you would need to submit a Pull Request (PR). Github Help will explain how to do this.

However you would need to be sure that your changes are in fact correct. Looking at the history of that channel list, the 28.615KHz offset was introduced on May 16 2005 with the comment "In the USA ATSC is actually shifted up 28.615 Khz to minimize interference between NTSC and ATSC signals". It seems strange (but not impossible!) that no-one in the last 15 years has had any problems with tuning these channels.

Perhaps. However some if not most of the area specific tables do not have the 28.615KHZ offset. I have a SiliconDust OTA tuner. With this tuner, there are special utilities/web pages which display current diagnostic information on a tuner that is being used. When I use the SD provided app, and look at the reported center frequency, the reported center frequency does not have the 28.615 KHz offset. However when I use my HTPC and the provided scan table, the diagnostic does report the offset. I also experience marginal reception even though I am only 5 to 10 miles from the local antenna farm.