[mythtv] ringbuffer.cpp

Warpme warpme at o2.pl
Sat Feb 15 20:06:02 UTC 2014

On 15/02/14 06:38, Jean-Yves Avenard wrote:
> Can you guys test the patch in this ticket?
> https://code.mythtv.org/trac/ticket/12045
> It has fixed all issues for me since I've applied it. Three frontends
> have been running liveTV for the past 5 hours, there's been no
> interruption; it hasn't happened in months before.
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
I still believe there is reason to have fsync in separate thread. 
Probably major one is that execution time of fsync isn't deterministic 
and using it directly in realtime task (tfw) sooner or latter will make 
problems. I can imagine huge dirty pages set flushed by flusher to 
persistent storage. This can take tents of seconds and in this period 
write operation will be blocked.
 From 12045.patch & discussion I understand that moving to synchronous 
write & fsync operations "fixes" problem. I think it rather masks 
problem as I believe root cause is somewhere within OS mass storage 
subsystem. I think it is worth to nail root cause. Maybe You can start 
with as simple as possible storage setup (single local HDD with ext3, no 
any LVM/mdadm/raid) and see how it works? If issue will be still present 
- You can consider test with different distro. Archlinux is good 
candidate as it is known with usage "vanilla" OS components (minimal or 
zero patches) for kernel/libs/tools/programs. Arch users are reporting 
perfect stability on their forums. I still believe given component 
original devs are better in fixing problems than packagers (like i.e. 

More information about the mythtv-dev mailing list