[mythtv-users] Moved to Intel NUC - no sound & IR receiver needed

Stephen Worthington stephen_agent at jsw.gen.nz
Sun Mar 22 15:45:30 UTC 2020


On Sun, 22 Mar 2020 13:00:09 +0000, you wrote:

>The SSDs in the backend have a fair bit of unused space. I'm thinking of adding this as storage space in the recordings group - and having a script run each morning in the early hours (when there's seldom anything at all happening with the system) to move recordings more than a few hours old to the main HDs. Worth doing ?

Doing that should allow you to record more programmes at the same
time.  However, it also will use a *lot* more of the write endurance
of the SSD.  So you will need to calculate how many more "terabytes
written" it will use and see if the SSD's lifetime will allow you to
use it that way.  It very likely will, but only if you intend to
upgrade the box to a new SSD in 5 years or so.

You want to only move recordings when the backend is not in use for
playback, and to not move any recordings which are currently still
recording or being used for commercial skip processing.  A crude way
to do that is to just schedule the move job for say the early hours of
the morning, and check that you have enough time between then and the
next recording time.  You can get the next recording time using the
Services API.  But if someone has paused the playback of a recording
that is on the SSD, you could still get into trouble that way as I
believe paused playback keeps the recording file open.  So a better
way to handle this is to also check the contents of the inuseprograms
database table.  If it is not empty, do not move any file listed in
it.  There is still a potential problem even then, as there seems to
be a bug (in v30 anyway) where the DBCleanup job that is run
automatically at some random time each day cleans up the inuseprograms
table and manages to delete all the entries, even ones that are
current.  It is only supposed to clean up old stale entries, and its
code that I glanced at should only do that, but it actually always
seems to delete all entries on my system.  Then as the jobs update
their inuseprograms table entries, the entries re-appear over several
minutes.  If your file moving script takes into account the
inuseprograms, then it potentially could be run safely at any time. It
would want to only copy the files and re-check inuseprograms before
deleting the source file in case something has started using the file
while the copying was happening.  And the destination file should have
a different name from the source file until the source file has been
deleted so that MythTV does not see two copies of the same file while
the move is in progress.

I have some Python code ("mythsgu") that moves MythTV recordings,
which has all this sort of thing in it.  It aborts any move that is
under way whenever it thinks mythbackend is becoming busy, rather than
just avoiding files listed in inuseprograms.  Let me know if you would
like a copy.

Be aware that if the free space on the recordings partition on the SSD
goes below about 20 Gbytes, mythbackend will expire recordings on that
partition.  This is not usually a problem with Tbyte+ drives, but SSDs
are typically rather smaller than that.  And other things use space -
such as backups of your database.  So you might want some way of
moving recordings earlier than every 24 hours if the free space is
getting too low.

>Am I right in thinking that any modern(ish) kernel will have TRIM support ? The backend is running Devuan ascii with 4.9.0 kernel. Filesystems (ext3) are mounted with defaults. Do I need to do anything to have TRIM supported and active ?

I do not know how Devuan is set up, but you need to have either the
"discard" option on each SSD mount line in fstab or a job that runs
fstrim from cron, anacron or systemd.  In Ubuntu, this is now done
from systemd:

/lib/systemd/system/fstrim.service:

[Unit]
Description=Discard unused blocks
ConditionVirtualization=!container

[Service]
Type=oneshot
ExecStart=/sbin/fstrim -av

/lib/systemd/system/fstrim.timer:

[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

and it is only run weekly.  I think that is far too seldom for a busy
MythTV backend, so I have added an override file to change that to
being run daily:

/etc/systemd/system/fstrim.timer.d/override.conf:

[Unit]
Description=Discard unused blocks once a day

[Timer]
OnCalendar=daily
AccuracySec=10m

If you are recording to the SSD, you will likely want it to be run
hourly, or use the discard option.  And you would likely want to also
run fstrim after the job that moves files off the SSD has been run.


More information about the mythtv-users mailing list