[multicat-devel] Issues with recording and playback

[Eduardo Vieira]

Comments inlined.

2012/1/5 Christophe Massiot <cmassiot at openheadend.tv>:
> Le 5 janv. 2012 à 22:12, Eduardo Vieira a écrit :
>
>> First of all, I've made some optimizations in the disk access part.
>> Now I'm using XFS file system with 4k block size, and these fstab
>> options:
>>
>> defaults,noatime,nodiratime,nosuid,nodev,allocsize=64m
>
> I do not use XFS so I can't comment on this.

I followed this guide:
http://www.mythtv.org/wiki/Optimizing_Performance#XFS-Specific_Tips

>
>> I've also added this to my sysctl.conf:
>> net.core.rmem_max = 16777216
>> net.core.wmem_max = 16777216
>> net.core.wmem_default = 16777216
>
> That would certainly help.
>
>> Yet the behavior I've described to you earlier continues..
>> After a few days of testing I think I figured out what is happening here.
>> It seems that in intervals of 30 seconds the kernel blocks on the
>> write() call on the main loop while some packets arrive in the receive
>> socket buffer. When this occurs, multicat is taking longer to pull out
>> the packets from the socket buffer and saving the wrong timestamps in
>> the aux file.
>> The proof is when a remove the aux created by multicat and generate a
>> new one with ingests the video plays smoothly.
>> I can provide you links to download sample aux and ts files from my
>> server if you want (contact me privately if so).
>
> Is it better if you use -i 10 (as root) ?

It didn't helped.

>
>> To work around this problem I had 2 ideias: one is to give multicat
>> the possibility to stream a ts file based on the PCR present in it.
>
> It already exists, it's called ingests and you found out already :).

Could multicat save the stream and generate the pcr based aux file all
by itself ?
That would be awesome!

>
>> The other idea is to get the packet's timestamps based on this:
>> http://lwn.net/Articles/325929/
>>
>> What do you think ?
>
> I'd love to see that because timestamping must happen as early as possible. BTW that's what we do for the ASI input of DVBlast also. However I do not know if the API you mention is stable enough, and whether it needs to be supported by the Ethernet driver. Also I do not know if it has consequences for the other processes of the same machine. Did you investigate this ?

It seems that this feature really depends on the device driver to
implements it. I've tried to modify the code to use this new
timestamping API, but got the same results as before.

> _______________________________________________
> multicat-devel mailing list
> multicat-devel at videolan.org
> http://mailman.videolan.org/listinfo/multicat-devel

Regards,

Eduardo