mmmm...
I guess you didn't read my PM...

And here I thought it was you. :) I sent you the code via e-mail last week.

I'll send a followup PM to you.

is it possible for me to beta test 2.0 ? :)

Version 2 uploaded with screenshots.

https://vborg.vbsupport.ru/showthread.php?p=528801

Among other new features, it includes forum support, including searching by forum and permission support.

CarCdr

I uploaded the file but, it doesn't load :( I gave it a good 10 minutes. Any ideas?

I have about 16,000 attachments and use 804 Mb. for attachments. Is this the problem?

EDIT It finally loaded after a long, long while. Is that normal?

Miguel

16,000 attachments hey. Hmmm... the browser only makes two queries, one to get the count of attachments you have access to (i.e., MySQL "COUNT(*)) and the other to load a page worth of attachment information.

Also, it does not retrieve the actual content, so the rows retrieved are quite small.

We have about 400 attachments and it loads very quickly.

I'd like to add a debug parameter that you could use to get feedback on what is taking so long. That way, you could get back to me about where it is eating the time.

Sure, just let me know what I need to do. It looks like a very useful tool. I f I could speed it up, I'd be a happy man :)

It said I had 772 Pages of attachments. If that matters.

Thanks,
Miguel

The 772 pages is just the count you get for 1400 attachents at the default of 20 per page. Like I said, it only retrieves the actual attachment table rows for the target page. I assume you were getting just the first page, so it would be retrieving the first 20 rows. We'll time the two queries to see which one is so slow. I expect it is the "count(*)" query.

If this is the case, one alternative is to not to the page navigation stuff, thereby obviating the need to do the "count(*)" query. One would only retrieve the target page plus one extra to see if there is a next page.

Other ideas folks?

I have made some optimizations to attachment_browser to improve the speed of the queries.

1. Only include a table JOIN if it is really required.
   We look at a query before running it to determine which tables to join. Before, we would always include all tables in addition to attachment: user, post, thread, forum.
2. Do not use a forum table JOIN.
   Got rid of references to 'forum.forumid' and 'forum.title'. Retrieve the forumid from the thread table join, which we likely need anyway for checking thread.forumid. Retrieve the forum titles for the page after the fact using the forum cache. The only time we need the forum table JOIN is when user request a sort by forum title.
3. Include forum access check only if required.
   The check for "thread.forumid IN (Accessible-Forumids)" is included only if required -- only if user does not have access to all forums.
4. Be default, there is no sub-sort (i.e., 2nd-level sort)

As a result, the two queries do run faster for default display.

Query #1: The 'COUNT(*)' query runs anywhere from 20% faster to 5 times faster (MySQL caching must explain this huge range.) This was by far the slower of the two queries.

Query #2: The row retrieval query to get the rows for the target page runs about 9% faster, but that is not so important as it was the fast query anyway.

PM me an e-mail and I'll send you the new version. Once we agree that things still work properly and you verify the performance increase, I will post the new version here.

Cheers

Hello,

Long time lurker, but decided to register since this modification interests me. My community has over 15,000 attachments with over 5.5Gb of data. I converted to file storage format to save on my server load. So I was wondering if this modification would work since I've done that? Also, is there a way to limit access to the mod itself? Like say, only grant access to a paid subscription member, moderator, or administrator specific?