I already reported bugs saying that TS support was barely usable fornormal end user in ".2 and they have been immediately closed as many of the old tvheadend 2.12 bug list. Reason for closing its in => 1) mistaken 2) Nobody cares about HTTP and 3) TS is there to please some extra terrestrial people...
So I will publicly restate here what I already said to maintainers in private messages. I hope some people wanting TS will support this request.
Let's start by a brief TS status on 3.2:
1) To record as TS you should select a
media container called
pass-through!!! This is not a container name and is misleading as what comes from the dvb adapter when selecting a muxes usually contains several channels and should be remuxed by removing packets non belonging to the relevant program, and then you also must regenerate the PAT/PMT and publish them periodically,
2) To stream as TS, well depending on the page you go to, you can either by an undocumented feature force TS streaming or you simply can't when the page uses javascript to open a vlc windows. Very user friendly. Second if you look at the various links given in various pages for individual channels you will notice that they are not homogeneous among pages,
3) TS streaming requires more CPU than mkv streaming, which is hardly understandable from a technical point of view
So from a user experience point of view as well as from a code factoring point of view (various link and means). There have been patches integrating TS on 2.12 that did a slightly better job for recording (container was called TS, possiblility to select container extension per container, an additional link was added where the javascript code was calling vlc directly), and TS streaming did use considerably less CPU than MKV streaming as expected.
I think http streaming would deserve a front page like EPG/PVR called Live TV whith individual links, m3u, and a MKV/TS selectable option.
Now some consideration about MKV vs TS. MKV is a good format, very rich and generally correctly supported forrecorded material. It has never been designed with streaming in mind because the header contains information that are available only when recording is complete. The lack of such header information render this format totally inappropriate for watch and records, time shifting, trick modes and so on.
Ts in comparison has been designed for broadcast and supports watch and records, time shifting, trick modes but you cannot add on the fly metadata,... In addition, as DVB stabdard requires it, all TV oriented devices (TV, IP stb, DMA, ...) know how to play TS and most of them handle http streaming. So for retail devices, TS and HTTP streaming are here to stay even if new adaptive streaming standards are popping up (HLS, DASH, M$ smooth streaming).
Using TS and HTTP make it easy to stream to a connected TV channels that are not directly available on your DVT-T/Sat plug (channels with CAS and no adequate CI+, IP TV, ...). Until I see HTSP in an embedded device, I still think HTTP is the best protocol for delivering the TV streams to off the shelves products. At least it enables to stream to VLC on android and IOS without installing anything special beyond the player.
Regarding the recordings in MKV, I also do think that requiring HTSP to see/play them is fairly restrictive and I prefer to expose them via DLNA. Again, then I can see them nearly everywhere without installing anything. All connected TV do support DLNA and can retrieve recordings directly.
So yes there is a life beyond HTSP and considering XBMC is the only way to use tvheadend is probably the best way to make sure it will vanish in a not too distant time frame.
I do use tvheadend and like it but I think there should be a roadmap to extend its usability outside PC world. HSPT as a protocol and MKV as a streaming container format are just non-sense for this goal.