When you run .7b, do you set it at p -2, or just leave it as "normal"?

It shouldn't do, as the code which looks for "New Data" and adds it to the end of the HH is separate from the realtime stuff. Also using "-p -1" might make it more likely to miss hands if the system is very overloaded ("-p 1" might be better, but can make your system/GUIs feel 'chuggy' sometimes).

It could be that v0.7b is faster for realtime mode though, as I know Mogobu optimized the realtime part most of all (this could explain why it's working better possibly).

Juk

I changed it from -p -2 (default) to -p -1 in the hope that it would bw less likely to miss hands, but still run at a lower priority than "normal" apps, because...

I was running this while "working" - doing PHP / postgres stuff on my work machines - chugging GUI can also mean chugging SSH connections to work machines, causing them to time out and lose my command line history - also causing me to reconnect, but that is less of an irritation

I think the realtime mode is much improved - I had serious slowdown issues using 0.06 in realtime mode after ~1000 hands or so, but not with this version

I only use realtime mode since I was under the impression normal mode quits reading the hand when it detects "wins", and I thought realtime just kept on scanning regardless, maybe that was not the case?

dave.

Cool, I just never got any real feedback about the 'b' versions, so couldn't be sure until now.

I know Mogobu did some profiling and found it worked significantly faster on his machine, but was just waiting for some feedback (we should have made sure we used the same defaults to make comparison easier).

If people have been using this without problems and it's confirmed to be running better, then I think I'll take down the old 'a' links.

No both have the ability to read the extra bit, just the non-realtime version would detect it separately and then add it to the end (my main fear with realtime model is it would pickup junk/corrupted HHs, but it seems ok in practice).

I think the reason it's running better is bc the code is more optimized meaning less chance it misses the end of the hand after the wins line (but not 100% sure).

Juk

I have a couple of ideas for increasing fphg's performance - particularly for realtime mode but I wanted to bounce them off you before I got too far with implementing my hacks. The inner loops are solid but we're not taking advantage of the fact that most active hands turn up in the same region time after time. I added some tables to track the 'active' regions and scan them on every loop - the inactive regions get scanned once every 5-50 loops depending on delay settings, with delay at zero, I'm scanning twice as many 'active' regions and still picking up new hands in new regions when they do occur.
The other thing I saw is that readprocessmemory is kinda slow - tracking regions means we don't have to do it every cycle, but virtualqueryex is an absolute dog. I haven't tried it yet but I think storing the MBI's, trying readprocessmemory and only doing the virtualquery when rpm fails will be much quicker. Combining these, we'll end up with another outer, outerloop of 1 - 2 seconds where all 'previous' regions are rpm'd and queried only if rpm fails, all regions are then scanned, but inside this loop we rpm and scan the 'active' regions - maybe 5 to 10 times and we have a much better chance of catching all the data.
I'm already tracking the regions but am not doing it in a 'nice' way and my C has been rusty for a decade. eg
unsigned int RegionStart[80];
Pls let me know if you think I'm off base or am about to hit a wall.
I just read my post preview and it seems the coffee has got to me, sorry if its completely unreadable. I hope I got the idea across though.


just added the following couple lines to prove that virtualqueryex doens't HAVE to be called immediately before readprocessmem - we can store the MBI's and MOST of the time the page boundaries won't move (they do move around when opening and closing tables but that happens in macro time)
void* NextAddress = SI.lpMinimumApplicationAddress;
NextAddress = (void*)((DWORD)MBI.BaseAddress + (DWORD)MBI.RegionSize );
MEMORY_BASIC_INFORMATION MBI2;
DWORD Ret2 = VirtualQueryEx(hProcess,NextAddress,&MBI2,size of(MEMORY_BASIC_INFORMATION));

Hey, just had a quick read through this and I think there is still alot of scope for optimizing FPHG.

The only things is that FPHG hand grabbing mechanism is going to be completely overhauled sometime over the next few weeks (likely within a month - I'm just about to move house, so can't really put the time in yet). Another 2+2er has already done all the groundwork and showed the new method works (and uses 0% CPU time with no missed hands).

It will mean all of the memory polling method will be gone, so it's prolly not worth putting in too much time fixing up the current FPHG code (you are welcome to if you want though, and just send me any code/patches and I'll post them as a beta).

I also think that FPHG needs a GUI, as when I first posted it I wasn't 100% sure how Party would take it (and assumed they would be less bothered by a simple looking CLI application). Well 8 months on and it seems prety much accepted byt Party and I think a GUI would now be a good idea to reduce the number of confused posting about how to add CLI args, etc.

Also, a FPHG FAQ is needed badly, as I seem to get 2/3 emails every few days saying basically "FPHG is saving the .hhf fine, but PT won't import them, can you help?". Ben has allready offered some space on hiw Wiki for this, but I just havn't had any time to get started on it...

Juk

I did have one idea for the core loop that I almost forgot, when processing a text frag we search all the way up the buffer for a terminator like 'wins', wouldn't it be quicker to branch as soon as we detect stars, and compare something like tables[i].lastchar to &buffer[tables[i].len] to see if the last char of buffer matches our stored lastchar value? if it does, we can work backward until we're confident its a match and not a random hit. This should save a few hundred compares per stars hit at a cost of storing a few chars per table.

edit: sorry, just realised the extra cost of matching the table name for every stars hit will very likely outweigh any gain

having quad aces rivered doesn't feel as bad as optimising obsolete code

does the new method have a realtime mode?

Hehe, sorry I should put a note on the main FPHG page warning that it's soon to be updated with a new method.

Yes, it should be 100% realtime mode (the reason for different modes in the old code was to try to reduce chance of corrupted HH appearing, but by skipping the first HH seen this seemed to negate that problem).

Juk

Thanks for this program!
I use Pokeroffice and find it a little time consuming to import the .hhf files one by one. Is there any script that automates this process?

Edit
An alternative might be to make one .hhf file for each level for example.

This program have worked well for me for some month, but today it doesnt work anymore. PT makes error message when I try to import observed hands.
Anyone know what the problem is?

http://www.pokertracker.com/forum/

Juk

Thing is that PT can import played hands, but not observed hands with FPHG.

I started the datamining like any other day this morning before going to the university, but when I came home it was all messed up for the first time ever, and there have been no updates in between.

Well, mb I should just give PT forums a shot.

If FPHG has saved the files to disk exactly as they are stored in Party's memory, then FPHG has done it's job. It is then up to PT to import these hands.

This is what has always been clearly written at the top of the FPHG page:

If FPHG is messing up and not saving the files properly (which can be verified by opening the text files and looking at them!), then I can help fix problems with that, but if PT is not importing the hands then I cannot; hence the link to the PT forums.

So far this same question has been asked, posted, PMed and emailed to me perhaps 500+ times so far (no joke).

Juk

Hi,

How can I/is there a way I can automatically set a schedule to shut down/turn off the FreePHG software?

The reason being is that I only have a certain time slot during weekdays when I can play online and while it is worthwhile, I believe, to continue to grab hands played by other players for an hour or so after I hit the sack, it does not seem to keep grabbing hands for the whole night and early morning.

Thanks.

JHH

Just downloaded this, love it but one questions. When I 1st tried it, it saved the HH files to the FPHG folder but then the 2nd time I tried it, it just saved the HH files right onto my desktop. Any idea why and what I should do so it doesn't happen again?

It saves to the folder where you run it from. You must have run it from your desktop 2nd time.

Juk

I did indeed. Thanks.

had the same problem.. where should i be running it from?

Can I use safemine instead of iWitness which has that annoying looping problem where it often will continue to search for tables and take my desktop hostage?

btw has anyone ever tried to use tweakui on the problem where iwitness continously steals focus searching for new tables??

Dizzle, this post answered all of my questions, ur the man.

Juk and others who helped- thank you for all the hard work, very much appreciated.

In case anyone else has this problem.

I just created a new PT database and I couldn't get it to import oberved hands. I have previously had this working since the the program was posted.

There was a message in the "Error Log" that said it was unable to open the file (.hhf). The message in the "Auto-Import" window said:

"The database you have choosen to import the observed hand histories into could not be found."

The "Observed Hands" option is greyed out and I know of no way to get around this.

I finaly got it working by putting the FPHG folder into the Hand History folder and using the -e txt option.

I would also be interested to know if anyone has a better solution.

Well it's obviously not an FPHG error,

"The database you have choosen to import the observed hand histories into could not be found."

DATABASE, thus something with your PT set-up, NOT anything to do with FPHG at all.

I'm sorry. I did not mean to imply that it was.

Yep, but it's no where near as advanced as iWitness (ie: have to use PP own filters, etc).

I'm pretty sure this will just cause major problems if tried, and may even make the problem above much worse.

Juk