[mythtv] Playback hickup with in progress recording when it closes

Jean-Yves Avenard jyavenard at gmail.com
Sat Jul 5 15:15:31 UTC 2014


On 6 July 2014 00:53, Angela <angela.schmid at wolke7.net> wrote:

> I had these 10 seconds lockups caused by DB access, because recordedseek was
> not using ISAM. After I moved it to ISAM, everything was OK in 0.27-fixes.
> https://code.mythtv.org/trac/ticket/12016#comment:21
>
> The 1 to 3s hickups where introduced in 0.27.1.

I can't see how 0.27.1 would create an additional delay.

Everything it does is now faster and less blocking.

That includes the SQL queries which are now cached and performed has a
block rather than making 10+ queries in a row.

that has improved write performance to the recordedseek table by 10

>> you mean startup delay?
>
> When a recording is finished, and you start playback within 1 minute, the
> startup delay is between 10-20 seconds.
> Otherwise, playback starts within 3 seconds (depending mainly on deletions).

I can't reproduce that any long

There were several bugs opened on this topic, with people experiencing
that issue.

All have reported that following an upgrade to 0.27.1 the issue had disappeared

> I have a combined BE/FE.
> Will it use streaming? What are the conditions?

no it won't.
not by default..

You need to start the frontend with -O AlwaysStreamFiles=1
having said that, the performance increase are mostly for people who
used NFS to mount their remote storate and bypass the myth:// protocol
altogether.


More information about the mythtv-dev mailing list