[mythtv-users] SMR drives on Mythtv

[Stephen Worthington]

On Wed, 31 Jan 2018 10:04:54 +0000, you wrote:

>On 31/01/18 06:44, Stephen Worthington wrote:
>
>> However, you can use SMR drives as storage for recordings - I have
>> four Seagate ST8000AS0002 (8 Tbyte) drives that I use that way.
>> Recordings go to my seven non-shingled recording drives, and the
>> recording files can be copied off to the SMR drives once recording is
>> completed.  I wrote myself some Python to automate the process of
>> selecting the oldest recordings and moving them to the SMR drives,
>> which I have in an "archive" storagegroup so that MythTV can see all
>> the recording files.  But as I do not have any recording rules that
>> will record to the archive storagegroup, those drive are never used
>> for recording to.
>
>A query about this:  do you have seektables for the archive SG?  If so, 
>no wonder you need to watch free space on the partition used by 
>optimize_mythdb - and it must impede other DB access for quite long 
>periods.  Is there a transcode-free, seektable-free format that would 
>still allow seeking, and can Mythfrontend use it?
>
>John P

In any normal MythTV database, for any recording in the database there
will be recordedseek entries.  Moving the recording files to different
locations or to different storagegroups does not change that - it does
not actually have any affect whatsoever on the database.  So yes, all
the recordings on my archive storagegroup drives have normal
recordedseek entries.  So as I have a large number of recordings, my
recordedseek table is correspondingly huge:

MariaDB [mythconverg]> select count(*) from recorded;
+----------+
| count(*) |
+----------+
|    25907 |
+----------+
1 row in set (0.00 sec)

MariaDB [mythconverg]> select count(*) from recordedseek;
+-----------+
| count(*)  |
+-----------+
| 241096367 |
+-----------+
1 row in set (0.00 sec)

root at mypvr:/var/lib/mysql/mythconverg# ll recordedseek.*
-rw-rw---- 1 mysql mysql       1041 Jan 19 07:37 recordedseek.frm
-rw-rw---- 1 mysql mysql 6028544575 Feb  1 01:04 recordedseek.MYD
-rw-rw---- 1 mysql mysql 5517818880 Feb  1 01:04 recordedseek.MYI
root at mypvr:/var/lib/mysql/mythconverg# ll -h recordedseek.*
-rw-rw---- 1 mysql mysql 1.1K Jan 19 07:37 recordedseek.frm
-rw-rw---- 1 mysql mysql 5.7G Feb  1 01:04 recordedseek.MYD
-rw-rw---- 1 mysql mysql 5.2G Feb  1 01:04 recordedseek.MYI

My database is on the system partition, which is a 100 Gibyte
partition of a very fast NVMe SSD (Samsung 950 Pro - 256 Gbyte).  Even
with that assistance, the size of recordedseek means that it takes a
long time to optimise or to backup.  Before I moved the system to that
SSD, that used to cause problems if a recording was happening at the
same time.  But now the normal MySQL system of journaling the updates
to a table that is being optimised allows recordings to happen without
problems at the same time.  The journal is used to update the
recordedseek table after the optimise completes.  The NVMe SSD has
enough random I/O capacity to handle the normal database accesses and
updates at the same time as the optimise or backup.  My old spinning
rust system drive (an excellent Hitachi HDS723030ALA640 3 Tbyte) could
not manage that, probably due to too much head movement being
required.

Without a seek table, DVB-T and DVB-S recordings in MPEG-2 transport
stream format as we have here in New Zealand all seem to be OK for
seeking - it takes a bit longer, and is probably not as accurate, but
it functions well enough for most purposes such as skipping ad breaks.
If the seek table is deleted for a recording, it can be regenerated
using mythcommflag --rebuild or mythutil --checkrecordings
--fixseektable.  For my DVB-T and DVB-S recordings, it takes a few
minutes per recording to do the regeneration.