Advanced search  

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Pages: [1]   Go Down

Author Topic: define('RANDPOS_MAX_PIC', 200);  (Read 4106 times)

0 Members and 1 Guest are viewing this topic.

GGallery

  • Contributor
  • Coppermine regular visitor
  • ***
  • Offline Offline
  • Gender: Male
  • Posts: 61
define('RANDPOS_MAX_PIC', 200);
« on: June 10, 2004, 05:44:45 am »

what is RANDPOS_MAX_PIC doing exactly? (defined in init.php) - does it mean that that the random speedup function breaks after 200 pics?
With about 3-5k new pics daily I am sometimes getting "no random pics to display" on the frontpage - I found in index.php that every 86000 seconds the following is getting executed:
$granularity = floor($pic_count / RANDPOS_MAX_PIC);M
        $result = db_query("UPDATE {$CONFIG['TABLE_PICTURES']} SET randpos = ROUND(RAND()*$granularity) WHERE 1");M

what is that doing exactly? will that still work with e.g. 1M of pics? would it make sense to execute that more often?
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47844
  • aka "GauGau"
    • gaugau.de
Re: define('RANDPOS_MAX_PIC', 200);
« Reply #1 on: June 10, 2004, 06:37:51 am »

There have been issues before with the random pics algorhythm, and it has been subject to change for cpg1.3.0. Maybe a serach on this issue might help (not sure though, maybe it has been posted in the dev board that can't be accessed by you). I propose you take a look at the random pic code within cpg1.3.0 (or even wait for the stable release to come out and upgrade then).

GauGau
Logged

hyperion

  • VIP
  • Coppermine addict
  • ***
  • Offline Offline
  • Posts: 1317
  • - retired -
Re: define('RANDPOS_MAX_PIC', 200);
« Reply #2 on: June 10, 2004, 07:24:44 am »

The issue was bypassed in 1.3 by commenting out the more complex algorithm, which was sufficient for our purposes, but that might not be adequate if one wanted to attempt to use the random meta album with more than one million pictures.

To be honest, I am not exactly sure what this code in index.php is doing, as setting all random positions values in the pictures table to the same value would seem to contradict the query in the complex algorithm (found in meta album section of  /include/functions.inc.php -- search for 'random'), which tries to match the randompos values against a list of random numbers. Perhaps this was the source of the trouble.  I have not studied this meta album in depth, so I'll have to take a closer look before I can write about it with any confidence. 

Tarique has done most of the recent work with this one; perhaps he could give a more expedient and satisfactory explanation. 
Logged
"Then, Fletch," that bright creature said to him, and the voice was very kind, "let's begin with level flight . . . ."

-Richard Bach, Jonathan Livingston Seagull

(https://forum.coppermine-gallery.net/proxy.php?request=http%3A%2F%2Fwww.mozilla.org%2Fproducts%2Ffirefox%2Fbuttons%2Fgetfirefox_small.png&hash=f0873409e7b0238c9b018100632837e3)

Tarique Sani

  • VIP
  • Coppermine addict
  • ***
  • Offline Offline
  • Gender: Male
  • Posts: 2712
    • http://tariquesani.net
Re: define('RANDPOS_MAX_PIC', 200);
« Reply #3 on: June 10, 2004, 07:28:08 am »

what is that doing exactly? will that still work with e.g. 1M of pics? would it make sense to execute that more often?
Like was said earlier - if you are going to put 1M pictures in CPG you are best off without the Random Pic function.
Logged
SANIsoft PHP applications for E Biz

hyperion

  • VIP
  • Coppermine addict
  • ***
  • Offline Offline
  • Posts: 1317
  • - retired -
Re: define('RANDPOS_MAX_PIC', 200);
« Reply #4 on: June 10, 2004, 08:03:32 am »

Looked at it a little more. 

The index.php code is supposed to create a restrictive condition to speed up the random album SQL query by giving each picture a randompos value that the actual query will then try to match randompos against a randomly generated list (thus cutting down on the number of matches). 

The aforementioned issue could occur if the random list numbers did not match any of the randpos numbers, which would mean no results would be returned. (In some cases the list may consist of only one number -- or key.)

Anytime no results are returned (SQL timeouts and memory overflows from woking with too large a result set included), the meta album will state no pics could be found.

In functions.inc.php, RANDPOS_MAX is used to scale down the pic count to create the $granularity variable, which is in turn used to set the defining upper boundary for random number generation.  In index.php it is also used to scale down the picture count for $granularity, which is then multiplied by the SQL rand() value (between 0 and 1).  This should generate random key sets for the pictures table that observe the upper and lower boundaries. More frequent refreshing of that value wouldn't do anything but move more pictures out of the 0 key  (the default key that CPG uses for adding pictures) and into other keys, but it could be seen as more evenly distributing the images throughout the  keys.  A lower RANDPOS_MAX should increase the range of the keys available.   
« Last Edit: June 10, 2004, 09:37:02 am by hyperion »
Logged
"Then, Fletch," that bright creature said to him, and the voice was very kind, "let's begin with level flight . . . ."

-Richard Bach, Jonathan Livingston Seagull

(https://forum.coppermine-gallery.net/proxy.php?request=http%3A%2F%2Fwww.mozilla.org%2Fproducts%2Ffirefox%2Fbuttons%2Fgetfirefox_small.png&hash=f0873409e7b0238c9b018100632837e3)
Pages: [1]   Go Up
 

Page created in 0.017 seconds with 20 queries.