Ticket #2511 (closed Bugs: fixed)

Opened 4 years ago

Last modified 4 years ago

Proble when adding more than 10 recordings

Reported by: dgonzalezh Assigned to: abrown
Priority: major Milestone: 2.5
Component: Announcements Version: 2.3.1
Keywords: Cc:
Confirmation: Confirmed SVN Revision (if applicable):
Backend Engine: Asterisk 1.4.x Backend Engine Version:

Description

I'm using FreePBX 2.3.1 and Asterisk 1.4.14 and I was doing a demo with the Bukt-in recordings, and some pre-made recordings; after I added the 10th item on the list FPBX got extremely SLOW, to add more fields, then when I pressed the Save button it took forever for the frog to come up. And what a surprise when I checked the IVR entry for that recording ti just played 12 items of the 15+ I had added. On the Asterisk CLI I see them going trgu Ok with no errors but It just stops playing after it reaches the 12th element, and throws me back to the previous menu.

This is the way FreePBX created the entry on extensions_Additional.conf 

[app-announcement-4]
include => app-announcement-4-custom
exten => s,1,GotoIf($["${CDR(disposition)}" = "ANSWERED"]?begin)
exten => s,n,Answer
exten => s,n,Wait(1)
exten => s,n(begin),Noop(Playing announcement demo-vitor)
exten => s,n,Playback(dictate/digits/1&digits/2&digits/3&digits/4&digits/5&digits/6&digits
/7&digits/8&digits/9&digits/0&digits/day-0&digits/day-1,noanswer)
exten => s,n,Goto(ivr-2,s,1)

; end of [app-announcement-4]

This is the announcement it created: 

[app-announcement-1]
include => app-announcement-1-custom
exten => s,1,GotoIf($["${CDR(disposition)}" = "ANSWERED"]?begin)
exten => s,n,Answer
exten => s,n,Wait(1)
....
exten => recording-12,n,Hangup
exten => recording-20,1,Answer
exten => recording-20,n,Playback(dictate/digits/1&digits/2&digits/3&digits/4&digits/5&digi
ts/6&digits/7&digits/8&digits/9&digits/0&digits/day-0&digits/day-1&digits/day-2&digits/day
-3&digits/day-4&digits/day-5)
exten => recording-20,n,Hangup
exten => recording-17,1,Answer
...
exten => recording-16,n,Playback(custom/test-saludo)
exten => recording-16,n,Hangup

; end of [ext-recordings]

Those are the only related entries.

Is this an Astereisk bug, or is it a FreePBX 2.3.1 issue?.

Has anyone had this behavior before?. I'm clueless here, thanks for the info you can proivide me with.

Attachments

recordings_patch.txt (4.3 kB) - added by prolfe on 11/28/07 18:43:37.
ivr_install_sql_patch.txt (0.8 kB) - added by prolfe on 11/28/07 18:44:12.

Change History

11/28/07 18:42:24 changed by prolfe

The above report is in fact two serperate issues.

1. The IVR issue:

The ivr module storages the "announcement" selected from the system recordings menu as a VARCHAR(255) field comprised of files (with paths) that make up the recording. This obviously becomes an issue if the user has a large number of sounds making up their recording, or if the sounds are in a reasonably deep directory structure.

The fix is to change the field type in the database from a VARCHAR(255) to a TEXT field , thus alleviating this problem. I've attached a diff for the install.sql file, however to change this on a running machine, login to your mysql server via the command line, and (data will be preserved, however make a backup first): 

alter table ivr modify announcement text;

2. The speed of the recordings module

The recordings module slows down dramatically as more sounds are added to each recording. This is due to the nature of the page whereby each dropdown box is fully populated with all sound files when the page is built. An example:

1. User has some 4000 sounds. 2. User creates a recording and adds 7 sound files to it. 3. Recordings module becomes very slow.

The reason here is that now the page has 8 dropdown boxes on it (7 for the sounds, an d 1 for any new sound to be added), and thus the page is built by progammitically building each dropdown box individually. This not only takes time, but results in a page source of some 28000 odd lines. Slowness ensues.

I've attached a patch which addresses this issue by providing only 1 dropdown box, and selections are then passed to a "flow" which is a collection of textboxes storing the sounds to be played. Not only is this much quicker, but it is also more flexible, as sound names can be typed (or cut and pasted) directly into the textboxes. All other functionality is maintained.

Hope this helps.

11/28/07 18:43:37 changed by prolfe

  • attachment recordings_patch.txt added.

11/28/07 18:44:12 changed by prolfe

  • attachment ivr_install_sql_patch.txt added.

02/07/08 13:46:54 changed by p_lindheimer

  • confirmation changed from Unreviewed to Confirmed.
  • milestone changed from Cut Line to 3.0.

Not sure why this got missed in the 2.4 planning but it did, so moving to next milestone. The varchar(255) vs text issue is an indirect by-product on how recordings are stored which should change but got pushed to the next release. The IVRs, RingGroups, etc. should not be storing the name of the files, simply a recording ID thus getting rid of that issue. In any event, we can review the contributed patches when we embark on the next milestone.

07/23/08 00:56:31 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to fixed.
  • component changed from System Recordings to Announcements.

looks like this bug was for announcements which has been fixed in r6128, see #2063. (And other modules will be addressed the same way)