[max_gradient]

You guys have done an amazing piece of work on tvheadend, I could not believe how painless the setup was and how nice it worked, kudos for that!!!

It's good to hear you have recording management on your radar, I will definitely be watching your project and hope to be back soon :-)

[NewJerseyNinja]

I have been and continue to be a MythTV user.

I am an HDHR and an HDHR Prime with CableCARD user for my TV tuners.

Mythtv is painfully slow when changing channels. About how long does it take for TVHeadend to change channels?

I am considering using mythtv for my DVR and another application for LiveTV, it really is that annoying.

[bilbonvidia]

Thats one of the reasons I bombed mythtv off. TVH is almost instant in comparison.

I was wondering will this change though with timeshift implemented?

[adamsutton]

@NewJerseyNinja as noted TVH is pretty damn quick to switch channels compared to Myth, this I believe is down to inherent design differences. However as I've noted in several places the real time to change depends on several factors, but in general TVH is usually the least significant for most users.

HDHR (Prime) has been giving us some headaches though depending on exactly what environment you're using it in. We do not have built-in HDHR support and therefore you must use the DVB API wrapper, and this appears to have problems. Mostly because many of the US (cable) providers completely disregard all of the DVB rules to the point that TVH struggles (due to certain assumptions it makes). So while is by no means impossible, be warned that you MIGHT have problems.

@bilbonvidia there may be a very small increase, since it does have to do a little bit of extra setup work. However its nothing like the way (I think, I've never looked I'm going on what I've been told) Myth does things. Personally in the testing I've done there has been no perceptible change in zap time.

The reason for this is that we don't always spool from disk (which typically requires allowing a small buffer to accrue before streaming and may account for delays in Myth, I'm guessing). In live mode the existing streaming chain (internally) is unaffected with the exception that a tap is placed in the chain to hive off the packets and buffer them to disk (in a sep. thread). Only when you actually try to pause/resume OR skip back etc... do we switch to the disk buffer.

P.S.
When I say "small" we should be talking micro seconds. Setup is VERY quick all it does is setup some lists, threads, mutexes, etc... teardown of the existing subscription is possibly longer (still talking microseconds) because it has to wait for the various threads to terminate and do some cleanup (Note: this does NOT include file removal, that is handled by a permanently running thread to avoid slow FS issues).

[NewJerseyNinja]

Would mythtv play nice with TVheadend on the same machine?

I'd like to test both before abandoning Mythtv.

[bilbonvidia]

Not concurrently, as one will lock the cards but you can have them both installed, just stop one and start the other.

[adamsutton]

You can restrict which cards TVH uses using the -a option (because by default it will try to exclusively lock the lot), I think myth probably already gives you better control over this.

But as bilbonvidia pointed out, they cannot share the same card and the same time (but that's probably just stating the obvious ).

Adam

[NewJerseyNinja]

Thank you very much for the clarification with the HDHR Prime! I look forward to testing.

Incidently, I also have a RaspberryPi running Openelec 2. Do you know if a TVHeadend client will work on that low-spec. platform?

Thank you again for all of your time.

@NewJerseyNinja as noted TVH is pretty damn quick to switch channels compared to Myth, this I believe is down to inherent design differences. However as I've noted in several places the real time to change depends on several factors, but in general TVH is usually the least significant for most users.

HDHR (Prime) has been giving us some headaches though depending on exactly what environment you're using it in. We do not have built-in HDHR support and therefore you must use the DVB API wrapper, and this appears to have problems. Mostly because many of the US (cable) providers completely disregard all of the DVB rules to the point that TVH struggles (due to certain assumptions it makes). So while is by no means impossible, be warned that you MIGHT have problems.

@bilbonvidia there may be a very small increase, since it does have to do a little bit of extra setup work. However its nothing like the way (I think, I've never looked I'm going on what I've been told) Myth does things. Personally in the testing I've done there has been no perceptible change in zap time.

The reason for this is that we don't always spool from disk (which typically requires allowing a small buffer to accrue before streaming and may account for delays in Myth, I'm guessing). In live mode the existing streaming chain (internally) is unaffected with the exception that a tap is placed in the chain to hive off the packets and buffer them to disk (in a sep. thread). Only when you actually try to pause/resume OR skip back etc... do we switch to the disk buffer.

P.S.
When I say "small" we should be talking micro seconds. Setup is VERY quick all it does is setup some lists, threads, mutexes, etc... teardown of the existing subscription is possibly longer (still talking microseconds) because it has to wait for the various threads to terminate and do some cleanup (Note: this does NOT include file removal, that is handled by a permanently running thread to avoid slow FS issues).

[raptorjr]

The reason for this is that we don't always spool from disk (which typically requires allowing a small buffer to accrue before streaming and may account for delays in Myth, I'm guessing). In live mode the existing streaming chain (internally) is unaffected with the exception that a tap is placed in the chain to hive off the packets and buffer them to disk (in a sep. thread). Only when you actually try to pause/resume OR skip back etc... do we switch to the disk buffer.

I think Myth treats everything like a recording, so watching LiveTV is just the system making a recording on the fly, therefore it needs to buffer a few seconds before starting playback.

I really like your approach much better and looking forward to be able to switch to TVH. When LiveTV works and recording series works as good and easy as Myth, i'll throw out Myth and never look back.
The configuration and ease of use almost made me switch to TVH, but then i realized i still needed the features of Myth more. Softcam support is great.

I hope you both find the time and maybe even some more developers. Can't wait to see TVH get even better =)

[schmoko]

Would mythtv play nice with TVheadend on the same machine?

I'd like to test both before abandoning Mythtv.

I find its pretty easy to go back and forth between the two. MythTV confines all of its settings to its own user, as does Tvheadend (hts). You really just need to remove whichever daemon you are not using from init.d/upstart when you switch. I can't provide detailed instructions but your distribution's documentation should be enlightening.

Having used both, here are my anecdotal observations. I'm using ATSC OTA in the United States, with a somewhat flakey signal for some stations.

Tvheadend
PROS
- lightweight, easy to set-up, easy to use
- instantaneous channel switching
- developers are inclusive and quick to respond to feedback, especially Adam
- all development is focused on XBMC clients
- headless set-up. installation can be done via ssh shell, further configuration is via a lightweight web server
- normally keeps better pace with XBMC development. opdenkamp supports and uses tvheadend and is peripheral to XBMC team. Adam Sutton has been very active in last six months.

CONS
- git head for both backend and add-on are not super stable
- problem solving is arduous, as issues could be in XBMC code, add-on code, or backend. none of which are stable
- latest stable release is ancient and missing key features
- no timeshifting in git head, haven't tried branch
- for me, tv stream would lock up when signal strength was low and this has not been addressed. this doesn't seem to affect non-OTA users.

Myth
PROS
- guide/epg support, especially for tv series is much better, and duplicate detection works. recorded programs are handled better (sorted by series/date)
- 0.25+ back-end is rock solid. rarely a suspect when things go awry
- timeshifting supported using git head. only pause/start, but is big feature for live events
- currently "just works" for me, where tvheadend doesn't. This is more of a personal anecdote and may be because myth is far more tolerant of intermittent signals

CONS
- frontend not always stable. right now I have to restart PVR services every few days.
- myth and its many services tend to be a resource hog, as does mysql.
processes are among among biggest drains on a NAS cpu
requires installation of many dependencies
- configuration of Myth requires X forwarding via SSH or plugging in a monitor.
- existing Myth install base is focused on mythfrontend. xbmc users seem to be lower priority
- can lag behind XBMC features. developers are not part of core XBMC team. This is less true now, as there are two active developers (janbar and fetzerch), but before that happened, cmyth add-on was very out-of-date.

When/if Adam gets tvheadend up to speed, it is definitely the path forward. Day-to-day, I tend to use Myth, as it is less likely to drive my wife crazy or cause me to miss football. I prefer tvheadend when it works.

[adamsutton]

@schmoko I'd mostly agree with your points, but there are few things I would like to correct:

1. "all development is focused on XBMC clients" - I'd dispute that, there is a definite slant towards XBMC since its our major client (and I use it myself). However we do have several other clients that we also have to consider as well such as showtime (the original TVH client), pidvbip and a few others.

2. "latest stable release is ancient" - latest stable release is 24 hours old v3.2.18 Now you can debate its relative stability compared to Andreas' last release (2.12), but both have their problems and generally speaking 3.2.18 should be better/more stable.

3. "git head for both backend and add-on are not super stable" - this is not a CON its a point of fact, git "master" is not intended to be stable, that's what the release branches are for. With regard to the XBMC add-on, I can't really comment but given XBMC-PVR is still a new feature in alpha phase I think that's a fair statement.

Adam

[schmoko]

@schmoko I'd mostly agree with your points, but there are few things I would like to correct:

1. "all development is focused on XBMC clients" - I'd dispute that, there is a definite slant towards XBMC since its our major client (and I use it myself). However we do have several other clients that we also have to consider as well such as showtime (the original TVH client), pidvbip and a few others.

2. "latest stable release is ancient" - latest stable release is 24 hours old v3.2.18 Now you can debate its relative stability compared to Andreas' last release (2.12), but both have their problems and generally speaking 3.2.18 should be better/more stable.

3. "git head for both backend and add-on are not super stable" - this is not a CON its a point of fact, git "master" is not intended to be stable, that's what the release branches are for. With regard to the XBMC add-on, I can't really comment but given XBMC-PVR is still a new feature in alpha phase I think that's a fair statement.

Adam

Thanks for the corrections.

RE 1. Proportionally, I think XBMC users are still a much larger percent of the tvheadend user base than for Myth, which is still a plus.

I stand corrected on 2 and 3, I think 3.2 was still in much earlier development last time I spent a significant amount of time running tvheadend.

[Xexiz]

I was trying for weeks now to configure TVH and HDHR3 on my Synology DS1512+
It's been pretty painfull and though to give a try to mythTV but I cant find any package to install it. I'm on Synocommunity package 3.2~git20121012-1

HDHR3 finally was detected but can't Match DVB to Channels though so well, can't do anything.

[LastCoder]

Hi, I'm using tvheadend, I'm very excited about it - it's easy to install, easy to maintain, uses low ressources and even word clients work with some clicks. Imho best tv backend ever. (Yeah, I tried them all ;-)

I hope that further development will keep it clean and simple !

So:

Please, never use MySQL as db-backend .. it's like using a sledgehammer to crack a nut ..
I think, that stuff like series recording and complex timer management and so on should be realized by the frontend ..
Timeshift .. nice to have but imho no killer feature 'cause there a ways of "emulating" this ..
You could improve the webUI handling, especially multiple operations etc.

Greetz

LastCoder

[adamsutton]

I guess I should comment on that

1. I guess it depends on the use case, for TVH it simply doesn't make sense and would never be suggested. There has on occasions been talk about using something like sqlite, but again there simply isn't a need at the moment.

2. I couldn't disagree more. Complex timer management/series linking etc... Is exactly what the backend is for, the frontend should merely be a display device. Putting this functionality in the frontend is massively limiting: what about multi front-end setups? what about thin front-ends (that don't necessarily keep all the EPG data all the time) what about front-ends that aren't permanently on?

Certainly my own setup is a TVH server running on a NAS, where a) the disks are, b) its always on and c) has all the required kit to do the job. My front-ends include rpi and ION based OpenELEC machines that are only turned on when I need them. The great thing about something like TVH (and the other backends) is the ability to centralise DVB infrastructure (including recording) and share that within the local IP network.

3. Timeshift may not be a killer feature for you, but it is for many others (myself included). There is no current way of emulating this in a sensible fashion. Yes you could record stuff and then playback from there (though not using the normal PVR playback at the moment), but that requires fore thought. What if you simply want to pause live TV (don't need to record stuff, just pause while I deal with something). I don't want the hassle of hitting record, then switching to record view (then what happens when the show I'm watching finishes - and thus the recording, and I realise I also want to watch the following show?) and then later remember to remove the recording.

Timeshift "is" a killer feature for many people and for anyone use to using a COTS PVR solution (in the UK, others?) its a must before XBMC-PVR can be truly accepted in the home as a replacement for said boxes.

4. The UI could indeed do with a revamp for many reasons (but we don't really have anyone on board, at the moment, to do the work). Andreas is currently working on improving the DVB network management.

Adam