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

dennis deg at outlook.com
Tue Apr 21 02:23:58 UTC 2015


I only see recent timestamps in the table corresponding to the mpeg2 
recordings I have.

mysql> select count(*) from recordedseek;

+----------+
| count(*) |
+----------+
|    33110 |
+----------+

I used to have a bunch of scripts that audited the database and clean 
things up like this, but most have been retired over the years as they 
got fixed in the code.

Do you have any recent recordings that were deleted and still show up in 
the table? By the age of your system,  I'm guessing this might be an old 
bug and the data never got cleaned up.


On 04/20/2015 07:09 PM, Steve E wrote:
>
> 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
>
>
>
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

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


More information about the mythtv-dev mailing list