Hi, since upgrading to the new UCP, we have weird problem with it. Downloading of recorded messages in Call History is slow - messages are downloaded at 30 kB/s. If I run multiple downloads at a same time, every one of them is downloaded at 30 kB/s. Downloading the same recording in old User Panel (ARI) was almost instant, so we were using it in a meantime, but after upgrading to the latest 6.12.65 track, the old User Panel is not working anymore.
Downloading voice mail messages was instant even in UCP, so the only problem was downloading recorded messages (I am writing “was”, because when I test it right now, after upgrade to 6.12.65 track, it looks that downloading voice mail messages is in fact not working - it shows File Not Found. But listening to the same voice mail message works. The link for downloading is /ucp/?quietmode=1&module=voicemail&command=listen&msgid=1412606699-0000000c&format=wav&ext=232 , just for any record. But I don’t care for voice mail messages for now :)).
FreePBX box is on the same local network as other computers. Downloading recordings using Reports/CDR or WinSCP is instant.
(To the record when talking about UCP, we had the same problem with Logout button not working as was described in other thread on this forum, but we have solved it by disabling WebRTC and SMS modules, as was suggested).
Hi tm1000, after today’s CDR module update, things are even worse. While yesterday downloading of call recordings was only slow, but it worked in all three browsers, today it behaves in every browser differently:
In Chrome, when clicking on download icon, it opens new tab instead and starts to play the recording in embedded player. I can right click on it and choose “Save video as…”, but it saves the recording under some default name (saved file.wav), and the download speed is still 30 kB/s
In Firefox, the download starts, but under random file name (with speed 30 kB/s)
In IE, new tab opens, but nothing happens (and the download never starts).
I should say again that in CDR (Reports -> CDR Reports), when clicking on the download icon, download starts in all browsers (edit: under correct file name of the recording) and is almost instant (more than 20 MB/s !)
We can keep arguing about this but I’ve already stated my results. Over the internet I get 500-600 kb/s. Locally I’m sure it would be faster but all of my machines are remote and get faster speeds than yours.
My goal is not to argue, I am here to seek help for a problem we are facing on our FreePBX box. The fact is that downloading of recordings worked allright in ARI (for like two years or more), works allright in CDR, but doesn’t work right in UCP. And with all respect, the fact that it is working for you doesn’t mean that there could not be some kind of problem that under specific circumstances prevents it to work for others. All I did to “break” it was to run the upgrade script.
(I would gladly use old ARI, which was working perfectly for us (even at the same time when UCP wasn’t), if it wasn’t removed in track switch upgrade.) Never mind, I have found FreePBX ARI Framework module under Unsupported modules, which brought me old ARI back, so I will be happy with it until things get better with UCP…
Yes I realize that but I am stating my testing attempts over various machines, not just one machine (I have tested with 3 machines now over entirely different networks). The fact that you get slow speeds and then failed to provide me any information about your system (of which I requested) only makes this more difficult to diagnosis and you can’t seriously expect anything to improve over time if you won’t provide what is requested.
No hard feelings here but all you have provided so far is that “UCP gives me 20 kb/s while ARI gives me 20mb/s” you can’t seriously think anyone could help to fix your issue with such little information could you? (yes you provided the fact that you are using the distro and your versions and that was helpful but I need hardware specs now)
Network type, server type and specs. These things are helpful to figuring this out…
Okay, I appreciate your help, and yep, I forgot to add our machine specs, sorry.
Our box is HP ProLiant DL320 G5 with dual core Xeon on 1.8GHz, 2GB of RAM, two 160GB disks in Software Mirror RAID and gigabit network card. We are using gigabit switch (HP V1910-24G).
Hmmmm. I made some modifications to differentiate “downloading” from “streaming” (which was/is listening through the browser). I made these changes to both CDR and Voicemail and just pushed it out 2 minutes ago but I am not sure thats going to help you at all as the behind the scenes methodology is the same.
Because streaming will not work correctly in UCP if that is done. Those functions that you are pointing to are very old, I have to pass data between two functions in UCP because of it’s abstractedness (meaning it can be put on a different server than what freepbx is on) because of that I can’t use simple functions that CDR Reports gets away with.
I did more testing last night on two servers and I averaged 500 - 600 kb/s over the internet, haven’t tried locally but I can assume it would only be quicker.
I’ve also been experiencing 2kb/s downloads in UCP from the Call History.
I’m no PHP developer, so my fix may be flawed, but I narrowed it down to the 8k buffering going on in readRemoteFile found in cdr/Cdr.class.php. I think the inefficiencies are caused by the repeated file opening/closing going on in readRecordingBinaryByRecordingIDExtension.
I started out by increasing the buffer size from 1024 * 8 to 1024 * 1024 and got huge gains. Then I replaced lines 392-406 with this and got stellar results.
There may be other unintended consequences in taking this approach, but there’s definitely some improvement in this function required to get reasonable throughput during downloads
Doing it that way you break the ability to abstract UCP onto a machine that doesn’t have FreePBX on it. What you think are inefficiencies are actually a way to pass the wav file over a restful api without exposing the location to your wavs. Reading the file directly through UCP breaks the whole premise of this concept and you’ll just have to keep adding your patches over time
Doing readfile() at that level breaks the abstractness of UCP because during abstraction the wav files are not available for UCP, it would have to query them from a freepbx server.
That’s a reasonable explanation, however, this function is already dealing directly with the file in the if conditional around the switch-case statement directly above the file transfer logic. I can’t see the abstraction being a compelling feature for anyone with large files at the current transfer rate.
The “is_file” function needs to be moved to the FreePBX part for abstraction. It’s a work in progress and has not been fully vetted yet. UCP was designed “theoretically” with abstraction in mind. I am just explaining the theory behind the function and not saying that it works 100%. Reversing the functionality of a function that is already abstracted is going back on the design principles of UCP. The transfer rate of 2kb/s seems to be system specific as I am still unable to replicate it (getting 230kb/s here).
What this really boils down to is the fact that I think UCP needs a mode to declare “local” or “remote”. In “local” mode it would use something like readfile, in “remote” it would use something else. This is a better solution than just replacing everything with readfile (note that readfile doesnt buffer anything into RAM). Speaking of this readfile issue, would you be willing to give me your system specs?
Anyways I am not here to argue. You did say “I’m no PHP developer, so my fix may be flawed” so I figured you were looking for a reasonable explanation instead of nit-picking the function apart I hope I’m right. It’s open source so you can continue to keep applying your patch well into the future. No one is going to stop you and it’s all cool with me.
It’s all cool, I mostly wanted to corroborate the original poster’s experiences and point out the likely bottleneck.
My system is a current generation i5 with 4GB RAM and an SSD. Over the local gigabit LAN in the original configuration, my browser estimated over 12hr to download a 121MB conference call recording. Increasing the buffer size from 8k to 1024k resulted in about a 12min download. Using readfile() resulted in <10s. I like the idea of local/remote mode. I was able to get tolerable performance using the existing code as long as I used larger buffers. Perhaps that’s a good compromise for those of us with slow performance until UCP is fully ready to run remotely.
I made the replacement in two places. I do not know accurate line numbers because I hacked the file before doing that, so my line numbers would be off.