[multicat-devel] Issues with recording and playback

[Christophe Massiot]

I confirm the problem. I will think about it…

Le 16 janv. 2012 à 18:40, Eduardo Vieira a écrit :

> Hi,
> 
> I'm still here trying to solve this...
> I've tested in 3 different computers and all of them presented the
> same behaviour: multicat is always generating a problematic aux file,
> with wrong timestamps, in intervals of 30 seconds. And it's definitly
> caused by disk access bottleneck. When I used a tmpfs partition ( aka
> RAMDISK), the stream is saved with no problems.
> I'm using SATA2 disks for the tests, I guess they should be able to
> handle the 10 Mbit/s data throughput. But, just in case, I'll ask
> this.
> Is there anyone here succesfully using multicat to save multicast
> streams and after playing  them back without problems ? Could you
> please send me your hardware specs ? Will this only works on SCSI (or
> faster) disks ?
> I'm running out of ideias on how to work around this :(
> 
> Best Regards,
> 
> Eduardo
> 
> 2012/1/9 Eduardo Vieira <eduardovra at gmail.com>:
>> 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
> _______________________________________________
> multicat-devel mailing list
> multicat-devel at videolan.org
> http://mailman.videolan.org/listinfo/multicat-devel