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

[Angela]

> On 5 July 2014 20:54, Angela <angela.schmid at wolke7.net> wrote:
> > Watching an in-progress recording shows a 1 to sometimes up to 3
> > seconds hickup when the recording closes.
> 
> this is a different issue...

Other subject line :), please answer my last question in the other thread.

> 
> 1 to 3s is *much* better than it used to be, it used to lock for over 10s

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.

> before, sometimes even exiting back to the main menu
> 
> one of the main reason is that the backend writes the new recording only
> once it has a complete lock and a reference frame. Once it has found a
> reference frame, it starts writing to the disk, but it does so only after
finding
> a 2nd reference frame as the data between the time the first lock was
found
> and you start writing is lost.
> 
> It's a long standing issue.
> 
> in the mean time, the frontend has exhausted data and is waiting.
> 
> >
> > Another issue I see, is when a just finished in-progress recording (in
> > the same minute it closed) is played, the delay is between 10-20
seconds.
> 
> what delay?
> 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've never seen that.
> On the other hand, before 0.27.1, if the recording ever stopped during the
> in-progress recording, or if you reached the end, it would abort
completely
> and go back to the main menu.
> 
> BTW, all of this works much better if you are streaming from the backend
> rather than reading directly from the disk or mounted partition

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

Angela