System recordings Slow for large filesets

I must have missed that part of the patch when looking at this. Go ahead and add a patch (call it something.patch so it is viewed with the diff viewer please). If it looks low risk once reviewing we may be able to consider it for 2.5 but for now moving into 3.0 and relabeling a feature request.

Patch added as discussed.

I've also added some sanity checking around the delete and move buttons.

Let me know what you think.

can you please provide a qualitative description of what you changed in the patch that makes it go quicker? From a quick glance at the patch it was not clear (although I have not had any coffee yet this morning, which may be why).

A solution that I had envisioned was to load all the sound files once into a javascript, and then just the selection that was chosen for each. Once you first select on any of the boxes, use the javascript to initialize the select box. That would be a huge improvement. But again - describe what you did above to improve it if you would. Thanks.

Can't load to test it either, this is against the latest in svn where you need to be making patches against for 2.5:

[root@mybox recordings]# patch -p0 < /tmp/recordings.patch 
(Stripping trailing CRs from patch.)
patching file functions.inc.php
Hunk #1 FAILED at 177.
Hunk #2 FAILED at 200.
Hunk #3 FAILED at 222.
Hunk #4 FAILED at 294.
Hunk #5 FAILED at 304.
Hunk #6 FAILED at 315.
Hunk #7 FAILED at 334.
7 out of 7 hunks FAILED -- saving rejects to file functions.inc.php.rej
(Stripping trailing CRs from patch.)
patching file page.recordings.php
Hunk #1 FAILED at 302.
Hunk #2 FAILED at 335.
Hunk #3 FAILED at 357.
Hunk #4 succeeded at 402 with fuzz 2.
Hunk #5 FAILED at 436.
Hunk #6 FAILED at 480.
Hunk #7 FAILED at 506.
Hunk #8 succeeded at 544 with fuzz 1.
6 out of 8 hunks FAILED -- saving rejects to file page.recordings.php.rej

Replying to p_lindheimer:

Can't load to test it either, this is against the latest in svn where you need to be making patches against for 2.5:

... SNIP ...

New patch against svn source supplied.

I had thought of using javascript to dynamically add textboxes and move selections from the selection dropdown, however needing something reasonably quickly, and having not used javascript much at all, I resorted to what I know. 8)

The patch does the following:

1. Removes the programatically built dropdowns on each line.
2. Adds a single drop down.
3. Adds a text box to specificy a location at which to update and soundfile.
4. Added some sanity checking around the movement icons.

Speed is significantly increased due to the removal of the requirement to build a large option list for a select box on each line.

If time permits, I'll look further at the Javascript solution for future improvement.

Ok, I loaded your patch so I can see what you are doing. The concept may work but I am not happy with some of the aspects. I don't like that the text boxes can be edited thus inserting bad values and I don't like that you have to type in the number and then press submit to add the value.

If you made it a bit more like the quick picks for ringgroups, but with the text boxes read only, it might work. It would also require another select box to choose which recording you are inserting/replacing.

However - I still prefer the idea of downloading it once and the populating the other select boxes through javascript when you need to access them.

Comments taken on board.

I've now changed it thus:

• Recordings list is loaded once at page load.
• There are no postbacks until the "Save" button is clicked
• All textboxes are readonly
• Insert or update is determined from a group of radio buttons
• Insert/update position is selected from a dropdown list
• Javascript is used to:
  • Insert new recordings (either at the end or at selected step.)
  • Move recordings up and down
  • Delete recordings
  • Play recordings

Any chance this can be included as an update to 2.5?

prolfe, I've been swamped with getting 2.5 out and Astricon coming up next week so I have not had a chance to load up your change, which means it will probably be a couple weeks until I do (sorry). Once it is loaded up I'll be better able to answer. In the interim it would be good to get some feedback of some of the other devs to take a look.

Attaching a patch against the 2.6 branch of page.recordings.php (although I think it would apply to 2.5 also). It loads the select for the first recording and leaves the other select boxes empty with just the current value in a hidden input box. It then uses a jQuery javascript call upon page load to populate all the other select boxes. So it removes the download time although the javascript can take some time to run depending on the client.

modified to fix bug and also remove the "value=xyz" from the option tags since they will default to the display setting.

One issue with this patch. I find in testing that downloading the data on a lan is quicker then this javascript version. There may be more efficient ways to do it or it may be that we need to keep the current implementation with a setting to switch to this version if you are running over slow WAN connections.

image to go with newest file, goes in the recordings/images directory

updated patch to provide feedback when the select box is being loaded

(In [7314]) re #3059 load 2nd-nth select box on demand from 1st select box with jQuery to reduce the length and overhead of the initial download from the long redundant select boxes that were created