[asterisk-users] bounty for ASTERISK-17474 streaming MusicOnHold bug

[Luke Hamburg]

Right -- I've been wrestling with this problem for over a year now.
Tinkering with modules.conf load order, "noload= / preload=" etc I even
modified the internal "priority" of the timers in the C code of the timing
modules so that after a reload the pthread timer would still be at a higher
prio than the DAHDI timer. For example in res_timing_pthread.c: around line
54: "priority = 0" change to "priority = 250" which puts it higher than
DAHDI.  That hack actually worked but messed up so many other things that it
was useless in production.  

The only "real" solution is going to be someone diving into the
res_musiconhold.c code to figure out
a) why after reload does it use the dahdi timer instead of pthread
b) why doesn't it play nice with the dahdi timer

It could be a bug in res_timing_dahdi or res_musiconhold, or even somewhere
else.  I wish I knew more about the code to debug this.  That's why I
thought maybe starting the bounty would help.  Vladimir I know you're
affected by this bug too as I've seen you posting to the bugtracker -- would
you be interested in putting up any $ towards the bounty?  I think if I
could get $500 together someone might take it upon themselves to actually
fix this once and for all...


-----Original Message-----
From: Danny Nicholas [mailto:danny at debsinc.com] 
Sent: Monday, September 26, 2011 10:43 AM
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: Re: [asterisk-users] bounty for ASTERISK-17474 streamingMusicOnHold
bug

Too early in the day - as I read this "dahdi restart" probably won't work
correctly in the scenario as I follow it.  The only workable scenario I see
here is an asterisk restart since the dahdi timers "hose the works";.