[multicat-devel] Issues with recording and playback

[Eduardo Vieira]

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