| Summary: | ASTERISK-12512: When calling a queue, after a few loops over a madplay'ed file, the MOH ceases to be played | ||
| Reporter: | Corentin Le Gall (clegall_proformatique) | Labels: | |
| Date Opened: | 2008-08-04 05:07:48 | Date Closed: | 2008-12-10 16:04:14.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_musiconhold |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) bug13229.patch | |
| Description: | When one enters into a queue, with such a musiconhold configuration : [noloopqueue] mode=custom application=/usr/bin/madplay --mono -a -10 -R 8000 --output=raw:- directory=/var/lib/asterisk/moh/noloopqueue in which there is only one mp3 file (did not try with more files), the file is played only a few times, then there is silence. * This occurs more easily with short sound files (5 - 10 seconds for instance) * This occurs when ztdummy is used for the timing I hesitated between "always" and "sometimes" for the Reproducibility field above, since in some way, the problem always occurs, but after a time that can be long. As stated above, with 5-10 seconds mp3 files, I never could reach more than 3 loops without being shut up. With a 30 seconds file, I had to wait between 6 and 20 loops before being shut up. Anyway, it finally happens. ****** ADDITIONAL INFORMATION ****** * As far as I have been able to trace it, we have 2 threads who share the pid number, related to the madplay spawned. ** in the one that calls "monmp3thread", the class->pid is set to 0 each time the file's EOF is reached, before being forked and set to != 0 again and again ... ** in the one that calls "moh_generate", the MOH is stopped once moh->parent->pid is found to be zero The point seems to be that sometimes, we are between 2 forked madplay's, so that the pid is 0, but nothing prevents "moh_generate" to read this value and end the music there. | ||
| Comments: | By: Jeff Peeler (jpeeler) 2008-11-25 18:37:28.000-0600 Test this to make sure it behaves as expected. I'm most concerned with other music on hold scenarios. Also, the sleeping only occurs for http locations since they seemed to be added originally only for failing media streams. By: Jeff Peeler (jpeeler) 2008-11-25 20:45:39.000-0600 Well, I just noticed that Asterisk doesn't shut down gracefully so something is wrong with the patch. By: Jeff Peeler (jpeeler) 2008-12-01 12:18:22.000-0600 Oops, something unrelated was going on here. This patch should be fine. By: Digium Subversion (svnbot) 2008-12-10 16:04:13.000-0600 Repository: asterisk Revision: 162874 U branches/1.4/res/res_musiconhold.c ------------------------------------------------------------------------ r162874 | jpeeler | 2008-12-10 16:04:13 -0600 (Wed, 10 Dec 2008) | 5 lines (closes issue ASTERISK-12512) Reported by: clegall_proformatique Ensure that moh_generate does not return prematurely before local_ast_moh_stop is called. Also, the sleep in mp3_spawn now only occurs for http locations since it seems to have been added originally only for failing media streams. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=162874 | ||