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

Angela angela.schmid at wolke7.net
Sat Jul 5 14:53:14 UTC 2014

> 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.

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
> a 2nd reference frame as the data between the time the first lock was
> 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
> 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
> 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?


More information about the mythtv-dev mailing list