[mythtv-users] Both In progress HD recordings and Live Tv dropping frames on frontend.

[John]

On 15/05/14 20:37, Michael T. Dean wrote:
> On 05/15/2014 03:10 PM, John wrote:
>> Further followup. I repeated the test Angela tried in
>>
>> https://code.mythtv.org/trac/ticket/12016
>>
>>
>> Created a donor recording, which was then stopped. Then removed the 
>> donor mpg file, and created a hard link to an in progress recording - 
>> I then had two entries in the recording screen one for the in 
>> progress recording (real) and one for the donor file, which is linked 
>> to the same (still recording) Fake file. The hard link recording uses 
>> the database entries and state of the donor recording that has been 
>> deleted.
>>
>> Playing back the hard link, no drops.
>> Playing back the real in progress recording, drops.
>
> When playing back the not-in-progress "view" of the recording, your 
> system isn't going to pull seek table updates and such from the 
> database, so this could be an issue stemming database congestion, 
> possibly due to database configuration (such as storing database data 
> files on a file system with barriers enabled on a system/storage 
> medium that's not fast enough for such a configuration).
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Michael,

Thanks, that is exactly what I think is the problem, but I am loath to 
think it is a backend problem as such. Earlier in the thread I said I have :

/dev/sdf1 on / type ext4 (rw,noatime,barrier=0,errors=remount-ro) , and 
the db drive is an SSD.

Digging through https://code.mythtv.org/trac/ticket/12016, and tracing 
what I can through the source code:

On the remote frontend logs for inprogress recordings I am seeing

QUERY_RECORDER 16[]:[]GET_FRAMES_WRITTEN
issued every frame, which seems excessive, and almost certain to cause 
database hickups if the backend is writing to the same table at the same 
frequency. So I can see why no barriers might be a good plan.


My frontend running on the backend machine  does not issue these 
requests at all according to the logs, when watching the same in 
progress recording.

QUERY_RECORDER 16[]:[]GET_FRAMES_WRITTEN is only issued when the seek 
table is actually used, or the OSD is updated to show position. ( which 
makes sense)

I would say the problem is that the remote frontend is continually 
querying the recorder/database for no obviously good reason.

I mentioned in an earlier par of the thread that the dropps stopped when 
I changed or disabled the vdpau deinterlacers.

I think the db queries cause  jitter, which is badly dealt with by the 
ion 2x deinterlacers, and thats why I'm getting dropped frames.
Turning off the deinterlacer  or down to a 1x deinterlacer doesn't 
change the jitter, as the queries are still there, but it does stop 
dropping frames.

Do you agree with this analysis, and more importantly how do I stop the 
remote frontend calling  GET_FRAMES_WRITTEN every frame !

best regards,

John