Print

[GGallery]

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?

[Joachim Müller]

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

[hyperion]

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. 

[Tarique Sani]

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.

[hyperion]

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.