[asterisk-dev] [Code Review] Don't forget to rescan MOH files for cached realtime MOH classes

[opticron]

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

Ship it!



/branches/1.8/res/res_musiconhold.c
<https://reviewboard.asterisk.org/r/1579/#comment8943>

    Very similar code already exists here.  I'd recommend either putting the change in the above if block to keep things consistent or combining both just after this else block.  Otherwise, the change looks good.


- opticron


On Nov. 11, 2011, 3:35 a.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1579/
> -----------------------------------------------------------
> 
> (Updated Nov. 11, 2011, 3:35 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Realtime MOH class caching was implemented because without it, you would build a completely new MOH class and would start the music over at the beginning each time hold was pressed in a conversation. Unfortunately, this broke re-scanning for file changes for realtime MOH classes. This patch corrects that issue.
> 
> 
> This addresses bug ASTERISK-18039.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18039
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/res/res_musiconhold.c 344438 
> 
> Diff: https://reviewboard.asterisk.org/r/1579/diff
> 
> 
> Testing
> -------
> 
> Set cachertclasses=yes and ensured that moh continued between hold presses and that replacing the MOH file caused the next instance of hold to play the new file as expected.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111111/6d34e508/attachment-0001.htm>