NOOOOooooo! Just delete the part in red.

Sorrow and Mattman86--

The Merge network (which includes Carbon and numerous other skins) is rolling out their new client next week. This is being hyped as a Mac-compatible client, but I read it to be replacing the current Windows client, too. It has apparently been rewritten in Java.

I suggest that we don't do any work on Carbon support until we see what the new client looks like on Tuesday. If their Java client runs on Linux, there will be any number of us working on Merge support in fpdb.

Has anyone been able to upload their Tourn Summaries with the latest snap shot?

I have mine set up properly but I've yet to upload a single thing.

It was broken by the recent work on transations.

It will be fixed in the next release.

Could someone clarify what "session" ... "S" is based on? Define the start, end or how it determines what a session is. I tried to test. Had 4 games open, same game, same level and all four were showing different stats as if each table was considering itself to be a session. It also seemed to "remember" if I came back to a same table, even if I closed FPDB and started it over. I'm confused...which is nothing new.

I assume that if I want the hud to show just that day's stats, I have to enter "1" and "T" for the hero in the config. That will show me one day's stats, based on GMT time which is 7 hrs later than Pacific PDT (I know, you hate daylight savings and it should be 8 hrs) So, my day has to run from 5pm to 5pm. It ignores the date stamp on the file HH that Stars names their file based on EDT, which ends at 9pm here, midnight in the east zone. Just trying to figure how FPDB figures a start and stop.

A weird thing... If I play after midnight locally, those records seem to not exist when I run a report. The next morning, there they are. Can't figure out when I cross over the midnight locally that play after that seems to hang out in limbo somewhere... thanks for any clarification on the time issues... and session issues...

Dog

Bump in case steffen missed this or anyone else can help.

hey dog,
i remember you from the pokerstars theme thread you were helping me out....anyways, i also have this problem but i think it appeared only after i downloaded the newest release. before i believe my sessions were from when i joined a table until i left it...even if i opened and closed FPDB. now, if i join a table i've played at any time before, its bringing up the stats from previous sessions. ie. i just join and sit down at 4 different tables, one of them may show me having played hundreds of hands even though i only played one. usually doesnt both me, but i like to know how i'm playing during a particular session and lately i've been messing around w/a LAG game and i'd like to see what my exact stats are.

Weird Bug

I think there might be an off-by-one bug with the calendar/date selector. To get the # of hands I expect* to see for August, instead of putting the start day as 8/01 and the end date as 8/31, I have to put the start date as 7/31 and the end date as 8/30.

* This expectation could be a logic error on my part; I'm basing it on:

This does however match up exactly with the # of hands reported on both graphs and player stats if I shift the start and end date earlier by one as stated above.

Just a thought on this whole time issue. We know you can't please everyone, so why not pick a middle ground and base the "day" on the same issue as PokerStars does, and that is Eastern Time, basically New York time. That way GMT will be 4 am for the new day, and here in California it would be 9pm.

Dog

I'm honestly not sure, there is some black magic in that code. Well... to me anyway - i'm not even 20% on the mechanics of how it is supposed to work.

Right now we are in the process of making sure that hands go into the database at the 'correct' time, but making sure they are presented to the user in the correct timezone is still not done. So even if the HUD session code was working 100%, it is still hard to tell due to factors outside its control.
The tourney stats import was broken in the most recent release due to the translations updating that was going on. That is now fixed.

If you are interested in tourneys:
http://****************/apps/wordpres...esults-graphs/

It only works with Stars Tourney summaries, imported via IMAP at the moment, but I hope that shows there is some progress. (and that i've started putting dev stuff on a blog, which i'm sure no-one is actually interested in.)

Sorrow

What timezone are you in Uncooper? Assuming the US - you are behind the rest of the world (and more importantly GMT), and neither the grapher or player stats view has been given the brains to correct that yet.

Sorrow.

That looks really good, pity I'm playing on FT at the moment

Keep up the excellent work.

Well, here's a new developer I've contacted to help with the "Black Magic code" you speak of...maybe she (??) can get the time issues cleared up. Just don't argue with whatever is proposed.



Dog

Every time I open a table (Everleaf), it loads my entire history for that table, regardless of when, even though all my stats are set for "Show This Session". I thought it was an Everleaf problem, since I"d not heard of anyone else having it. Perhaps it's just a lot more obvious since Everleaf is so small, so you're always playing at the exact same tables.

I thought the stats queries were not inclusive, I always add one to the day in both directions, to get the right stats. Everleaf however records the time in UTC, if I remember correctly.

I am EST/New York time, so that makes sense.

It doesn't seem like an inclusive/not inclusive issue, since I can get it to report the expected number of hands from date x to y by putting in (x-1) and (y-1).

can i browse individual handhistory files that i have played somewhere?

Okay, while we're on weird things, here's what's happening to me, running Windows Vista, got plenty of memory. While playing the harddrive kicked into overdrive again while FPDB was running. I opened the Task Manager to see what was running since I basically only had Stars and FPDB.

There was only one unusual thing. There were two lines showing "pythonw.exe" running. When I clicked to see the complete path of each, it showed the same path. It seems as though there were two copies running. One showed about 23 megs and other showed about 54 megs, seemed strange and awfully large to me. Any ideas?

I closed everything down, rebooted the cpu, opened FPDB again and now it is only showing one pythonw.exe file running with approx 29 megs... strange, but I've seen that pattern about three times now when it starts into the "I'm gonna lock your system up soon..." phase.

Dog

ps.. I just tried some more things. Guess it runs one copy when you open the FPDB program, then it opens a second copy of pythonw.exe when you click the auto import. Is that supposed to do that? That's a LOT of memory being used, more than my browser or any other program... memory hog??

Fpdb and the HUD are completely different programs. There are good reasons to make them run that way--for example, the HUD doesn't lag when you are importing a new HH. Fpdb starts the HUD program when you click the "Start Autoimport" button and stops it when you click it again.

I don't think that using 25M and 55M is a problem, considering that everybody has at least 512M these days and most people have at least 1000M. (Ah, the good ol' days when my PDP-8 was the best because it had 16k and all the others just had only 8k. I could do a lot in 16k in those days. My girlfriend was 22 and cute, too. But I digress.) Anyway, the amount of memory used is going to be sensitive to how many tables you have open, what db manager you use, and probably some other stuff. I checked just now and fpdb/HUD used less memory than either firefox or Full Tilt. That's on my Linux box, of course.

I see why. I am also using Firefox and usually play 4 tables at a time. That's enough with Omaha08.

Mine is STILL 22 and cute... but if my 59 year old wife finds out... ouch and I will be "out of memory" totally..

I'm still not giving up on the time issue being consistent. Just ran a report and it's all screwy. It would seem they could set everything to GMT, that I could handle... but... give us an option to enter the + or - hours we are different so the ring game stats and graphs all give us a true one-day's worth of stats.

Dog

I know you developers hate that I'm beating this time issue to death. But I spent a lot of time today analyzing it. Here are the facts, and the results, detailed. I requested "Hand History Audit" from Pokerstars so that I knew the figures were correct.

I quit playing tonight at approx 11 pm local PDT (6th) (Pacific Daylight - California) which converts to 2am the next day (7th) on EDT (N.Y) which is 6 am GMT (7th)

Pokerstars, based on Eastern time zone (GMT -4hrs) had the following data for me. On the 6th I won $19.35, on the 7th I won $3.45 (short session just to gather stats on the "next day". These match my manual scraps of paper records I kept today for this test.

When I ran both graphs and ring game stats for the 7th it showed no data available. What happened to the $3.45 I won which technically was won on the 7th on GMT time?? It shows nowhere.

For the 6th, both the graphs and ring stats match each other, but.. they show I won $7.61 on that date, when in actuality I won $19.35. This makes it hard to keep track of actual stats/wins other than writing down on post-it scraps or just taking my starting figure on Stars and go to the end of the night, and subtract the two... but that will include bonus deposits either made or earned. VPP points cashed in... you get the picture, a lot of record keeping. Not to bother getting into tournaments won/lost that I'm afraid to even import to FPDB.

No figures match. As Eros mentioned, and others, it's off by at least a day. But I don't see why my "7th" play doesn't exist. Is it because FPDB somehow records the time from my own CPU which is still saying it's the 6th, and the 7th isn't here yet, so it can't report winnings "in the future" which is already here, so to speak, because if FBDP is based on GMT it's 6am on the 7th.

I know, I know, I'm wasting your time and broadband width beating this dead horse, but it's frustrating to run a report to see how I'm doing and it means nothing... "it's a pretty graph and stats viewer" but pretty means nothing if it's not accurate.

Thanks.. now I'll get off my soapbox and go to bed since it's nearly midnight here in California... haha.. 3am in NY and 7am in Australia GMT... somewhere.

Dog

I hadn't really payed much attention to this previously, as it appeared to be 'mostly ok'

- The Stars import always adjusts from ET to GMT (whether or not the hand history is in ET or not). Different importers have different levels of support for timezone conversions.

- The calendar module (thing thing used in both Stats and Grapher for the date)
-- Takes the dates provided (t1=2010-09-04, t2=2010-09-05)
-- Converts using mktime, which adjusts for timezone - i'm +8 GMT(adj_t1 = 2010-09-03 16:00:00) for t1, and adds 23:59:59 to t2 (adj_t2=2010-09-05 15:59:59)
-- Add/Subtracts the amount of time in <general day_start="" from the config, set to 5 by default. Setting this value to 8 gives: adj_t1=2010-09-04 00:00:00 adj_t2=2010-09-05 23:59:59 - ie. back to start. (NOTE: I wasn't aware of this parameter until about 20 minutes ago)

These values are then used in the SQL query:
Which may or may not be compensating for current local time at the SQL level.

Places this can mess up:
- The importer might be adjusting the date for ET, when the date in the HH is actually in CET or some other value
- Config - day_start value
- GTK/python config. May not use local time setting - may use BIOS date, or something weirder. This will be dependent on the mktime() implementation for python.
- Database insert: Any of the databases might assume that a time value is either already GMT, or adjust it based on current time (being a flaky interpretation - see GTK/python line) and adjust it for us (using a different mechanism). Also - it might be different on each different database, and each platform the database is implemented on.

Each potential pitfall has multiple verification steps, and is very irritating to track down.

I recommend adjusting the date_start value around until it hits what you are looking for.

Sorrow.

Apart from the fact the tourney "bit" is broken, filtering hands by number of players works at the moment.

When tourney stats are back up and available I will check it again and report back.

Now that I totally am confused..somewhat Where do I find the "date_start value", what file or line in a file do I go to do some trial and error to see if I can get it to match up. Thanks..

Any developer feel free to give me that location and what I should actually add/subtract or change. I am running the source 906 version but on Vista. (so I can make changes like this)

Dog

.