| Summary: | ASTERISK-18039: Realtime music restarts from beginning each time | ||
| Reporter: | Alistair Cunningham (acunningham) | Labels: | |
| Date Opened: | 2011-06-20 07:00:15 | Date Closed: | 2011-11-11 22:06:15.000-0600 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_musiconhold |
| Versions: | 1.8.4 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) realtime_moh_files.txt | |
| Description: | If realtime music is stopped and started again in the same call, it restarts from the beginning each time. Non-realtime music (configured manually in musiconhold.conf) correctly continues from where it left off. | ||
| Comments: | By: Alistair Cunningham (acunningham) 2011-10-31 18:24:59.663-0500 Has there been any progress on this? By: Alistair Cunningham (acunningham) 2011-11-10 22:01:51.469-0600 To clarify, the system has "cachertclasses = no" set because it's part of a cluster with multiple web machines and multiple Asterisk machines, and the Asterisk machines need to pick up new music when a user uploads new music on a web machine. By: Terry Wilson (twilson) 2011-11-11 03:23:55.572-0600 The implementation of cachertclasses was incomplete since it would never rescan the available files like the non-cached version. The reason for caching is so that we don't have to create an entirely new class each time (load from the db, alloc the class, and start the MOH from the beginning each time hold is pressed in the same call. This corrects the problem that cached realtime classes could never see new files without a reload--which completely defeats the purpose of realtime. | ||