[mythtvnz] Seek issues on currently-recording file

[daniel williams]

Try setting the 'aways stream file from backend' option if you haven't
already.  Means the frontend will talk to the backend for the recording,
rather than just look at the filesystem/database.

I found that I had issues with seeking within a currently recording show
until I set this.

Daniel

>>> I too have always had this issue, since VDPAU started working + 8.10. I
>>> work
>>> around it by saving my position before seeking, escape out of playback,
>>> then
>>> hit "play from bookmark", then seeking works. After a few minutes it is
>>> no
>>> longer accurate however. Otherwise, the down arrow on my remote jumps
>>> ahead
>>> 10 minutes, which seems to line up with ad-breaks on 3 News, so just
>>> starting from the beginning again isn't so hard.
>>> Playing back a recording-in-progress seems to set a reference point on
>>> the
>>> head of the recording from the time you start watching, with any seeks
>>> treating this as a fixed end point.
>>
>> Sounds to me as though the frontend caches the seektable that has been
>> created by the recording so far when you first start playback and
>> doesn't
>> update it during the playback. That means you'll never be able to seek
>> past where it was when you start watching.
>>
>> Sounds like a reasonable way to go to me - could be that LiveTV is
>> treated
>> differently so that it keeps the local seektable cache up-to-date
>> (although I've not looked at the code to check this).
>
> Without a knowledge of the code we are all guessing, which is one of
> the reasons i suggested the user list :)
>
> However as _everything_ in mythtv seems to be stored in the database I
> would have thought it would stay in the database, why would you cache
> something that is subject to change? If it works the way you suggest
> then it would have emerged as a problem before now I am guessing.
>
> My further guess is that the strangeness of the NZ h.264 streams is
> somehow fooling the system. This could be a container issue or a codec
> issue or some combination. But again thats all guess work.
>
> A look at the frontend logs when this happens might be revealing.