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:48Date Closed:2008-12-10 16:04:14.000-0600
Versions:Frequency of
Environment:Attachments:( 0) bug13229.patch
When one enters into a queue, with such a musiconhold configuration :

application=/usr/bin/madplay --mono -a -10 -R 8000 --output=raw:-

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.


* 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.