record, replay & [detect-ads] overload

[MymsMan]

The source is available on github if anyone cares to investigate .

I have just completed coding the changes to DetectAds to run cpulimit on a specific process id which shouldn''t suffer the problem of the long running task.
However when testing I found that while it works from the command line when I invoke it within detectads it generates the process found message and then quits

        exec /mod/bin/cpulimit -l $cpulimit -p $ffmpegpid &

I don't know what is wrong so I will need to investigate more

The new version will also includes orphaned file clean up, sweeper rules update and Back button returning to flexview.

 

[MymsMan]

The problem with cpulimit turned out to be simple to fix once I had tracked it down, I was hitting a timing window where the ffmpeg process was not yet fully active - adding a sleep 3 provided a sufficient delay to allow limiting to work properly.

However cpu limiting in itself may not solve all the problems. When running with 2 simultaneous HD recordings in chaseget mode with cpu limited to 40% I came across a recording that couldn't be processed by detectads.
Further investigation showed that it was failing in ffmpeg, probably due to a corrupted data packet during recording it thought that the recording had 28 audio channels rather than the usual 2 or 6!

[aac_latm @ 0x4457c0] Sample rate index in program config element does not match the sample rate index configured by t                                                                                         he container.
[aac_latm @ 0x4457c0] Evaluating a further program_config_element.
[aac_latm @ 0x4457c0] Sample rate index in program config element does not match the sample rate index configured by t                                                                                         he container.
Input stream #0:1 frame changed from rate:48000 fmt:s16 ch:6 to rate:48000 fmt:s16 ch:28
[SWR @ 0x478cd0] Value 28.000000 for parameter 'ich' out of range
Unsupported number of input channels

I am not sure what I can do about such problems or how to distinguish it from a retry able type of problem

Seem to have found a file that detectads cannot process. Overnight it processed several files before getting to this one, then it locked up the box (on but unresponsive), had to power it down. Powered it up again (about 6:30), but having come home from work, I find it locked again. The detectads log shows nothing after reporting "22/03/2016 06:28:03 DA(3109)- ==DETECTADS Chase Run:" this morning. Sysmon is showing no data after 8:30. I have removed the detectads queue file to prevent it from attempting to process the file again.
Any suggestions for diagnostics?

My problem did not cause a box lock up, do you still have the recording that caused the problem?
If you do have the recording could you try manually decrypting it via the webif,
if that works try running DetectAds on the decrypted file,
if that doesn't work could you try running ffmpeg from telnet to see if that shows anything:

 ffmpeg -i "your decrypted video file.ts" -vn -sn -ac 2 -f au pipe:1 > c4.mp3

if that works then try:

/mod/webif/plugin/detectads/silence  4567 -75 0.1 5 60 90 1 < "c4.mp3"

 

[MymsMan]

I have updated the Detectads and Chaseget packages to include the cpulimit and other changes

The setting option will only be visible if cpulimit is installed.

40% seems a reasonable value if using chaserun processing, 50% if using traditional but please experiment and report back if cpu limit seems to make any difference positive or negative.

 

[hairy_mutley]

My problem did not cause a box lock up, do you still have the recording that caused the problem?
If you do have the recording could you try manually decrypting it via the webif,

Afraid not...
Following our original discussions of the problem regarding stray -dec files and the use of cpulimit, I successfully cleared temp files and applied cpulimit to process this file.