Tvheadend

Floel has decided to do everything in the mainbranch.

Every suggestion to

- draw a new baseline
- announce rc
- do bugfixing in the stable branch

has been rejected. (already 3 years ago)

Godmode programming doesn't need testing, releasehandling and requiremtenthandling.

Folks I imagine the problem is time, or the lack of it for many aspiring developers these days. The original developers appear to have stepped back and as a result it has been left to @Flole998 to keep some shape on the project as it currently stands and administer it. A free for all is not the answer here.

Many aspiring developers come and go with great ideas and plans for TVH that never really materialise. Just look at some of the PRs still outstanding on the GitHub for example.

What could be done is to establish a section on this forum for aspiring TVH developers where they can discuss ideas and submit proposals as a collective to further TVH development.

The current trend is towards containers and while some swear by them others are reluctant to embrace them for their own reasons. That’s something that can be discussed here at length so a consensus could be arrived at.

Your ideas are not being rejected but change for the sake of change is not necessarily a good thing for the longer term future of the project.

Jonas Lang wrote:

What could be done is to establish a section on this forum for aspiring TVH developers where they can discuss ideas and submit proposals as a collective to further TVH development.

That sounds like a sensible idea to me.

The current trend is towards containers and while some swear by them others are reluctant to embrace them for their own reasons. That’s something that can be discussed here at length so a consensus could be arrived at.

Given that TVH relies on hardware - TV cards - that rely on drivers and that in some cases those drivers are not in the mainline kernel, I don't know how containers cope with that situation. Plus of course there's the container wars - which one to pick? So I'm not convinced containers solve any of TVHs problems.

Jonas Lang wrote:

What could be done is to establish a section on this forum for aspiring TVH developers where they can discuss ideas and submit proposals as a collective to further TVH development.

I too would also be interested in developers' section in the forum. I am new to TVH and although I am learning, some of the most simple concepts still take a lot of investigation to uncover.

I was hoping someone would make a post on this topic at some stage. So many pass through, critise TVH and disappear again.

Personally I use a Sat IP tuner so don’t have issues with firmware and kernel upgrades breaking TVH. Of course many use DVB cards too and clearly broken drivers are a big issue in that case.

It would be good for TVH if we could breathe new life into this forum. It would help users to discuss their problems, suggest possible new features among other things.

For those who don’t develop or code there’s always the TVH wiki that needs updating so everyone has a part to play.

Jonas Lang wrote:

For those who don’t develop or code there’s always the TVH wiki that needs updating so everyone has a part to play.

Send me what want to post in wiki part and I'll post it in reasonable time.
/for me reasonable time is: up to 2-3 days, not few month's/

saen acro wrote:

Jonas Lang wrote:

For those who don’t develop or code there’s always the TVH wiki that needs updating so everyone has a part to play.

Send me what want to post in wiki part and I'll post it in reasonable time.
/for me reasonable time is: up to 2-3 days, not few month's/

Of course but the idea is to get others involved too. This can’t be left to one or two people all the time. The more we have onboard contributing the more chance of expanding the project we have. That’s evident over the last couple of years here.

Flole Systems - What is your vision for TVH?
Flole Systems - How can we, the user/developer community, help you achieve that vision?

That being said: What follows is my, admittedly unsolicited, opinion. No offense is meant, none will be taken.

Step 1 - Perform a risk assessment.

What are the risks if TVH continues along its current path?
Are these risks acceptable?

I think that the project risks being forked off by other parties who what to fix some bugs or add some features. This could eventually end up with multiple and potentially incompatible versions of TVH floating around.

There may be other risks too.

Step 2 - Start a project and give it a name.

It could be v4.3.0, or it could be a code name, it does not really matter as long as we are all talking about the same thing.

Step 3 - Communications

• Create a forum section to discuss this, and only this, topic.
• Create a Wiki page to keep track of common data and centralised progress pertaining to the project.

Step 4 - Assess the current situation.

• Extract a list of merged PRs since that last stable release from GitHub.
• Match the PRs to bugs/issues recorded by TVH.
• Assign each change a category such as 'bug fix', 'enhancement' or 'new feature'.
• Determine which sub-system the change affects (DVB, EPG, API, etc).
• If the change impacts the WebUI, what translations have been done or are required.

This will give the project team an indication of the potential scope of the project as well as the areas of expertise that may be required.

Step 5 - Risk assessment (again) and Prioritisation

I may be slightly naïve, however, I see pretty much the only risk as being 'System Instability'.

For each change identified above, assess the likelihood that it will cause system instability and the impact that the instability will have on the average user. This will help provide an estimate of the testing effort required.

If the audit has shown a huge backlog, perhaps each change can be prioritised 'low', 'medium' and 'high' in terms of importance to the release.

Step 6 - Testing / Translating

Depending on the risk assessment and prioritisation above plus the state of the translations, changes can be prioritised and testing can commence.

I know that when I make changes, I test that feature on my system and do a quick sanity check, but I do not do exhaustive regression testing. I would appreciate at least one other person testing my code prior to release.

Also, if there are other forks in the wild: When was the fork made? How stable are these forks? How many of the identified 'changes' have been incorporated? We may be able to reduce some testing overhead by assessing how changes have performed on other forks.

With the translations: If we can not enlist the help of any appropriate native speakers, I have had success with online translations in the past. I use two independent services and perform a round-trip check. System 1 English -> Foreign -> System 2 Foreign -> English. If the English that comes back is 'close enough' then it is probably safe-ish to use.

Step 7 - Release

Make an official release. Perhaps it could be labelled 'Beta' as a safety precaution.

Delta Mike Charlie wrote:

• Extract a list of merged PRs since that last stable release from GitHub.

GitHub has a REST API that can list all of the PRs.

Example: https://api.github.com/repos/tvheadend/tvheadend/pulls?state=all&sort=updated&per_page=100&page=16

I volunteer to write a Python script to extract the: PR title, creator, assignees, create date, merge date; for all PRs that have been merged since 16-Oct-2018. Output could be in a text format consistent with Wiki tables.

There is really no point in trying to maintain 2 branches if there aren't even enough resources to maintain a single one. Also I have absolutely no clue how a new release needs to be done. I assume it somehow involves branching, but that's probably not all that's needed.

I have simply abandoned the idea of doing releases for now as the master branch is pretty stable (and at least better than 4.2). With maybe 10-20 commits per year the risk of breaking something is low enough.

I don't think I have access to the translations, also the documentation needs to be "compiled".

What would make sense is switching from our own dvb scan tables to the upstream version so we no longer need to maintain that.

Delta Mike Charlie wrote:

Delta Mike Charlie wrote:

• Extract a list of merged PRs since that last stable release from GitHub.

GitHub has a REST API that can list all of the PRs.

Example: https://api.github.com/repos/tvheadend/tvheadend/pulls?state=all&sort=updated&per_page=100&page=16

I volunteer to write a Python script to extract the: PR title, creator, assignees, create date, merge date; for all PRs that have been merged since 16-Oct-2018. Output could be in a text format consistent with Wiki tables.

This option is available in Redmine automatically.
badly Redmine platform is also outdated and cannot communicate with github anymore
and was disabled long time ago https://tvheadend.org/projects/tvheadend/repository

Badly no one have full access to all services used by project.
as an example I can give that in github there are no tags for the possibilities of tvhehedend
and this does not help at all for the discovery of the project.
Which could possibly lead to new members to enrich the project.

Flole Systems wrote:

There is really no point in trying to maintain 2 branches if there aren't even enough resources to maintain a single one. Also I have absolutely no clue how a new release needs to be done. I assume it somehow involves branching, but that's probably not all that's needed.

I have simply abandoned the idea of doing releases for now as the master branch is pretty stable (and at least better than 4.2). With maybe 10-20 commits per year the risk of breaking something is low enough.

I don't think I have access to the translations, also the documentation needs to be "compiled".

What would make sense is switching from our own dvb scan tables to the upstream version so we no longer need to maintain that.

Flole Systems - Thanks for the update.

Is there anything that we can do to help?

I'm not sure why 2 branches need to be 'maintained', at least in the long run. The master branch would remain as-is and the new branch would be where the release build from and then saved.

I recently worked on the documentation provided by the WebUI for one of my PRs. There was a python script to run that builds some 'c' / 'h' files from some 'md' files. These then get compiled into the application. Would some investigation in this area help?

What do you mean about not having access to the translations? Do you know where they are kept and you don't have access or do you not know where they are kept?

Demonstrating a shameful lack of self-control, I start work on the script. Here are some initial findings:

Target PR Count: 231 / Total PR 1546
Bug/fix Count: 80
Update Count: 30
New Count: 40

The last three are simply keyword searches, so their accuracy may be dubious.

What would make sense is switching from our own dvb scan tables to the upstream version so we no longer need to maintain that.

The TVH scan-tables are 23 commits ahead and 59 behind crazycat69's version, although the actual differences are not that great. However upstream hasn't been updated for over two years and he may not be able or willing to support merging the two (especially if his advertised location is correct).

I wonder whether it is actually necessary to have these detailed mux tables; on the dvb-t and dvb-s networks I've used, tuning into one mux automatically collects the details of all the others. Just have a cut-down table with one key mux per satellite / transmitter and ask the user to tune into that to get the rest.

Dave Pickles wrote:

What would make sense is switching from our own dvb scan tables to the upstream version so we no longer need to maintain that.

The TVH scan-tables are 23 commits ahead and 59 behind crazycat69's version, although the actual differences are not that great. However upstream hasn't been updated for over two years and he may not be able or willing to support merging the two (especially if his advertised location is correct).

I wonder whether it is actually necessary to have these detailed mux tables; on the dvb-t and dvb-s networks I've used, tuning into one mux automatically collects the details of all the others. Just have a cut-down table with one key mux per satellite / transmitter and ask the user to tune into that to get the rest.

compare to https://git.linuxtv.org/dtv-scan-tables.git/
submitted PR and it was refused
https://github.com/tvheadend/dtv-scan-tables/pull/72

The linuxtv tables seem more up-to-date but are not completely correct - mux 10773H on Astra 28.2E is shown as DVB-S when it was switched to DVB-S2 six months ago (my PR #136).

However the layout of the tables is different. For example the Astra 28.2E constellation is listed in a single file in the crazycat69 and TVH tables, but linuxtv has separate tables for Astra-2E, 2F and 2G satellites. I'm not sure that TVH would work with these, unless it parses the satellite position from the filenames.

I find it much simpler, certainly with Astra 28.2 to start with a blank network, provide one known working mux and starting a scan with the option “Add New Muxes”. This way I see 87 newly found muxes instead of the 120 muxes provided in the predefined muxes list. A lot less housekeeping to be done when you map services.

This FR https://tvheadend.org/issues/4379
explain all scan table needs in one option

Right now basically all build are broken for various reasons. I won't merge anything until someone has time to do adapt Github actions to test all PRs on all targets so such issues can be noticed before merging. I am tired of code that makes it in and then randomly breaks some targets....

One thing that would help lower the threshold, is to switch to gulp github discussions. Which means things get more localized more together. Same with issues. I'm far from a fan of github (hate it with passion is more accurate), but you can't deny that since we ARE already using github; we should also leverage issue and discussion features, which allows for cross-linking. Having 2 places to see things happen is painful, having to signup to redmine, is painful.

On the upside, the github discussions could be focused ONLY on developer related topics/discussions.

If one the other hand, some developers refuse to use github (which I can totally get) we should (have in the past?) moved to gitlab

Delta Mike Charlie wrote:

That being said: What follows is my, admittedly unsolicited, opinion. No offense is meant, none will be taken.

Heh, I personally value your very product-manager like input. The general problem isn't the input or the idea's behind it; it's pure raw man-power. Who will do all these steps that you suggest? That's where the first issue starts from.

Drive-by developers that offer a new feature is great (I do it too). The long-life and risks of TVH is all based on the lack of maintainers, reviewers even testers. Writing automated pipelines is a great start for example, which would help; but who will do it?

So what is the real risk of TVH? That the current maintainers will burn-out/stop caring and leave the project, and it just rots and dies.

(What I just wrote above however, centralizing on github or something) could help in making it slightly easier to maintain, at least in a while from now ..)

What would make sense is switching from our own dvb scan tables to the upstream version so we no longer need to maintain that.

Funny you say that. I am the official maintainer of the upstream dvb-scan tables. I stopped (ish, as nobody contributes) them for the most part, because your downstream mirror was more active. Obviously I don't have the bandwith if lots of MR's start popping up again but splitting them off of tvheadend would a) force people to submit them upstream, and b) remove the (official) burden here.

I'll restore the dvbscan tables github repo if that helps

Btw, doing releases, we can automate, I've written multiple scripts for gitlab that manages this, might be possible to port it to github with some effort. But lets not even worry about the releases, a release, in the end is just a branch/tag that 'we consider stable' and allows us to do hotfixes on a release without affecting master. But the churn on master is low, so 'meh', but not a problem.

But if these other resource-issues do not get addressed, it'll be moot anyway ...

Dave Pickles wrote:

I wonder whether it is actually necessary to have these detailed mux tables; on the dvb-t and dvb-s networks I've used, tuning into one mux automatically collects the details of all the others. Just have a cut-down table with one key mux per satellite / transmitter and ask the user to tune into that to get the rest.

that's only true for some streams. But a) you still need the initial frequency, which comes from the dvb-tables; b) your network needs to squirt these out on a channel (that needs to be in the dvb-tables).

Oliver Schinagl wrote:

Dave Pickles wrote:

I wonder whether it is actually necessary to have these detailed mux tables; on the dvb-t and dvb-s networks I've used, tuning into one mux automatically collects the details of all the others. Just have a cut-down table with one key mux per satellite / transmitter and ask the user to tune into that to get the rest.

that's only true for some streams. But a) you still need the initial frequency, which comes from the dvb-tables; b) your network needs to squirt these out on a channel (that needs to be in the dvb-tables).

Not all SAT positions offer NIT/FastScan or whatever automation for scan with TVH except manual frequency add.
13E and 19.2E are not only sat positions with people use

Oliver Schinagl wrote:

The general problem isn't the input or the idea's behind it; it's pure raw man-power.

I understand that now. Thanks.