[mythtv] Video playback framerate

Stephen Worthington stephen_agent at jsw.gen.nz
Wed Jan 9 02:42:58 UTC 2019


On Tue, 8 Jan 2019 11:01:54 -0500, you wrote:

>
>
>On 1/8/19 10:34 AM, Stephen Worthington wrote:
>> On Tue, 8 Jan 2019 10:33:29 +0000, you wrote:
>>
>>> On 8 January 2019 1:28:41 pm Stephen Worthington <stephen_agent at jsw.gen.nz>
>>> wrote:
>>>
>>>> On Mon, 7 Jan 2019 14:25:11 +0000, you wrote:
>>>>
>>>>> How big are peoples databases currently running...
>>>> I have a monster database.  So increasing the size of the recordedseek
>>>> table would have a big impact on me:
>>>>
>>>> root at mypvr:/var/lib/mysql# du -h mythconverg
>>>> 14G     mythconverg
>>> 14G, of which 13.4G is recordedseek table alone.
>>>
>>>
>>>> 4.0K    mythconverg/recordedseek.frm
>>>> 7.0G    mythconverg/recordedseek.MYD
>>>> 6.4G    mythconverg/recordedseek.MYI
>> Yes, that is the way it works.  In most databases, most of the storage
>> is used in the recordedseek table.  I should also say that I am not
>> opposed to changes to recordedseek - it is one of the good things
>> about MythTV as it makes skipping about in recordings work
>> excellently, and improving that is a good thing.  I just want everyone
>> to be aware of the potential for problems with databases as large as
>> mine.  Imagine how long a schema update might take if all of my
>> recordedseek had to be converted to a new format.  And it would be
>> dramatically worse if all of my recordings needed to be rescanned to
>> do it - how long would it take to just read 65 Tbytes of data, let
>> alone do processing on it?
>>
>Point taken, we will not make any changes that require recreating the 
>seek table. I would prefer to get rid of the seek table, but I don't 
>know if that can happen.

If the recordedseek table could be done away with, without sacrificing
any of the seek performance, then that would be a very good thing. The
size of recordedseek is a pain in so many ways.  But the seek
performance is a key feature of MythTV, so I would not want to see any
degradation of that at all.

If it was necessary to rescan everything and recreate the seek data,
that would be possible, but would take some careful planning.  I think
it would require keeping the old recordedseek table around and in
read-only use until all the recordings had been converted to use the
new seek data.  There would have to be a background task that was
running converting the old recordings, and it would have to be
completely robust and restartable as it would be running for so long
that it would be inevitable that MythTV and/or the entire PC would
need to be shut down at some time during the process.  And the
possibility (probability?) of a power failure or other catastrophic
crash during the process would need to be accounted for.  There would
likely need to be a mechanism to pause the scanning so that database
backups could be done safely.


More information about the mythtv-dev mailing list