[asterisk-dev] [Code Review] Fix issue 17078: MixMonitor records shorter files than the call duration.

[David Vossel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/611/#review1857
-----------------------------------------------------------

Ship it!


thanks for checking, looks great!

- David


On 2010-04-07 17:13:35, Dwayne Hubbard wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/611/
> -----------------------------------------------------------
> 
> (Updated 2010-04-07 17:13:35)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Mantis issue 17078 reports that MixMonitor records shorter files than the call duration.  This was because the mixmonitor thread was not processing frames received from the audiohook fast enough.  The mixmonitor thread would slowly fall behind; when the channel hung up, the mixmonitor thread would exit without processing the same number of frames as the channel and leaving the mixmonitor recording shorter than actual call duration.
> 
> This revision fixes this issue by moving the ast_audiohook_trigger_wait() and the subsequent audiohook.status check into the block where ast_audiohook_read_frame() returns NULL.
> 
> 
> This addresses bug https://issues.asterisk.org/view.php?id=17078.
>     https://issues.asterisk.org/view.php?id=https://issues.asterisk.org/view.php?id=17078
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/apps/app_mixmonitor.c 256422 
> 
> Diff: https://reviewboard.asterisk.org/r/611/diff
> 
> 
> Testing
> -------
> 
> I had access to geoff2010's equipment and was able to reproduce the issue.  After the fix, I verified that the issue was resolved.  geoff2010 has been running with this patch on multiple systems in a live environment and has also verified that the issue is fixed with this patch.
> 
> 
> Thanks,
> 
> Dwayne
> 
>