[asterisk-bugs] [Asterisk 0017807]: Music on hold doesn't recover very cleanly when it can't play a file

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17807 
====================================================================== 
Reported By:                kshumard
Assigned To:                bbryant
====================================================================== 
Project:                    Asterisk
Issue ID:                   17807
Category:                   Resources/res_musiconhold
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                       SWP-2016 
Regression:                 No 
Reviewboard Link:           https://reviewboard.asterisk.org/r/910/ 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-08-06 11:35 CDT
Last Modified:              2010-09-09 12:25 CDT
====================================================================== 
Summary:                    Music on hold doesn't recover very cleanly when it
can't play a file
Description: 
I found that MOH using default files misbehaved in 1.8.0-beta1 because of a
dot in the filenames of the LICENSE, CHANGES, and CREDITS files. I see that
this has been fixed in 1.8.0-beta2 by renaming those files so they don't
include a dot. But this uncovered something else that it wouldn't hurt to
address.

When res_musiconhold can't play a file in one of its classes, it stops
musiconhold and just waits indefinitely.

I suggest that a cleaner way to handle this would be to skip the file it
can't play (and perhaps remove it from the musicclass) and continue on to
try to play the next file in the class. As it is, MOH stops and there's
just dead air on the channel until it's hungup or taken off hold or
whatever. Logging a warning and playing another file is IMO a saner/cleaner
way to fail.
====================================================================== 

---------------------------------------------------------------------- 
 (0126781) svnbot (reporter) - 2010-09-09 12:25
 https://issues.asterisk.org/view.php?id=17807#c126781 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 285641

_U  trunk/
U   trunk/res/res_musiconhold.c

------------------------------------------------------------------------
r285641 | bbryant | 2010-09-09 12:25:25 -0500 (Thu, 09 Sep 2010) | 28
lines

Merged revisions 285640 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r285640 | bbryant | 2010-09-09 13:23:28 -0400 (Thu, 09 Sep 2010) | 21
lines
  
  Merged revisions 285639 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r285639 | bbryant | 2010-09-09 13:22:25 -0400 (Thu, 09 Sep 2010) | 14
lines
    
    Merged revisions 285638 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r285638 | bbryant | 2010-09-09 13:20:17 -0400 (Thu, 09 Sep 2010) | 7
lines
      
      Fixes an issue with MOH where it doesn't recover cleanly when it
can't play a file and would just stop, instead of continuing to find the
next playable file in the MOH class.
      
      (closes issue https://issues.asterisk.org/view.php?id=17807)
      Reported by: kshumard
      
      Review: https://reviewboard.asterisk.org/r/910/
    ........
  ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=285641 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-09 12:25 svnbot         Checkin                                      
2010-09-09 12:25 svnbot         Note Added: 0126781                          
======================================================================