[mythtv-users] Ceton vs multirec questions

[f-myth-users at media.mit.edu]

    > Date: Wed, 28 Jul 2021 20:20:09 +0000
    > From: Gary Buhrmaster <gary.buhrmaster at gmail.com>

    > On a properly manageable switch one can support changing the
    > priority queue of packets (i.e. QoS) from the ceton to essentially
    > eliminate the issue on the network side.  One may also need to
    > adjust network buffers on the host.

True.  In my case, since I don't already use a managed switch, a $15 NIC
was a reasonable solution, given that I have a couple of free PCIe slots
in the backend.  It also gives me one less failure point (sort of :) and
one less thing with a configuration I can screw up and have to debug.

    > In any case, as I recall, the MythTV support for a ceton uses RTSP
    > over TCP, which at least has "some" possibility of retry (the
    > native HDHR support uses UDP).

You know, now that you say this, I should have remembered this:
my testing was using "nc -l 1234" and thus was not listening on UDP.
I haven't stress-tested this to see if I'll -actually- lose packets,
but I wouldn't trust the cheap unmanaged switches here not to do
so if I decide to absolutely saturate the wrong link, which I do
occasionally do.  A $15 NIC buys a lot of peace of mind.

    > btw, while I do not recall the ceton tuner stating that it does
    > so, the HDHR tuner which uses UDP (it may also use TCP when using
    > the more modern tuning methods) does tag it's traffic with a DSCP
    > flag (cs5?) that at least some more recent commodity switches may
    > prioritize without any extra setup (cs5 is typically used for
    > broadcast video, and would be placed in the priority queue on
    > those switches that support it).

Interesting.

    > > You should be able to find 6ETH's on eBay; they seem to pop up regularly.

    > Be aware that if your MSO uses Tuning Adapters, the ceton cable
    > that supports them is not a cable that is usually easy to find (I
    > think it was a mini-A (host) to full-size B USB cable), so if you
    > use a TA, make sure you get that cable included.

Also a good point.  Fortunately, Comcast (in my area, at least)
does not require TA's.

    > And, of course, there are the known thermal (they got hot, and
    > then fail in interesting ways, which may mean an additional fan),

Already accumulated the hardware for that. :)

    > and firmware issues (for some MSOs you need to use the latest beta
    > firmware in order to tune all your subscribed channels, and the
    > beta firmware has known memory leaks requiring a reboot at some
    > random interval), so, as always, caveat emptor.

Yeah.  I've read that you may need that latest beta to tune copy-once
channels, and that's the firmware which may leak.  So part of my testing
may be to install that latest firmware, see if I can tune such channels
(most of them are ones I don't subscribe to anyway, so I'll have to find
one which I do), and then write something which reboots the Ceton every
so often when it's not currently recording.  (That last part is easy
---send it a magic URL.)

I really wish that SiliconDust had managed to get their 6-tuner version
out the door.  Waiting for that was one of the other things that dissuaded
me from upgrading for a while, but I read (probably here) they had chip
vendor issues that ultimately screwed them.

P.S.  I also don't know if the SI units can avoid EAS alerts, but my
Comcast issues them -insanely- freqently (often more than once a week!
and always at completely unpredictable times) and they have regularly
destroyed recordings.  (I wrote some C code years ago that listens for
the tones in recordings and alerts in real time so I can reschedule; I
think I may have even posted it here.)  In theory the Cetons can avoid
that if you click the "EAS Bypass" button after each boot; in fact I
have not (yet) tested this, and there is a claim [1] that one must
install three different firmware versions -in order- for this to work.
Haven't tried that yet, either.  (I've clicked the button on a random
firmware version and am currently waiting for an EAS alert to happen.)

[1] https://www.thegreenbutton.tv/forums/viewtopic.php?f=68&t=10575

P.P.S.  Other thing, if you care about logs, is that Ceton logging is
bizarre.  They log via an internal syslog but there's no way to log to
syslog over the network, so you have to poll via the URL that fetches
the log.  The log is reset when it boots.  The log always starts from
Jan 1 even though the card notices UTC timestamps going by on the wire
and logs them.  The logs are truncated to zero when they reach 1 meg.
Aaannd their internal clock appears to run about 4 minutes fast -per
day-(!).  So collecting usable logs of what the tuner thinks it's doing
in a way that you can correlate to external events is... interesting. :)
[Which may not matter if everything's going peachy, of course, but
it's nice to be able to figure it out ex post facto when it doesn't.]