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

[Terry Wilson]

> On Nov. 11, 2011, 7:48 a.m., opticron wrote:
> > /branches/1.8/res/res_musiconhold.c, line 1443
> > <https://reviewboard.asterisk.org/r/1579/diff/1/?file=21693#file21693line1443>
> >
> >     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.

You can't put things up in the above block, because the above block is if (var) which will fail when we are pulling back a cached realtime class. I did add a var = NULL after ast_variables_destory() and add a check for !var to the check so that we don't scan the files twice on first load.


- Terry


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


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/20111112/f6fa3817/attachment.htm>