[mythtv] Why are there so many instances of recordedseek?

Steve E simon.sinister at sbcglobal.net
Tue Apr 21 00:09:11 UTC 2015


I was looking through the MythTV mysql database to try to
figure out where the current position in a recording is stored.
Based on the name, I thought *recordedseek* might be the spot.

    mysql> *describe recordedseek;*
    +-----------+-----------------------+------+-----+---------------------+-------+
    | Field     | Type                  | Null | Key |
    Default             | Extra |
    +-----------+-----------------------+------+-----+---------------------+-------+
    | chanid    | int(10) unsigned      | NO   | PRI |
    0                   |       |
    | starttime | datetime              | NO   | PRI | 0000-00-00
    00:00:00 |       |
    | mark      | mediumint(8) unsigned | NO   | PRI |
    0                   |       |
    | offset    | bigint(20) unsigned   | NO   |     |
    NULL                |       |
    | type      | tinyint(4)            | NO   | PRI |
    0                   |       |
    +-----------+-----------------------+------+-----+---------------------+-------+
    5 rows in set (0.00 sec)


    mysql> *select * from recordedseek;*
    +--------+---------------------+--------+-------------+------+
    | chanid | starttime           | mark   | offset      | type |
    +--------+---------------------+--------+-------------+------+
    |   1111 | 2010-04-04 05:00:00 |  44794 |  2181271880 |    9 |
    |   1111 | 2010-04-04 05:00:00 |  44781 |  2180506720 |    9 |
    |   1111 | 2010-04-04 05:00:00 |  44766 |  2179733476 |    9 |

...

This went on forever, until I typed Ctrl-C to terminate the operation.

    |   1091 | 2009-01-17 21:00:00 |  49644 |  3156051316 |    9 |
    |   1091 | 2009-01-17 21:00:00 |  49644 |  3156051316 |    9 |
    Ctrl-C -- sending "KILL QUERY 52407" to server ...
    ^CCtrl-C -- query aborted.

    +--------+---------------------+--------+-------------+------+
    *2280198* rows in set (3.00 sec)


This message rather surprised me. I've got 2.28 million *recordedseek* rows
in my database? Granted, I currently have a large number of recorded
shows (234),
but that's averaging 9744 recordedseek instances per recording, which is
ridiculous.

It seems likely that a large number of *recordedseek* instances are not
being
deleted from the database when the corresponding recording is deleted. Some
of the dates listed above are from 2009, so I've been accumulating them
for at
least 6 years.

Do other developers / users have really large numbers of these rows in
their databases?

You can retrieve an approximate count using the following syntax:

    mysql> *show table status like 'recordedseek';*
    +--------------+--------+---------+------------+---------+----------------+-------------+------------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+----------------+---------+
    | Name         | Engine | Version | Row_format | Rows    |
    Avg_row_length | Data_length | Max_data_length  | Index_length |
    Data_free | Auto_increment | Create_time         |
    Update_time         | Check_time          | Collation       |
    Checksum | Create_options | Comment |
    +--------------+--------+---------+------------+---------+----------------+-------------+------------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+----------------+---------+
    | recordedseek | MyISAM |      10 | Fixed      | *2280198*
    |             25 |    61642050 | 7036874417766399 |     67974144 |  
    4637100 |           NULL | 2014-12-06 17:48:53 | 2015-04-19 23:49:30
    | 2015-04-18 07:42:10 | utf8_general_ci |     NULL |               
    |         |
    +--------------+--------+---------+------------+---------+----------------+-------------+------------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+----------------+---------+
    1 row in set (0.00 sec)

    mysql>

Any theories on why these keep accumulating?

The size of this database table worries me. I wonder if it's slowing down
my system performance. Lately, my recording playback has been
pausing for 2 or 3 seconds every time I hit the top of an hour, even
when there is no recording currently going on. Would the insertion
of another instance of *recordedseek* every hour cause such a delay
due to the size of the table?

     - Steve




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20150420/c95b9a24/attachment.html>


More information about the mythtv-dev mailing list