[gentoo-user] Opinions on DVR/PVR backend?

[gentoo-user] Opinions on DVR/PVR backend?

[Grant Edwards]

I think it's about time to replace my SageTV DVR/PVR system, so I'm
looking for opinions and recommendations for a DVR backend to run on a
Gentoo desktop machine.

Some Background...

For many years, I ran a dedicated, combined frontend/backend MythTV
system (usually a Debian install).  Then I switched to a mac-mini
frontend booting a dedicated MythTV frontend distro from a USB flash
drive with the MythTV backend running on my general-purposed Gentoo
box.  I was never completely happy with the mac mini frontend, but it
was small and quiet and mostly worked.

After that (about 8 years ago) I switched to using the SageTV backend
on that same Gentoo box with SageTV brand custom frontend set-top
boxes.

About a year later, SageTV got bought by Google and mostly shut down.
Software continued to be updated for a few years, and EPG data was
kept flowing.  The software has since been open-sourced, but the
backend development has slowed and development/support for the set-top
boxes ended (there are some nagging set-top box problems that are
never going to get fixed). The "lifetime" free EPG data spigot for
SageTV got turned off last year.

SageTV is a large Java app with a bunch of custom libraries.  For now,
the tarball of JAR files and binaries works, but it's not a long-term
solution.  I tried building the SageTV backend under Gentoo and was
unsuccessful in an effort to produce an ebuild for it.  The build
system is a completely broken mess of shell-scripts and makes all
sorts of assumptions about development host library versions (it
requires a lot of ancient library versions).

And now...

I'm looking for opinions on a DVR backend to run on a desktop Gentoo
box.  Input is OTA ATSC via an Ethernet-connected tuner (SiliconDust
HDHomeRun).  The ideal set-top frontend would be Roku. I'd also really
like a good Android frontend.  My next choice for a set-top frontend
would probably be Kodi on Raspberry Pi 3B or Vero 4K HW.  I'm going to
pick up a RPi3 this weekend and start playing with Kodi (OSMC or
LibreELEC).

The main backend options seem to be MythTV, Plex, and TVHeadend.

 MythTV

    Pros: Good feature set
          Open-source

    Cons: It's a giant bloated mess that pulls in all sorts of Qt stuff
          Fragile frontend API/protocol that gets broken regularly
          Poor music player (the last time I tried it)
          Poor frontend support for Android.

 Plex

    Pros: Roku frontend
          Good integration of existing media files
          Good support for Android

    Cons: DVR support is new
          Closed source
          Commercial service

 TVHeadend

    Pros: Lightweight
          Minimal dependencies
          Open-source
          Android frontend (I think)

    Cons: Weak recording management
          Poor integration of existing media

There are minimal subscription costs for all three ($40/year for Plex,
$25/year for the others), so that's a push.

-- 
Grant Edwards               grant.b.edwards        Yow! Youth of today!
                                  at               Join me in a mass rally
                              gmail.com            for traditional mental
                                                   attitudes!

Re: [gentoo-user] Opinions on DVR/PVR backend?

[Rich Freeman]

On Fri, Jan 26, 2018 at 11:29 AM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
>
> The main backend options seem to be MythTV, Plex, and TVHeadend.
>

You seem to understand the pros/cons fairly well.

I moved from MythTV to Plex about two years ago, but as a result of
moving from DVR to discrete media files, which MythTV was a poor fit
for.  The DVR service is new for Plex and I've never tried it, though
it would be free for me to use (I have a lifetime Plex pass).  I don't
have any tuners set up at all right now and no easy ability to watch
LiveTV of any kind.

One pain I always had with MythTV was any time where I wanted to run
different distros on front-ends vs servers, because the protocol
changes from time to time and upstream does not support anything other
than all clients and servers running on the exact same build.  (In
reality it is more flexible than that, but protocol version changes
are not generally announced or managed because upstream really does
want everything on one build.)  So, running a Gentoo server and a
MythBuntu front-end is a constant source of pain with the versions
never being in-sync.

The thing I like about Plex is that upstream basically tries to keep
everything painless and "just working."  They do QA testing on all
their platforms/etc, and I've never had a situation so far where my
server wouldn't talk to one of my clients.  I use a Roku client, an
android client, my android client casting to a chromecast, and the web
client.  I've messed with the windows desktop client as well.  They've
all always "just worked" with the auto-updates on all the various
platforms, and I just update my server about once a month (I think I
have that running in an Arch container on my main Gentoo box). Plex
also seems to handle media in whatever format I already have it in
fairly flexibly - I rarely have to rename files or anything like that.

Now, MythTV in general is going to be more flexible with DVR
capabilities, since it does have a database you can poke around in,
and more of an API/etc.  And of course it is open source so you really
can patch whatever you want into it.

In a pure DVR world I might still be running MythTV.  I'd certainly
evaluate Plex though.  I'm not sure how easy it is to evaluate Plex
DVR without paying something though.

-- 
Rich

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jan 26, 2018 at 11:29 AM, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> The main backend options seem to be MythTV, Plex, and TVHeadend.
>
> You seem to understand the pros/cons fairly well.
>
> I moved from MythTV to Plex about two years ago, but as a result of
> moving from DVR to discrete media files, which MythTV was a poor fit
> for.  The DVR service is new for Plex and I've never tried it, though
> it would be free for me to use (I have a lifetime Plex pass).  I don't
> have any tuners set up at all right now and no easy ability to watch
> LiveTV of any kind.

Live TV is not a priority at all and would be the first thing I would
give up in order to gain in other areas.

> One pain I always had with MythTV was any time where I wanted to run
> different distros on front-ends vs servers, because the protocol
> changes from time to time and upstream does not support anything
> other than all clients and servers running on the exact same build.

Yep.  You can make it work, but it takes effort.

I was never able to find an option for an acceptably small and silent
Myth fontend.  The last time I was looking into that, the Raspberry Pi
3B seemed like a decent option, but reports indicated it still took a
lot of futzing to get it work.

> The thing I like about Plex is that upstream basically tries to keep
> everything painless and "just working."

That's always good, and I'm more than happy to pay cash money for
that.

I'm guessing that Android client support is going to be better with
Plex than with the others.

> [...]
>
> Now, MythTV in general is going to be more flexible with DVR
> capabilities, since it does have a database you can poke around in,
> and more of an API/etc.  And of course it is open source so you really
> can patch whatever you want into it.

After reading through the Plex DVR wiki pages, I was pleasantly
surprised.  It had some features that MythTV has but TvHeadend and/or
SageTv lacks:

  * Minutes-before and minutes-after settings for a recording to
    adjust for local TV station management decisions to skew
    start-stop times.  SaveTV lacked this, and it was annoying. [The
    optimal solution is repeated beatings for the people who decide to
    do that.]

  * How many and which recordings to keep for each series.  [SageTv
    does have this.]

> In a pure DVR world I might still be running MythTV.  I'd certainly
> evaluate Plex though.  I'm not sure how easy it is to evaluate Plex
> DVR without paying something though.

One notable feature that (I think) TvHeadend lacks is the ability to
only record series episodes that haven't been previously recorded and
watched.  Both MythTv and SageTv can do that, but I'm not sure about
Plex.

I'm still not sure how storage space management works with Plex's DVR.
AFAICT, TvHeadend doesn't provide any space management at all.

-- 
Grant Edwards               grant.b.edwards        Yow! Where's th' DAFFY
                                  at               DUCK EXHIBIT??
                              gmail.com            

Re: [gentoo-user] Re: Opinions on DVR/PVR backend?

[Rich Freeman]

On Fri, Jan 26, 2018 at 12:50 PM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
>
> I'm guessing that Android client support is going to be better with
> Plex than with the others.
>

I know nothing of TVheadend.  MythTV on Android has always been kludgy
at best, though I haven't touched it in two years.

Plex on Android is a thing of beauty, especially with offline sync.
Progress is synced to the server and across all clients, and you can
give it a quality level and it will keep #n unwatched episodes synced
to the Android device, which get auto-updated anytime you're on wifi.
I've used it on trips where the hotel wifi is terrible and it works
great.  Maybe it takes all night while I'm asleep to sync new episodes
with heaven knows how many retries, but it still syncs, and then they
play just fine the next day or on the flight home.

For managing shows the web interface is still better than
Android/Roku.  Often I'll set up the sync rules from the web - and
then the android device will just magically do what it should
(eventually).  If I'm in a hurry I can fire up the android app and
tell it to sync right away, and it picks up the new rules.  The server
picks up the rules immediately and will have the shows transcoded
already, so it is just a matter of file transfer.

That's the other thing - the Plex server/clients do a good job
negotiating codecs, with the server doing all the transcoding.  You
can pre-transcode files if you want to in order to reduce server load,
such as if you have many Rokus you use at the same time.  When
transcoding you do get a bit more latency, especially if you want to
seek around a lot (no issue at all if you just hit play and watch the
show) - you end up with bufferbloat on both the server and the client
when you transcode.  Still, it all just works, and it is no worse than
Netflix/etc.  You can also configure quality rules for LAN vs WAN
streaming, both on the clients and the server.


-- 
Rich

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jan 26, 2018 at 12:50 PM, Grant Edwards
><grant.b.edwards@gmail.com> wrote:
>>
>> I'm guessing that Android client support is going to be better with
>> Plex than with the others.
>>
>
> I know nothing of TVheadend.  MythTV on Android has always been kludgy
> at best, though I haven't touched it in two years.
>
> Plex on Android is a thing of beauty, especially with offline sync.

That's a big plus for Plex.

> For managing shows the web interface is still better than
> Android/Roku.

That's fine -- I prefer using a web browser for that sort of thing.
One of my complaints with MythTv and SageTv was that the web UIs for
backend configuration and recording scheduling were after-thought
add-on/plug-in kludges.  My current SageTv setup lacks a web ui
completely. :/

The config/scheduling UI for TvHeadend is purely web-based.

> That's the other thing - the Plex server/clients do a good job
> negotiating codecs, with the server doing all the transcoding.  You
> can pre-transcode files if you want to in order to reduce server load,
> such as if you have many Rokus you use at the same time.

Pre-transocoding from MPEG-2 TS to MPEG-4 h264 would be nice.

> When transcoding you do get a bit more latency, especially if you
> want to seek around a lot (no issue at all if you just hit play and
> watch the show) - you end up with bufferbloat on both the server and
> the client when you transcode.

When watching recorded TV shows, I do rely heavily on "jump forward
30s" and "jump back 5s" for manually skipping commercials.

> Still, it all just works, and it is no worse than Netflix/etc.  You
> can also configure quality rules for LAN vs WAN streaming, both on
> the clients and the server.

That's cool.

One open question is handling of closed-captioning in ATSC recordings.
Results with Plex seem to be mixed.

I think I'll try out Plex DVR this weekend and see how it works with
the Roku and Android frontends.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm definitely not
                                  at               in Omaha!
                              gmail.com            

Re: [gentoo-user] Re: Opinions on DVR/PVR backend?

[Rich Freeman]

On Fri, Jan 26, 2018 at 1:40 PM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
>
> Pre-transocoding from MPEG-2 TS to MPEG-4 h264 would be nice.
>

So, that is a downside with Plex.  I don't think you get that level of
fine-grained control.  You can't just pick the codec and features.
You pick the target platform (optimize for Android, or a generic
Optimize for "Mobile", etc), and you pick the resolution/bitrate from
a list of presets.  I'm not sure how easy it is to tweak the actual
settings, though maybe it is possible.

On MythTV the transcoder isn't exactly super-flexible either.

On either platform you could also do your own transcoding.  With
MythTV the regular player tends to be pretty picky about how files are
encoded (at least it used to be).  Plex will play just about anything
you throw at it.

>
> One open question is handling of closed-captioning in ATSC recordings.
> Results with Plex seem to be mixed.
>

I've found captions mostly work, but I don't use them much, and I
haven't used the DVR functionality.  I couldn't tell you how well they
work with ATSC.  The bigger pain is the way they're encoded into
shows.  If they're done right you can do things like have captions
only for foreign language phrases (works great in Star Trek
Discovery).  If the subtitles aren't set up the way it expects then
you find yourself constantly turning them on/off when the show
contains extensive use of foreign/fictional languages.  I suspect the
issue is more in my source material there, though I can't vouch for
how well it works over ATSC.  With ATSC I'd think that foreign
language subtitles would be more likely to be burned in anyway.

-- 
Rich

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jan 26, 2018 at 1:40 PM, Grant Edwards
><grant.b.edwards@gmail.com> wrote:
>>
>> Pre-transocoding from MPEG-2 TS to MPEG-4 h264 would be nice.
>
> So, that is a downside with Plex.  I don't think you get that level of
> fine-grained control.

I think there's a hook to do stuff like that.  I've stumbled a cross a
few mentions of how to configure Plex DVR to run a "post-recording"
script.  I've also seen somebody mention that you can just run a cron
job to search for new .ts files and convert them to .mp4 (or
whatever).

One of the built-in Plex DVR features is to run comskip on a recording
when it is finished, and I'm sure with the right hammer that could be
bent so that it just does transcoding.

> You can't just pick the codec and features.  You pick the target
> platform (optimize for Android, or a generic Optimize for "Mobile",
> etc), and you pick the resolution/bitrate from a list of presets.
> I'm not sure how easy it is to tweak the actual settings, though
> maybe it is possible.
>
> On MythTV the transcoder isn't exactly super-flexible either.

When I got my first HDHomeRun ATSC tuner, I didn't have a MythTV
frontend capable of playing HD MPEG-2 transport streams, so I set up
post-recording transcoding to convert the files into an SD format that
my frontend's Hauppauge PVR-350 card could play back.  By the time you
got Myth to do something like that, you felt like you'd been in the
wars...

> On either platform you could also do your own transcoding.  With
> MythTV the regular player tends to be pretty picky about how files are
> encoded (at least it used to be).  Plex will play just about anything
> you throw at it.

That makes the "cron job" approach a decent option.

>> One open question is handling of closed-captioning in ATSC recordings.
>> Results with Plex seem to be mixed.
>
> I've found captions mostly work, but I don't use them much, and I
> haven't used the DVR functionality.  I couldn't tell you how well they
> work with ATSC.

I'll have to do some experiments.  I get the impression if you disable
transcoding, then it varies depending on the frontend.

-- 
Grant Edwards               grant.b.edwards        Yow! They collapsed
                                  at               ... like nuns in the
                              gmail.com            street ... they had no
                                                   teen appeal!

Re: [gentoo-user] Opinions on DVR/PVR backend?

[Taiidan]

So you know the RPI is not open source as the RPI foundation doesn't 
provide firmware sources.
Proprietary firmware is required to boot and fully use the device as the 
RPI foundation only cares about open source when it is convenient to them.

I would consider purchasing another device, of which legitimately open 
source low power ARM devices are a dime a dozen (vs the high performance 
realm where POWER's TALOS 2 or rare developer boards are the only choice)

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Taiidan@gmx.com <Taiidan@gmx.com> wrote:

> So you know the RPI is not open source as the RPI foundation doesn't
> provide firmware sources.

Yes, I'm aware of that.

[...]

> I would consider purchasing another device, of which legitimately
> open source low power ARM devices are a dime a dozen (vs the high
> performance realm where POWER's TALOS 2 or rare developer boards are
> the only choice)

The problem with purchasing less common but more "open" boards is that
it tends to be a lot more work to get things running on them.

I don't get particularly upset if a cheap, throw-away board like the
RP3 uses closed-source firmware -- all the underlying chips are
closed-source designs also.[*] As long as that firmware is part of a
driver that provides a standardized, open, documented API, I'm happy.

If the board/firmware/driver becomes unavailable, the open-source
applications and libraries can always be moved to a different
board/firmware/driver combination that implements that same
standardized API.

[*] Sure, you can run low-performance, high-cost "open-source HW"
    designs by combining open-source VHDL cores and compiling a SOC
    design into an FPGA, but the FPGAs and all the tools used to
    compile the VHDL are closed source.

-- 
Grant Edwards               grant.b.edwards        Yow! My NOSE is NUMB!
                                  at               
                              gmail.com