lasthits: phantom hits?

[zimtzucker]

at least once a day the value "mtime" in the table "pictures" is set to the actual time on all pictures. I've integrated the lasthits on my frontpage, that's why i noticed it. Does anybody know how this can happen?

[Joachim Müller]

what do you mean exactly? Once pics exist in the database, coppermine doesn't modify the mtime. Please post a link to your page, or a screenshot. A screenshot of the phpMyAdmin screen before and after this might help as well.

Joachim

[zimtzucker]

It always happens when an admin logs in...
The attachement shows the picture table, all the mtime values are set to the last log in time of the admin

[attachment deleted by admin]

[lamama]

If I can trust the LASTHITS-view my coppermine gallery had 12176 hits to pictures tonight, all at 01:16 o'clock.

If I trust the apache server log, there were only a few 'countable' hits at that time, less then 10 on a image preview and no click to a fullsize view.

It's not the first time I'm surprised to see lots of hits at the same time and always considered crawlers, bots or leeching attempts. But it seems like coppermine has a funny minute every now and then and showing all the pics to itself

Has anyone a good explanation for that?


Maybe this topic is related to this (unsolved) thread.

[Nibbler]

I'd guess this is caused by the block of code at the end of the index page below

Code Select Expand

// Speed-up the random image query by 'keying' the image table

That would reset all the mtimes to the current time.

[lamama]

Found that code, but I've no idea how it works or what to change.

[xplicit]

I had (and still have) the same, I wanted to know what images were viewed at a specific time when a know user logged in but all time stamps were set at the same time....

Perhaps sort of a bug though?

[lamama]

It seems to be related to that piece of code Nibbler posted, maybe some unexpected side-effect of speeding up the random view, but I still have no idea what to do with that information because I don't know what to change and how that piece of code works anyway.

So let's wait until some coppermine dev team expert steps by and comes up with an advice  

[Nibbler]

If you don't use a random block you could comment out that section, I don't think it would do any harm.

[lamama]

I offer my users a random block to have some pics to start with inside a extensive gallery.

So the choice is: fast random view or correct lasthits? 

[lamama]

Hmmm. I'm not convinced that the "random code block" is responsible.

This is the code (index.php, at the end):

Code Select Expand

   // Speed-up the random image query by 'keying' the image table
   if (time() - $CONFIG['randpos_interval'] > 86400) {
       $result = db_query("SELECT count(*) FROM {$CONFIG['TABLE_PICTURES']} WHERE 1");
       $nbEnr = mysql_fetch_array($result);
       mysql_free_result($result);
       $pic_count = $nbEnr[0];
       $granularity = floor($pic_count / RANDPOS_MAX_PIC);
       $result = db_query("UPDATE {$CONFIG['TABLE_PICTURES']} SET randpos = ROUND(RAND()*$granularity) WHERE 1");
       $result = db_query("UPDATE {$CONFIG['TABLE_CONFIG']} SET value = '" . time() . "' WHERE name = 'randpos_interval'");
   }

The TALBE_PICTURES is updated only one time, and only the 'randpos' value in (line 9). Or am I wrong?

But...

The attachement shows the picture table, all the mtime values are set to the last log in time of the admin

... where does this code changes the mtime of the picture table?

And why does this happen usually one time per day?

It always happens when an admin logs in...

I usually log in and out more then one time per day but the "phantom" hits (to more or less all pics inside the gallery) appear AFAIK one time per day.

"Could someone please explain / the reason for this strange behaviour" (DuranDuran)  

[lamama]

Once pics exist in the database, coppermine doesn't modify the mtime.

... where does this code changes the mtime of the picture table?

Why didn't anybody tell me that mtime is a timestamp datatype? 
mtime get's the acutal timestamp everytime the related data record is updated, so surely also in the above code.

[kegobeer]

Why didn't anybody tell me that mtime is a timestamp datatype?

A quick look at the picture table structure (or looking at the sql file) would've told you that.

[lamama]

yesyesokok, it was a rhetorical question. :-)

I just wanted to say that Nibbler was probably right.

Anyway: GauGau doesn't seem to know (because mtime is actually modified a lot of times), nor the one who programmed that "speed up random image" thing either, otherwise he maybe had to find a better way to speed things up.

Now I finally commented out that code in index.php and will test that modification over night. Usually around 4 o'clock the "phantom lasthits" used to appear...

[Nibbler]

It's probably a good idea to assume that I am probably right and work out why later

It updates once every 24 hours, so it will of course be roughly the same time of day each time. It's not related to admin login, although if you login more often than than your users you are more likely than most to trigger the update.

Maybe it would be better to make mtime a normal field and update it specifically.

[lamama]

It's probably a good idea to assume that I am probably right and work out why later

maybe... perhaps... yes...

It updates once every 24 hours, so it will of course be roughly the same time of day each time. It's not related to admin login, although if you login more often than than your users you are more likely than most to trigger the update.

That's what I'd like to call useful information!

Maybe it would be better to make mtime a normal field and update it specifically.

I think it would be the best solution, had that in mind already yesterday but wanted to wait if the mod worked.
At least one other lasthits-problem ("why do batch-added appear in lasthits") seems to be connected to the fact that mtime is a timestamp-type. Default value for all new pictures is now the timestamp when they were added (right?), but I guess it would be more "clean" if mtime would just be unset (NULL? Empty?) until the very first time a users clicks on it.

BTW:
My Coppermine installation (1.3.2) runs fine without that "speed up random" code and I can't see that the random view had slowed down or something else. So what does that code does anyway? Setting a new random order? Is it neccessary? (I don't know how random view works in coppermine anyway, but willing to understand )

[lamama]

Maybe it would be better to make mtime a normal field and update it specifically.

Today I changed some pathnames in the pictures table manually and was finally fed up with the mtime/lasthits issue, because - of course - all touched pics had new mtimes..... :-\\

So I tried this:

1.) Changed mtime in the cpg_pictures table from TIMESTAMP to DATETIME format/datatype

2.) Modified functions.inc.php :

Code Select Expand


FIND:    (in:  function add_hit($pid) )

      db_query("UPDATE {$CONFIG['TABLE_PICTURES']} SET hits=hits+1 WHERE pid='$pid'");

CHANGE TO:

      db_query("UPDATE {$CONFIG['TABLE_PICTURES']} SET hits=hits+1, mtime=CURRENT_TIMESTAMP WHERE pid='$pid'");



Has someone from the dev team some idea if this could cause strange side effects?

What I've done:
- applied the hack above to my coppermine 1.3.2
- put the random-speedup-code (mentioned above) in index.php back in place
- removed the hack suggested for the "batch-added pics in lasthits"-issue here: http://forum.coppermine-gallery.net/index.php?topic=10570.msg52390#msg52390

Seems to work pretty fine: only "real" hits appear in lasthits. So few changes, such a nice effect

[Arlo]

This bug was driving me crazy, I'm glad I wasn't the only one! Thanks for the fix, worked like a charm.

Why the heck don't the Coppermine devs provide maintenenance releases with fixes like this while we wait for 1.4? It's been 8-9 months since an update. I switched from Menalto to Coppermine for a number of reasons, but those guys are much more on the ball with updates...anyway, rant over, thanks again.

[Tranz]

Sorry about that. This has been fixed for v. 1.4, fyi.