MythTV or TVheadend on QNAP
From QNAPedia
This page is to list the similarities and differences of MythTV and TVheadend on the QNAP NAS. The purpose is not to prove one better than the other, but to help those deciding between the two to know which may serve their purposes better. Even though the title limits the scope to implementations on the QNAP, features that are not unique to the NAS certainly may be discussed.
Contents |
MythTV
MythTV is a full-featured PVR backend and frontend, but only the backend is used for the QNAP. Currently, it is not available as a QPKG, but many users have been successful to manually compile the code outlined here. Compile time for QT is approximately 12 hours on a 219P+ and compile time for MythTV is approximately 6 hours on a 219P+. MythTV does not include a web interface by default, but users have had success using MythWeb as indicated here.
PROs
- Stable and well established backend for TV recording with features including:
- Standard EPG display grid with color coding (time across and channels down) (mythweb feature)
- Various schedule options:
(1) record this showing,or (2) this program in this timeslot everyday, or (3) every week, or
(4) find and record one showing of this title, (5) or each day, (6) or each week,
(7) record at any time on channel X, or (8) on any channel - Detect duplicate recordings: won’t record an episode if it’s already recorded
- Recording priorities
- Tracking statistics (uptime, %of time recording, total recorded, etc)
- Integrated HDHomeruns (and many others) into the backend (no need to pre-install libraries/drivers)
- Very active bug squashing (many developers knocking out problems quickly)
- Once you have it installed, it works without problem (set and forget)
- Does allow HDDs to sleep when not recording
- Records to *.mpg: natively supports timeshifting (fast-forward while recording)
CONs
- Quite difficult to install on the QNAP. You need to follow the forum guides (and go off piste occasionally) to install the pre-requisites such as Qt, perl modules. As described above the compile time is crazy. I suppose if someone figures out (and is so inclined) to create a qpkg, then this wouldnt neccesarily be a problem.
- As a result of the above point, upgrading the MythTV solution is a problem. You need to take down your pvr backend for 6-9 hours to upgrade it. Again, could be fixed if a qpkg was available.
- You need mythweb to schedule recordings. From my experience the scheduling in xbmc pvr addons are a little earliy in development cycle to use. I needed to upgrade PHP to get mythweb to work (i vaguely recall followign this guide http://forum.qnap.com/viewtopic.php?f=124&t=52610)
- Personally, only using a fraction of the feature rich backend. MythTV backend has so many options, but I only need a service that records TV. I cant use the clever commercial detection functions on the QNAP.
- MyyTV would seem to be not designed for QNAP type architecture, as you need to pre-install a lot of software to just get the basic PVR function to work. I understand that a developer has forked MythTV into Torc, which might lead to a more flexible solution that can be easily delivered on various infrastructure.
Performance Info
QNAP 219P+
mythbackend
- idle: 22MB RAM and 0.0% CPU
- recording 1 SD stream: 24MB RAM and 1.9% CPU(range: 0.7-2.7%)
- recording and streaming same SD stream: 27MB RAM and 6.7%CPU (range: 6.1-8.1%)
- recording and streaming same SD stream and playing separate HD recording: 27MB RAM and 11.9%CPU (range: 10.3-14.3%)
- recording 1 SD stream and playing 2 separate HD recordings: 27MB RAM and 14.0%CPU (range: 13.2-17.2%)
mysqld: 33-34M RAM and 0.0-0.1% CPU
Useful Links
XBMC (Eden) frontend interface to MythTV:
Issues
MythTV backend exits without warning
A user noted that the backend may exit without any notification in the error log, even when using "verbose all". Because other users indicated similar issues here, using the "--noupnp" flag when launching mythbackend has solved the problem.
MythWeb does not allow download or stream of recordings
Documented here, an "Internal Server Error" occurs when trying to download or stream recordings from the "Recorded Programs" page. There are no errors in the apache error.log file to indicate the problem.
TVheadend
TVheadend is a light PVR backend. It is available as a QPKG and supports the most popular USB tv tuners. Current version requires firmware 3.6.0, whereas past versions may be used on older firmware versions. XMLTV is also available as a QPKG to download Electronic Programming Guide (EPG) information. QPKGs for other devices are available:
PROs
- Lightweight, small footprint for install
- Simple and current web user interface for configuring the backend.
- Seems quite stable (just does the job, no helper scripts required to keep the service alive)
- The early support for TVHeadend as a backend in XBMC is really good. I use Openelec nightly pvr builds (ION), and they integrate the TVHeadend pvr addon. These OpenElec builds mean i dont need to compile xbmc (as i would need to with tsp42's branch with the best mythtv addon). The OpenElec builds just work (no tweaking, compiling, just point it at the QNAP tvheadend service, and you are away). OpenElec also "just works" with suspend/resume, no crashing. All in all, a good pairing is QNAP TVHeadend and OpenElec pvr builds.
- Easy upgrade via qpkg (a thousand thankyous mr virtualdj!)
CONs
- TVHeadend is an emerging favourite in the hobbyist PVR backend arena. It is relatively new, and if you have a non-standard configuration (cards etc) you might hit upon a problem that no-one has encountered (or solved) before.
- I believe TVHeadend started with 1 develeoper (I guess the lonelycoder website gives that away). Possibly due to the popularity of the solution, there are a few more active developers, but there seem to be less that MythTV has at its disposal.
- As a result of the point above, it can be some time before forum posts get responses, and bugs get squashed. This is not a criticism, but merely used to compare the support bases between MytHTV and TVHeadend
- After services are mapped to muxes after scanning, they may not get mapped to XMLTV channels. In this case, a user must manually map each service to an XMLTV channel. When a user has multiple tuners, this mapping must be done for each tuner and is quite tedious.
- Records to *.mkv: does not supprt timeshifting (fast-forward while recording). See issue below.
Useful Links
Do a custom action when a recording has completed
How to add frequencies manually using DVB-T
Configure dvbhdhomerun driver to work with two hdhomerun devices / configure DVB-T hdhomerun to not be detected as DVB-C When using multiple HDHomeRun devices, they need to be specified in the file found at /etc/dvbhdhomerun. Version 0.3.2 of the HDHomeRun QPKG houses the dvbhdhomerun file within the QPKG directory and provides a symlink for the system at /etc/dvbhdhomerun to maintain persistence between reboots.
Issues
TVheadend using HDHomeRun ATSC continuously when idle Fixed Sep 13, 2012
A user has indicated here that TVheadend will make use of the HDHomeRun when TVheadend is idle, although it's not described how long this behavior may last. If the tuner is shared between multiple PVRs having separate recording schedules, this behavior may interfere with other recording schedules.
Add muxes manually doesn't work with ATSC tuners and no channels can be added Fixed Feb 6, 2013
This is a known limitation of the tvheadend webpage; the "add mux manually" button doesn't have a "case" for ATSC, so nothing happens. See tvheadend forums here and here. To add muxes for an ATSC tuner, follow the directions here.
Timeshifting is not possible with *.mkv recordings Fixed Apr 13, 2013
A user is not able to fast-forward through a recording while the video is being recorded. This scenario is common, for example, when a user wants to skip through commercials while the program is recording. See tvheadend bug report and QNAP forums for details. Recording to *.ts files, instead, allow a user to timeshift. Users have reported success with timeshifting when using a branch available here, which provides the user with an option to record to *.ts instead of *.mkv.
