[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