Tvheadend

Eric,

I just want to clear a few things up, I wouldn't want people to get the wrong end of the stick.

Firstly your comments were not "private" and were in a public forum, however they were not in the most obvious location for public discussion which is why I suggested you'd be better bringing things to the forum first. But for reference, in case people want to know the relevant issues and see the topics they are here #1280, here #1283 and here #1285.

For further background you can also review comments on the original PR reports; here https://github.com/tvheadend/tvheadend/pull/38 and here https://github.com/tvheadend/tvheadend/pull/71.

The Tvheadend developers all work in their spare time and for no financial gain (other than occasional donations made at the users discretion if they feel they want to support the work we do). We do our best to cater for as many people as possible, but ultimately our efforts will always focus on those requirements that most affect ourselves and the majority of our user base. Sorry that's just life!

If doing so results in the death of the project then that would of course be very sad, but c'est la vie.

Of course if others want to offer help and support for areas they are interested in we're more than welcome to accept it and do our best to integrate others work. I won't go over old arguments about the fact lots of PRs were left languishing for a long period, because hopefully most sensible people are aware this was due to the fact Andreas stopped actively developing Tvheadend and we now have a new team who are doing their best to actively engage teh community.

Anyway I think I've expressed my own views on this subject enough in all the above material, I will dip back in to this thread as and when people make comments I feel need following up.

But for now I turn the table over to everyone else. Consider this a chance to air your opinions about the direction of Tvheadend's development and I promise I will listen to what people have to say.

Regards
Adam

Adam Sutton wrote:

Firstly your comments were not "private" and were in a public forum, however they were not in the most obvious location for public discussion which is why I suggested you'd be better bringing things to the forum first. But for reference, in case people want to know the relevant issues and see the topics they are here #1280, here #1283 and here #1285.

Mots of the discussion behind MKV vs TS, HTTP, DLNA vs HTSP I was reffreing too have been discussed with you and john in private email exchange that haven't been made public as far as I know. I wanted to sum them up here as what I see for TS integration is neither end user proof nor long term proof for me.

The Tvheadend developers all work in their spare time and for no financial gain (other than occasional donations made at the users discretion if they feel they want to support the work we do). We do our best to cater for as many people as possible, but ultimately our efforts will always focus on those requirements that most affect ourselves and the majority of our user base. Sorry that's just life!

I know. It is even for this reason I preferred to decline your offering to not slow down other people that have possibly more time than me. But, because of working on spare time, you should be even more focused and concentrate your efforts in a future proof direction.

But for now I turn the table over to everyone else. Consider this a chance to air your opinions about the direction of Tvheadend's development and I promise I will listen to what people have to say.

Thats the goal. I may be wrong and for sure I would prefer to be able to send Pull Request rather than just arguing. in the past all I did was debugging most of the time and integrating other people works on my spare time. Hardly more.

Eric,

Sorry I didn't include those threads, as they were indeed private and didn't want to divulge a private conversation without prior consent. I'll take this to imply you give consent and have attached them. Maybe they will help enlighten people about the various discussions we've had in the past.

Regards
Adam

Eric,

I can only apologise, I thought you were concerned that things were being discussed in private that you felt should have been in public.

I have of course removed the files and again apologise if any offence was caused by people having access to your private correspondence. Though it's a shame as I think it's useful background information about the views from each side without us having to re-hash things.

Though I guess there is plenty of other discussion that is already in the public domain that people can refer to for my opinions.

Regards
Adam

Adam Sutton wrote:

Eric,

I can only apologise, I thought you were concerned that things were being discussed in private that you felt should have been in public.

No I was not. I just though it was time to reassert my concerns in a more polished way to share them with more people now that you were about to release a first version for public consumption. Consider them as a wishlist, feature request discussion when setting up possible goal for future versions.

I have of course removed the files and again apologise if any offence was caused by people having access to your private correspondence. Though it's a shame as I think it's useful background information about the views from each side without us having to re-hash things.

No offense but as a rule you shall always ask people their explicit consent before publishing private data. May be we can publish some selected extracts if you think they really deserve. I do no more have them available via IMAP anymore right now (expunged Inbox to local storage at home) so cannot go through them right now but I still have them.

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 would say the reverse, the only thing keeping tvheadend alive is the integration with XBMC.

Cheers, Des.

Des G wrote:

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 would say the reverse, the only thing keeping tvheadend alive is the integration with XBMC.

Cheers, Des.

VDR + streamdev was there for even longer I bet. Did this prevent VDR relative decline? No. The rant against VDR are 1) configuration nightmare, 2) streaming capabilities and indeed integration with a player. Xine been one used. On the other hand, you should consider:

1) There are probably more XBMC windows users than XBMC linux users. tvheadend does not run on windows and they are better PVR alternative anyway on windows,
2) There is still no official XBMC with PVR build-in. So its mainly for geeks for the moment. Its not ready for general consumption IMHO
3) tvheadend being GPL V3 it will hardly find his way in embedded devices were linux indeed dominates,

--eric

I'm fairly new to the world of DVB so I can't comment on stuff outside of TVH. But I will add a few points, just to keep things balanced.

1. That's a very big "probably", there are very few stats for XBMC usage, most of what does exist is very out of date. Plus with the growing popularity of projects like OpenELEC and the proliferation of small but capable ARM boards (such as raspberrypi and others) I wouldn't count on Windows having a majority (if indeed it does) in the foreseeable future. That's not saying there aren't pro's / con's on both sides.

2. I'm not going to argue about TVH running on Windows, nor do I care. It doesn't, period.

3. Depends how you understand things. PVR is now part of mainline code (has been for some weeks) and will be in the Frodo release. The addons aren't for a variety of political and technical reasons, but this is a minor issue. Frodo will be out in the not too distant future. I'm not sure if the release schedule has been publicised yet so I can't say any more than that.

4. That depends if you have an incredibly narrow view of things and what your definition of embedded is? GPLv3 does not stop you from using TVH in an embedded product as long as you adhere to the restrictions on openness (i.e. the user must be able to freely update the system). Indeed, I consider OpenELEC (on any of the supported archs, be it rpi ARM or an m-ITX ION) an embedded product. Not to mention the many ARM based NAS boxes that people install TVH on.

Personally I don't care if TVH can't be used in STB's that's not the target market. Most people interested in using TVH are doing so to avoid using a STB (I know I am). Also I'm privy to information that you're not about future projects that may indeed make use of TVH in commercial (embedded) products.

Regards
Adam

Adam Sutton wrote:

and the proliferation of small but capable ARM boards (such as raspberrypi and others) I wouldn't count on Windows having a majority (if indeed it does) in the foreseeable future. That's not saying there aren't pro's / con's on both sides.

Linux is only 2% of PC market share if 50%!!! of users use XBMC, that makes less than 1% of PC share.

A vast majority of ARM device do run android, until XBMC is widely available there... I tested Xbian and rapsbmc. Live Tv does not work on HD at the moment and for SD you need to buy MPEG2 licences... BTW there is a bug in config when using cross compiler as mmx and sse2 are enabled (on arm!! Its a bug in gcc but anyway).

4. That depends if you have an incredibly narrow view of things and what your definition of embedded is? GPLv3 does not stop you from using TVH in an embedded product as long as you adhere to the restrictions on openness (i.e. the user must be able to freely update the system). Indeed, I consider OpenELEC (on any of the supported archs, be it rpi ARM or an m-ITX ION) an embedded product. Not to mention the many ARM based NAS boxes that people install TVH on.

I know few NAS that enable to install a complete system. Only some enable to install custom packages. And you need to have the correct DVB-T driver which most of the times is problematic as kernel are really old and do not offer support!

Personally I don't care if TVH can't be used in STB's that's not the target market. Most people interested in using TVH are doing so to avoid using a STB (I know I am). Also I'm privy to information that you're not about future projects that may indeed make use of TVH in commercial (embedded) products.

I agree with this one. But I would liek to put tvheadend on a NAS and avoid a PC entirely :-)

-- eric

It's really not worth arguing over statistics. They are so easy to break without hard and fast numbers. For example a LARGE percentage of Windows PCs are corporate, so you have to first rule them out. Most Linux PCs will count in both camps (as they will have been sold with OEM Win license) so need to rule them out. A Large percentage of Linux PCs are server so you need to rule them out (depending on which base stats you're using). Home media centres, while gaining popularity are still the realm of AV enthusiasts and geeks (for which Linux typically has higher relative share compared to overall numbers). XBMC downloads are difficult to count for Linux since usage is spread across many distro repos, plus you have to discount possible re-installs (in both).

I'm not arguing which has the highest share (it probably is Windows), just pointing out the numbers are too easily bent to which ever way you like.

I can't speak for Android, but certainly XBMC is beginning to take traction there but its early days. And again I'm aware of several commercial projects that are not currently in the public domain.

Can you please properly clarify your statement, "Live Tv does not work FOR ME on HD at the moment". You're indeed right that most users need an MPEG2 license for SD, though again not all (some countries are fortunate to get all DVB content in H264). But an MPEG2+VC1 license is only £3, so hardly a large expense. For me I'm able to watch both DVB HD (always have) and now SD (thanks to the MPEG2 license) just fine. I'm not saying it doesn't need optimising/polishing. But it works for me (and many others). The only issue I have is HD movies with DTS tracks, though the HW supports decoding (including FW/SW support) and it probably won't be long before licenses are available to the general public.

I cannot comment on the relative kernel support of the various NAS boxes (as a consumer that's something you should take up with them), but that doesn't preclude you from being able to achieve it. In fact several of the changes/fixes I have made were at the request of the NAS community (mostly Synology and QNAP I believe).

Regards
Adam

Just some more ideas:

1)for live, beside the fact that for non scrambled Live stuff you do not need anything, I think there will be soon a PVR driver that will enable to use the tuner directly or even descramble via OSCAM (VLC, kaffeine, mplayer already support that). In that case nobody will need tvheadend for live.The epg via xmltv can be bundled too. So I do not think for live, it will be a long term driver...

2) There are also pseudo remote tunner manager ( more or less like dvbhdhoerun but for regular tuner called vtuner http://code.google.com/p/vtuner/) that will enable to pilot remote tuner from XBMC and see live.

Adam Sutton wrote:

Can you please properly clarify your statement, "Live Tv does not work FOR ME on HD at the moment".

Sorry if this was unclear. XBMC does not work for displaying Live HD content from tvheadend when they run both on raspeberry pi. Its a XBMC problem as I can display the live stream from tvheadend running on the pi on XBMC PC and I can display HD content via DLNA via XBMC on the pi. Just the combination does not work. I have seen some fixes going in late september but did not had time to rebuild a full XBMC (crosscompilation on a pi to make real debian package is a pain, and compiling locally is just too slow).

Eric,

1) Great for one particular use case, useless for many others. It may well happen, but it needs someone to do it.

One of the many benefits of TVH (and one that many users make use of, including myself) is that by centralising the DVB decoding on box with large storage (such as NAS box) and dual/quad tuner they can then have many clients sharing the kit. Obviously it depends on your personal use cases, how many tuners, how many simultaneous users, but its a very common use case for TVH.

2) An interesting project, but generally I think its a different target market (though some obvious overlap).

3) Indeed, there are definitely issues with running TVH on the pi for DVB, most of these have been surrounding the poor USB performance (which is obviously the only route in for DVB tuners on pi). The problem was related to excessive FIQs generated by the USB drivers, they have improved this somewhat recently. But I don't have any USB sticks, nor would I personally want to put TVH on my pi. So I can only go by the feedback I'm given.

Personally I use OpenELEC for XBMC on my pi, though I don't think the official beta's currently include PVR support. There are some semi-official ones about, plus TVH is currently out of date (though that will change soon). Building own OE isn't difficult, but can definitely be slow.

Adam

Adam Sutton wrote:

One of the many benefits of TVH (and one that many users make use of, including myself) is that by centralising the DVB decoding on box with large storage (such as NAS box) and dual/quad tuner they can then have many clients sharing the kit. Obviously it depends on your personal use cases, how many tuners, how many simultaneous users, but its a very common use case for TVH.

I agree with this one, but, again, would like to avoid the PC near the TV. Using http, ts instead of mkv and DLNA I can/could :-)

3) Indeed, there are definitely issues with running TVH on the pi for DVB, most of these have been surrounding the poor USB performance (which is obviously the only route in for DVB tuners on pi). The problem was related to excessive FIQs generated by the USB drivers, they have improved this somewhat recently. But I don't have any USB sticks, nor would I personally want to put TVH on my pi. So I can only go by the feedback I'm given.

I already have the fiq patch and the overclocking code, the tuner is on a powered hub otherwyse you get not enough power supply, raspbmc has a preliminary XBMC version with PVR support and tvheadend build in if you want to try...

1) I think the problem with DLNA is that no one is willing to do the work, the current TVH devs (myself included) aren't interested. This is both because its a horrible spec and because none of us have a requirement for it. So unless someone that actually needs/wants it steps forward to do the work I don't see it happening.

HTTP+TS streaming is there, we can debate the performance/configuration etc.. Performance does need some work (some locking issues), but its certainly usable, and configuration will improve over time.

2) No thanks, I tried raspbmc, it was too painful. I had to download something, stick that on my SD card, plug that in to pi then it tried to download something else. That hung horribly and was taking ages anyway and that was it for me.

Contrast that with OE: download file, run script (to copy/install to SD), plug in, boot and go Took all of 5mins (excluding download). I now compile my own OE images, just because for obvious reasons I need to keep up to date with some of the development.

To be honest I did OE first (as that's what I already use on my ION), the raspbmc was just for curiosity, so the early pain meant it was never going to get a second look in. Plus for me its better to have identical software on both of my XBMC boxes.

Adam

Adam Sutton wrote:

1) I think the problem with DLNA is that no one is willing to do the work, the current TVH devs (myself included) aren't interested. This is both because its a horrible spec and because none of us have a requirement for it. So unless someone that actually needs/wants it steps forward to do the work I don't see it happening.

You do not need to implement DLNA. You just need to notify a local DMS a new content (recordings) is available so that it can be indexed. If you take minidlan there is a inotufy API to do that... You can even expose http URL for live streams as m3u from DLNA...

-- eric

Then I guess we don't need to do anything I'm pretty sure we already output m3u for streams, though I might be wrong it might just be recordings. But adding it for live streams would be trivial and that's a feature request that might stand a chance of being implemented.

Adam

Adam Sutton wrote:

Then I guess we don't need to do anything I'm pretty sure we already output m3u for streams, though I might be wrong it might just be recordings. But adding it for live streams would be trivial and that's a feature request that might stand a chance of being implemented.

Adam

Well, providing pre-integrated scripts or embedding code for using the minidlna inotify API, being able to publish the M3U file outside tvheadend because it has to be indexed by the DMS to translate it into ressoources and being able to publish directly new object via a call to UPnP AV create/add object (when/if minidlna supports it one day).

--eric

Eric Valette - wrote:

Des G wrote:

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 would say the reverse, the only thing keeping tvheadend alive is the integration with XBMC.

Cheers, Des.

VDR + streamdev was there for even longer I bet. Did this prevent VDR relative decline? No. The rant against VDR are 1) configuration nightmare, 2) streaming capabilities and indeed integration with a player. Xine been one used. On the other hand, you should consider:

1) There are probably more XBMC windows users than XBMC linux users. tvheadend does not run on windows and they are better PVR alternative anyway on windows,

My server is Linux, my clients are Linux/Windows/Android and iOS? Does anyone use a combined FE/BE, no-one I know does. (Not statistically representative, just an observation)

2) There is still no official XBMC with PVR build-in. So its mainly for geeks for the moment. Its not ready for general consumption IMHO

As has been mentioned, built in PVR support is around the corner. Lets be honest, all of this is for geeks & always will be, normal people just use a stb from their TV provider, etc.

3) tvheadend being GPL V3 it will hardly find his way in embedded devices were linux indeed dominates,

My server will never be an embedded device

To me, it looks like the project is in Limbo, which is understandable. What the way forward is, depends on what the few devs there are want to spend their time working on.

I have some features I would really like to see, but without the ability to code them myself, I'll just wait

Cheers, Des.

Des G wrote:

normal people just use a stb from their TV provider, etc.

I'm not sure stb are here to stay given what new tv set do (CI+ for pay TV, VOD offer, proprietary recordings on disks, DLNA, internet browsing, skype,...)

I agree with the FE/BE stuff, but would like to have nothing special to install on FE beside normal players (XBMC on IOS => jailreak, on android you need at least tvhguide + a player, ...)

I am currently trying to get away from Windows and Windows Media Center, so XBMC and Linux is where I have ended up.

I have just installed the XBMC PVR build plus tvheadend and it works nicely. I was impressed!

Then I tried to pause live TV and found it did not work. I've found my way, via google, here and it sounds like the reason I cannot pause, rewind etc. live TV is that the live TV data is streamed in mkv format. It sounds like if I could get it streamed to XMBC in TS format then it might just work. Surely this would be a good thing?

I found another post where, I think Adam, suggested you need to append a param on the HTTP request to stream in TS format, but of course the XBMC tvheadend plugin streams via HTSP.

Any advice or help would be gratefully received.

Evan,

Live pause / time shifting is currently NOT supported by either Tvheadend or XBMC. The best you can get is a pseudo pause in XBMC because it will buffer the stream in memory, but expect your system to go bang when it runs out of RAM

TS v MKV is mostly irrelevant to this discussion since the primary focus for live streaming is HTSP (at least for XBMC).

The hope is that live pause / time shifting will be implemented in the medium term future, but I need to get up to speed on things first or get help from others. There are plenty of good ideas floating around #hts about how to do this. And yes use of the raw TS data is obviously one idea, use of MKV data is certainly NOT relevant and I don't think anyone has argued it would be.

The use of MKV for default HTTP streaming is mostly historical and you never know it might change, but I wouldn't count on it. It certainly won't change for recordings. However the options do exist to change these on the fly (and for recordings you can change the default). The only thing really missing here is the ability to set the default HTTP streaming muxer, but that could (and hopefully will) be added in the future.

Regards
Adam

P.S.
For balance and clarity, I should add some hooks for live pause do exist in the XBMC code and there are some unofficial forks that do provide such support in conjunction with other backends. But as yet this has not made it into the official code (or at least hadn't last time I checked). Mainly because there are still ongoing discussions about the best way to handle it.

Adam Sutton wrote:

Evan,

Live pause / time shifting is currently NOT supported by either Tvheadend or XBMC. The best you can get is a pseudo pause in XBMC because it will buffer the stream in memory, but expect your system to go bang when it runs out of RAM

Well while that is technically correct, by recording in TS waht yu watch and using the recorded file rather than the live stream, you can do it. This does not work when recording in MKV...

TS v MKV is mostly irrelevant to this discussion since the primary focus for live streaming is HTSP (at least for XBMC).

I beg to disagree, probably because I know the way its implemented in many STBs... If you are going to implement full time shifting, including going back in time, not just pausing and resuming, you will easily conclude, you will need to implement "always record what you watch feature" on a disk and trash the recording when you change channel. The way the recording is done shall permit, trick mode fast backward/forward. This excludes MKV.

Then if you plan to watch and record at the same time, you will probably not use two formats... using mkvmerge to convert TS at the end of recording, adding metadata you got via epg...

Thank you both for the replies.

For my install tvheadend and xbmc are on the same box so getting tvheadend to record to a ts when live tv is initiated and tell xbmc which file to then play would work. I can see the implementation is more complex when tvheadend is remote as it has to stream the file content.

Eric, any idea how I could achieve that for a a co-located install?

Eric,

Actually because of the reported issue #1267, this will only work if you use direct file access (or NFS/SMB) and not via the HTTP links used by TVH. This has nothing to do with TS v MKV, its a problem with streaming via HTTP (which is why recordings will eventually also be available via HTSP). I'm sure there is a solution, I just need to read the HTTP spec to see what can be achieved.

Seriously you need to read what people write. I said the discussion was irrelevant because it is. I then went on to say the reason its irrelevant is clearly MKV would NOT be used for such a feature. It will almost certainly use either TS or TVH's internal packet structures, there are pro's and con's for both. And which is chosen will probably depend on several factors, not least of which will be who actually stumps up the time to do the work (though obviously the technical considerations must be considered too).

Nor do any of the discussed approaches preclude the use of MKV as an end recording format, ultimately its just the last link in the chain. Though I admit there could be some inefficiencies related to doing this, but for most people they'd never notice and they can always change the preferred format.

Adam