Why has devlopement nearly staled?

Ericv2

Since the "project news" discussion is not open to everyone post and anyway information there is quite old, I will use this forum to ask my question. What is currently ongoing with project development?

Some facts : On github master branch, the last commit is dated Nov 13, 2024. A few commit are on alternative branches but not much. There are 37 PR patiently waiting for approval or commit including dangerous one like one to fix README.md to correctly access this forum.

Can someone post an official statement on project news? Thanks

chewitt

Tvheadend seeks to support as many build targets as possible. The upside of that is folks with a vintage DVB card needing a prehistoric kernel on an ancient version of Ubuntu can still install and run Tvheadend. The equal downside is that sometimes jumping-through-hoops and reworking of CI is needed to keep everything building, and late last year we hit one of those roadbumps; and it's coincided with a busy period for key staff (work, life, travels, etc.) and so it's taking time to get fixed.

Once CI is up and running again (or we've finialised decisions to drop specific builds) we'll merge the backlog down and things go back to normal. So nothing has nearly stalled, and there's not really any need for news posts as "something broke, we're fixing it, it's taking a while" isn't particularly newsworthy. Given the often glacial pace of normal development, it's not particularly abnormal either.

"nothing to see here, move along please"

Ericv2

chewitt

Tvheadend seeks to support as many build targets as possible. The upside of that is folks with a vintage DVB card needing a prehistoric kernel on an ancient version of Ubuntu can still install and run Tvheadend.

People having a working install on such vintage system are unlikely to install new version except if something breaks. And reinstalling on new PC with recent system is likely to break because of obsolete packages used for build (duplicating code via static library build is a bad practice for bug tracking especially with ffmpeg and should be exception).

and it's coincided with a busy period for key staff (work, life, travels, etc.)

Adding people with more time and commit rights even if less knowledgeable can help for that unless you want to keep absolute control. I've seen dozen of obvious fixes pointed out by people or by sonarbot that are obvious.

Once CI is up and running again

Any possible target date? (and do not use the usual "it is open source after all" please).

So nothing has nearly stalled

I see no commit on master for six month. I call that almost stalled. Your view appears to be different.

Never mind.

Flole

Adding people with more time and commit rights even if less knowledgeable can help for that unless you want to keep absolute control.

It's not about clicking the merge button, that is done in a matter of seconds. Even without merge rights you can

Review PRs and post comments
Open PRs with improvements you want to see

Both is helpful and usually the way it goes is that someone does one/both of those things and then is given the necessary privileges to do commits, and not the other way around.

I've seen dozen of obvious fixes pointed out by people or by sonarbot that are obvious.

Then please open PRs for them. Also you can encourage people to open PRs instead of "pointing out fixed". Sure, they won't be merged until the CI is fixed again (if you see something obvious there for the issues that are still a problem please open a PR against the fixci2025 branch) but they can easily be rebased and merged once the CI is fixed again.

Ericv2

Flole

Then please open PRs for them.

Looking at the number of open PR or closed bugs without sound or polite explanation is unlikely to persuade people to take time to open new bug and spend time to provide complete debug info if they fear it will be a waste of time.

Existing PR with fixes are already pending. Fixing the CI build and PR backlog is probably the most important task at this point.

And for the record, the last one I tried to open was for ffmpeg 7 support missing as compiling on debian unstable failed (soon what was august 2024 unstable will be stable trixie) . It has been immediately closed by a "not a priority or not a target" I do not remember exactly. Later someone else opened a similar one, and has gone a lot further in term of time investment as he has been providing code to fix it. There is now a dedicated branch and a lot of PR pending since august 2024... Not really motivating.

Anyway, I expressed my view on the actual development speed/methodology. I follow tvheadend development for quite many years (2013) and have it working on multiple machine and multiple tuners with kodi frontend and android cleints. I send obvious fixes to the developer that build the debian package I use (not the one provided by the project itself as it does not follow debian rules (static libraries)) . It is much more efficient for me to get the code I need pulled in. I put my effort where I think it is worth. Sorry.

Flole

Ericv2 And for the record, the last one I tried to open was for ffmpeg 7 support missing as compiling on debian unstable failed (soon what was august 2024 unstable will be stable trixie)

You commented on a bug report as far as I can see, which was closed as ffmpeg 7 support is simply not there yet, which means its not a bug that it doesn't compile with ffmpeg 7. I wasn't able to find the PR you mention, only older ones from what I assume is your old account.

Ericv2

Flole

You commented on a bug report as far as I can see, which was closed as ffmpeg 7 support is simply not there yet.

Well Yes but you may also look at tvheadend/tvheadend1715

It has indeed been closed as not a bug as I wrote. and reason is "You are using a modified version"! Yes I had to because ffmpeg6 was indeed not installed on my system and I have to change default config to avoid static libs...

For me, when code does not compile on widely used Linux systems using default libraries, it is a bug but I understand one may disagree and say it is a missing feature. See https://packages.debian.org/trixie/ffmpeg (testing = trixie not even unstable or experimental) or https://launchpad.net/ubuntu/+source/ffmpeg/7:7.1.1-1ubuntu1 (Plucky = 25.04).

It may be fine for some devs to keep old code that runs with ffmpeg 4,5,6 on a Linux 4,5,6 kernel but I would prefer code that require at least ffmpeg 6 and works with ffmpeg 7 and a 6.x kernel (october 2022). At least, when resources are scarce, I find it is more efficient to spend energy to go forward and prepare the future than trying to maintain compatibility with old, unsupported system especially when work is (for me) wasted on the CI to maintain the build infrastructure for theses obsolete systems instead of enhancing actual code.

People needing old code because of dependencies can use git to get old releases that are compatible with their system.

At least we managed to express our different opinions politely. Already an achievement.

Flole

Ericv2 especially when work is (for me) wasted on the CI to maintain the build infrastructure for theses obsolete systems instead of enhancing actual code.

It's not about obsolete systems, that was a rather easy fix. Right now it's an issue with aarch64 in certain configurations. Ubuntu 22.04 is nowhere near obsolete, same for Debian bullseye and even the most recent raspberry pi os. If we would be talking about some 10 year old end-of-maintenance OS I would see your point, but killing recent and still supported and in-use OSs might work short term but soon people will show up complaining it doesn't compile on Ubuntu 22.04, and you can't just say "we don't support that anymore". And then it's time to pick up the pieces which will take significantly longer than having it done correctly from the beginning. And that's what's really important when trying to save resources.

Ericv2

Flole

Ubuntu 22.04 is nowhere near obsolete, same for Debian bullseye

That does not imply tvheadend has to still support ffmpeg 4 (The Jammy Jellyfish aka 22.04) and ffmpeg 5 (bookworm). For system that does not meet the minimum requirements, you can always use static build. What is the point of static library build support if not that?

In addition CVE fixes will not be backported ad vitam for ffmpeg and probably some old distrib security fixes at some point in time will have to move to a nearly up-to-date ffmpeg version.

If you want waylan hardware decoding support, hardware decoding of AV1 for vdpau, you will need more recent version of ffmpeg than ffmpeg 4 anyway.

And that's what's really important when trying to save resources.

I maintain obsoleting ffmpeg and other major external dependency software version (ffmpeg being a major component for video stream handling) and not trying to support everything would save resources.

People having to cherry pick patches as they need to make tvheadend work on their system is a waste of resources as well (globally) and also impacts project image.

Thanks again for this discussion.

Flole

Ericv2 That does not imply tvheadend has to still support ffmpeg 4 (The Jammy Jellyfish aka 22.04) and ffmpeg 5 (bookworm).

Removing support is more work than just leaving the old #ifdefs there. It's also not tested by the CI, only the static ffmpeg stuff is tested, and that broke for some reason without changes on many platforms late last year.

Ericv2 People having to cherry pick patches as they need to make tvheadend work on their system is a waste of resources as well (globally)

You mentioned that you send patches to a version of Tvheadend maintained by a third party. I'm a little surprised someone is going through the effort of maintaining such a fork.

Ericv2 and also impacts project image.

Well what should I do instead? Say "sorry guys, the raspberry pi is no longer supported"? I don't have any stats but I'm quite confident that a significant amount of users are using it.

DeltaMikeCharlie

Please stop this.