Bug - Fixed Price Update not working

Winterbay

Winterbay

Active member
I've set Mafia to atomatically update prices from kolmafia.us from the nifty preference for this purpose. It does however not appear to be working.

I've logged in with new sessions three times today, with the same character, and every time the prices have been updated. Between 1046 and 3000+ prices to be exact (the 1046 was direct after a login that updated over 3000). Every time I have done a check of first the historical price (historical_price();) and then the mall price (mall_price();) for "pile of dusty animal bones".

The result for the first one have been the same all three times, 1635 meat, and the mall price in the vicinity of 300 meat. After having checked the mall price the second time I logged out cleanly, exited mafia and restarted it again. Logged in and got the exact same values.

The question is thus: Does Mafia only get prices but never upload them or is there some other wonderful error involved?

First login today was made with r8474 and the second and third ones with r8479.
 
As I pointed out in the other thread, the timestamps coming from http://kolmafia.us/scripts/updateprices.php?action=getmap are around 1278937605 which is some 36 days in the future. This prevents correct data from being uploaded, because they are rejected as out-of-date.
Mafia itself is working correctly (future timestamps are clamped to "now", probably assuming that the difference will never be significant), but
1) the server-side data should be purged of anything too in the future
2) the script which handles price uploads should start rejecting any updates with significantly future timestamps

I would probably not mind prices one or two hours off, but certainly not more than a day, and then only if they are clamped on the server (to server's current now()).
 
As in "how is it possible that the downloaded file has future timestamps, when they are all from the past in the database" or "how did did future timestamps appear in the database" or "who uploaded from the future"?
 
So... we got a timetraveller using Mafia. Awesome, great to know. Also, apparently we now know what to invest in.

But while we're waiting for this future date to hit, can we modify the PHP to reject all future timestamps?

(Seriously, though, my guess is that someone's system clock is set to 36 days in the future... Unless it's the PHP itself that's setting the timestamps, which would make some sense regarding how all these future times were uploaded at once, but not answer the question of how they're from the future in the first place.)
 
If anyone feels like fixing up the code be my guest, just pm me and I'll toss it that way. I don't have the know-how to fix it atm and am rather busy on work related stuff and projects.
 
Others to look out for is "cream of pointy mushroom soup" and "spicy mushroom quesadilla". Current historical price is 900k and 76k respectively, current mall price is 1600 and 1750 respectively.

(found through strange suggestions by PriceAnalyser.ash)
 
Did you also remove anything "too new" from the database, or is that work for someone else?
(or does the script now disregard future prices even if they are server-side?)

There is over 1000 of them, so fixing them by hand every time somebody has problem with one of them is, IMAO, a waste of time.
 
I think Heeheehee said it should have automatically fixed it all but not sure.
 
I can confirm that piles of dusty animal bones, cream of pointy mushroom soup and spicy mushroom quesadilla (i.e. the ones I've been checking lately) now all show the correct values with historic_price().
 
Lets see ... highest timestamp is now apparently 1275940421, which is much better than 1278937605.
(now show be 1275952906)

So, corrected.
 
It removes anything already in the database that's newer than right now and also rejects all submitted mall prices that are from the future. So yeah, should've taken care of all the problems.
 
heeheehee, does this account for time zones? Assuming the server is in the US (average GMT -6), if someone in Europe submits a price (GMT +0) or someone in Asia (GMT + 9), will their prices be ignored?
 
Uhh... PHP's time() uses the time since 1970/01/01 00:00:00 GMT, doesn't it? I'm assuming that Mafia uses Java's implementation of the time functions, which should work in much the same way.

Edit: If you're interested in seeing the fix, I changed a few lines around 64:
PHP: 
   log_it("Updating newer prices...");
   $time = time();
   $count = 0;
   foreach ($newdata as $item => $inf) {
      if((int) $original[$item]['time']>$time) unset($original[$item]);
      if ((int) $inf['time'] > $original[$item]['time'] && ($inf['time']<$time)) {
         log_it($item.' updated from '.$original[$item]['price'].' ('.$original[$item]['time'].') to '.$inf['price'].' ('.$inf['time'].')' );
         $count++;
         if (!sim()) {
            $original[$item]['price'] = $inf['price'];
            $original[$item]['time'] = $inf['time'];
         }
      }
   }
 
Last edited:
For further reference:
Code: 
fewyn:~# date
Thu Jun 10 12:44:31 UTC 2010
fewyn:~#

The server is set to UTC
 
I don't think the problem would come from the PHP side -- the question is, when mafia creates the timestamps does it take timezone into account? In other words, are they all GMT timestamps or are they all local timezone timestamps?

A lot of apps are sloppy about timezones because they toss around datetime strings that don't include timezone. I just wanted to bring up the point that if time zones are capable of screwing this up, it's possible that this fix may be over-restrictive. Sorry, I don't really have time right now to do the legwork it would take to figure this out (my schedule is basically full from 9am to midnight every day until next Friday, whee).
 
The timestamps are supposed to be relative to GMT - of course, that assumes that the user has their computer set to the right time zone, not merely the right local time.
 
You must log in or register to reply here.
Back
Top