For a month ago i started trying TVHeadend, because after 3 years a happy user of MythTV I liked to use something else. A more lite program whith buildin descrambling solution and doing what it should do for a PVR.

I started using the latest unstable version, because of the better DVB configuration and i like to have always the latest software Also i use the latest XBMC with the default plugin (not the "tvh" one).

After some disapointments, mainly bad configuration, we (the whole family) are swapped to the TVHeadend / XBMC combination. Because I'm running with the latest versions, sometimes the system is doing unexpected things and also the webinterface is not always showing the right things, but I have good faith that these unwanted features are going to be solved.

Actualy the project is fascinating me, and i like to be more involved in making this project better. I'm a bit worry about the fact that there is a lot of talking about the future of this project. It would be good for the project that people now involved stay involved, perhaps in another role?!

It's more that this should be a community effort, and the community is simply too small. He needs more people to help with the design, the coding, the documentation, the support, and that's really the call - C/C++, Javascript, HTML, interface design, analysis experience to say "actually, we can do this more efficiently like <this>".

Apparently, he has a job, a family and a real life outside of tvheadend. Damned inconvenient

I'd like to also thank Adam (and Andreas) for their work on TV Headend.

I am quite time-poor, and have a mish-mash of skills (jack of all trades - master of none), but will see what I can do to help.

TV Headend has been incredibly useful for me - and the simplicity with which you can compile and run it on new clients (Pogoplugs, Go Flex Nets etc.) is amazing. The new DVB interface handling system has obviously required a lot of work, but is a great addition.

IMHO what is really stifling tvheadend's improvement, it that it tries to do too much in C and is therefore VERY hard to understand/extend. Tvheadend would truly benefit from a conversion to C++ where the inheritance model would greatly simplify the understanding of the code.

If someone wants me to start a conversion process to C++, i would be happy to do that, but I don't want to start working on a project and have the code ignored. I've already (99% complete) converted the comskip code.

Also of interest is another of my projects to leverage the hd-homerun in combination with tvheadend. This is a C++ conversion of Silicon Dust library/utilities and hdhr-user.

An interesting feature of this code is that it can properly handle the hdhomerun prime's to tune in encrypted channels in conjunction with tvheadend (although I have to patch tvheadend just a bit to get it to do a single program per tuner).

@cbxbiker61 Here I would have to disagree. C is no harder to understand than C++ (want an example, try reading something like XBMC code without your head exploding!), a good software engineer realises that language is mere syntax, it's the design that makes things easy or difficult to understand. The TVH design, being OSS, is not the best, though its far from the worst I've seen. I admit some of the recent additions could already benefit from re-factoring (having been designed on the fly, sue me!). C++ provides very little benefit IMHO, yes some minor syntactic sugar (as with most higher level / OO languages) but anything that can be done in C++ can be done in C, with only minimal extra keystrokes. To be honest, I prefer OO in C to C++ these days.

I think if you want a migration to C++ you should consider helping out the tvdaemon project, they forked from TVH about the same time I started working on it. There original plan was to start a migration, then it turned into a full scale rewrite. I told them they were over optimistic suggesting they could have a bare bones working solution in 2-3 months, 24 months on, I don't really see them anywhere near that (though I believe the project is not dead). Certainly a migration to C++ would be possible, but you'd basically have to rewrite the entire code base (just re-doing the DVB/Input code has taken me 6-8 months). I think it very unlikely I'd want to be involved in that, since I can see very little benefit to the project as a whole. Maybe it would open it up to more people, certainly there is a tendency for educational institutions to turn out programmers that know C++, and think C is some sort of black art, but I'm not convinced myself.

With regard to HDHR one of the big things I did in the DVB rewrite was try and create (I say try, I think I could have done better, but I lost energy and focus) a more flexible framework into which other input systems could be added. Of course, for native HDHR support to exist, someone would have to step forward and do the work. And of course, thankfully the guys at SiliconDust have at least been sensible about writing there lib in C (rather than C++) because it offers greater flexibility for user applications. No doubt actually adding another input system would highlight some issues with what's been done, but I doubt its anything insurmountable.

C++ allows programmers to switch between object oriented and procedural code in the same program, because it's assumed to be "extented C". But it's not good idea - a lot of mess, compare C++ and C# for example. C# is clean, C++ is mess only with a lot of strange constructions that can get confused even the best programmer.

@adamsutton, it's funny you mentioned xbmc as code that makes your head explode, since I think Xbmc's code is relatively well written considering the number of contributors and the complexity of the project as a whole. There are a few times I've had to "look" for something and it has been a bit more difficult than necessary, but that was not due to C++ itself, but more a design issue. Xbmc would be totally unmanageable if it were written entirely in C.

C++11 is way beyond the C++ of 10 years ago, and anyone that may have been put off by C++ in the past really should re-investigate the new features that make it more robust and faster to code.

@giaur, I disagree that "C++ is a mess...that confuses even the best programmer".

Yes, backward compatibility with C, this is the worst thing. Compare to C# again - lambda expressions, simpler and cleaner syntax etc. C++, I don't really know - it's object oriented or partially object oriented. C++11 introduces some new stuff but in any case, I don't like c++.

Something about tvh future... do you plan to add some new functionalities? I've asked a long time ago, for example - full epg support (with all non standard epg headers/strings) and I remember it was confirmed to be not supported yet.

There is one missing thing. Configuration->Channel/EPG. I preffer custom channels order but to order channels I need to edit Number for each channel. There should be "Move Down" and "Move UP" for each channel for changing channels order more eaisly.

Also, I don't really understand how defaulit sorting works. I think channels should be sorted by LCN, but id doesn't happen and some channels are added even without any number. "Number" column should be logical channel number for each channel, as assigned by broadcaster.