Tvheadend

I really like tvheadend overall, but there are some issues (some of which I may file as bugs/feature requests if no-one else has) that are actually quite important for the developers to look at and I'll list them below in no particular order. Feel free to comment on any of them you like...

• I worry about tvheadend being a single process model. I've been able to crash some releases completely and that takes out everything (stops recording, EPG is gone, can't stream anything). I much prefer Apache's idea of having a relatively simple (but rock solid) parent process that runs child processes that it monitors and will spawn fresh ones if they die unexpectedly. Are there any plans for this? I guess parts of tvheadend would have to be split into separate processes, but this might benefit multi-core machines anyway.

• Why is the TV grabber for XMLTV fired up every time tvheadend is started, rather than every, say, 12 hours that I've configured it to run? Shouldn't tvheadend consult some sort of "last run timestamp file" for the grabber on startup and not run the grabber unless 12+ hours have elapsed beyond the timestamp of the last run? It's an intensive perl script that can use 5 minutes of CPU time solid, just when I want to record or view something!

• Even a release I built from a repo download on 5th June still has a critical bug in Ubuntu 12.04 (64-bit) to do with recordings made of BBC One HD programmes in the UK (the HE-AAC audio is dropped, usually in the middle of the continuity announcement and for the rest of the recording too). Note that live TV streaming of BBC One HD is fine - it's only recordings that have this quite bad audio issue.

• The Web interface is quite slick, but it doesn't remember any of the column changes I make in, say, the Digital Video Recorder / Recorder schedule section (e.g. I remove the Episode and DVR Configuration columns because both aren't needed, but in my next browser session, these are forgotten and the columns are back :-( ). I'm wondering if a cookie could be used to store them (including stuff like ascending vs. descending order).

• The United Kingdom (UK) data for digital terrestrial transmitters is extremely out of date. The whole of the UK is now post-digital switchover and yet the multiplex frequencies are pre-switchover (i.e. anything between a few months and several years out of date). This means you have to a) find the name of your transmitter, b) look it up on Wikipedia (which does have the post-DSO frequencies) and c) manually add 6 or so multiplexes yourself. Considering the Astra 28.2E satellite stuff is "perfect" for UK users, why are all the Freeview UK frequencies utterly wrong?

• Talking of entering multiplex frequencies manually (Configuration -> TV Adapter -> Select tuner -> Multiplexs -> Add muxes manually...), why isn't "Auto" the default for all fields that have that option instead of being blank by default? If the 6 fields (Constellation: through to FEC Lo were Auto, that would mean UK users would just to set the Bandwidth to 8 Mhz and then enter 6 frequencies (clicking Add after each one).

• It would be nice if there was some way to detect non-free (i.e. encrypted) channels and have a tickbox option to exclude them all in one fell swoop. I believe Mediaportal can do that on Windows.

• Are there any plans to implement Accurate Recording (whilst still keeping the ability to pre/post-pad recordings) that's part of the Freeview standard in the UK? This would be a very useful addition, particularly for long overruns of programmes (e.g. live sport).

• Are there any plans to transcode recordings/live TV on the fly (i.e. not by running a command when the recording has finished, but actually passing the stream through a transcoder first before streaming it or saving it to a .mkv file)? For those us with beefy enough CPUs (the CPU would have to be benchmarked to see if it could do it in real time - perhaps using multiple threads for transcoding?), this would be great. My experiments have shown that you can half the size of the .mkv file by transcoding it with carefully selected parameters.

• There is no disk information shown anywhere in the tvheadend interface. It desperately needs a stats page for its recording area:
  - Number of recordings
  - Total space used by recordings (both as a MB size and as a %age of the total recording area space).
  - Average recording size
  - Space remaining (MB/%age again)
  - Number of recordings of avg size that will fit in space remaining
  There should be warnings issued in the Web interface when the space remaining is low (e.g. <5 new avg. size recordings can fit)

• On a similar note, show the MB size of each completed recording in the Recorder schedule tab! I can't believe that you have to search the tvheadend server's filestore to find this important info out :-(

Don't worry, I've got an even longer list for the XBMC front-end (like how I can crash it easily just using its video controls or how it doesn't peridocally rescan for the tvheadend server if the server isn't running when xbmc is started to name just a few issues).