FPHG available

[Tera_flop]

[ QUOTE ]
[ QUOTE ]
re: PT's importer

as I understand it the lightning bolt importer is sensiteve to file sizes, the party specific importer is not.

[/ QUOTE ]
Cool (I never knew that!), this could explain some of the problems I've had in the past then.

Juk [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]

The problem, I think, with the party importer is that it doesn't recognize .hhf files. So how do you get observed HH? Change them to text in freepgh and let them get stored in the same access file as your hh?

[bhudson]

juk, Tera,

I have a similar but with FPHG and Party CPU usage going up. At the same time Party's memory footprint goes up as well. I have to recycle both Party and FPHG eventually. It's not monster - things were same before Monster as well.

Wow, awr, that's news to me too. Thanks for the tip!

[Tera_flop]

[ QUOTE ]
juk, Tera,
At the same time Party's memory footprint goes up as well. I have to recycle both Party and FPHG eventually.

[/ QUOTE ]

bhudson, does recycle mean shut down the program, restart computer, or other? (I should never have chosen Tera_flop as a name b/c it gives the impression that I know something). Thanks!

BTW, I paid particular attention to cpu use during datamining w/ fphg, iwitness and PT running. Totally stable over 2 hours. My problems only occur when I add playing into the mix (PAHUD, MTH are on then, but are not the cpu hogs, it is PP and PT. I find this suprising... but I'm a biologist.)

[duck_butter]

Sorry, I am sure this has already been addressed, but a quick answer would be great:

Can you play and collect data on your tables normally, while also collecting on observed tables with FPHG?

Thanks

[jukofyork]

[ QUOTE ]
Sorry, I am sure this has already been addressed, but a quick answer would be great:

Can you play and collect data on your tables normally, while also collecting on observed tables with FPHG?

[/ QUOTE ]
Yes, it should be fine as PT will take care of any duplicates. You can also use the "-o" option to not output any hands you are involved in, as these get saved by the Party client anyway.

Nice avatar! [img]/images/graemlins/grin.gif[/img]

Juk [img]/images/graemlins/smile.gif[/img]

[duck_butter]

Thanks Juk, you're the man!

BTW, can you tell me how to use the "-o" option please.

THX

[jukofyork]

[ QUOTE ]
Thanks Juk, you're the man!

BTW, can you tell me how to use the "-o" option please.

THX

[/ QUOTE ]
When you extract the FPHG zipfile you'll see a file called "run.bat". Edit it to look like this:

@echo off
freephg.exe -o

Then make sure you run FPHG by running run.bat and not by running freephg.exe itself.

Juk [img]/images/graemlins/smile.gif[/img]

[Mogobu The Fool]

[ QUOTE ]
[ QUOTE ]
I open 4-6 tables, cpu is fine. Over the course of the next 90 minutes I open and closes many tables and am playing at 5 (that I opened early) while mining 5 others, and soon the cpu is getting pegged every few seconds and everthing slows way down.
Tera

[/ QUOTE ]
I cant really see an explanation, but even for me Party seems to be running badly lately (even for datamining). I used to be able to mine 3 clients without too many problems, but recently just 2 clients maxes my CPU.

Juk [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]

I don't think it's the hhf's. I know from my experience speed-testing FPHG and playing with different loading conditions that Party behaves differently when you're playing tables vs. observing tables.

Party has significant memory creep once you start playing; more segments come into use, forcing FPHG to scan more and more memory. Part of the reason is that it starts remembering played hand histories, but the creep is too big to be explained by that; there is probably some leaking, as well.

In addition, there is a lot of creep caused by opening and closing tables; GDI objects just keep stacking up. If you're like me, you probably open and close a lot of tables finding your chosen four or five to play. . . and that causes a lot of dud objects to hang out in memory.

If you open 12 tables and just observe, Party will run stable for quite a while. This is probably how they ran it to test for bugs and leaks.

If you play four tables while cycling through all the rest of the tables, your memory consumption will increase steadily and you will build up thousands of discarded GDI objects. You can see them easily in task manager; just open and close tables and the number continues to grow! They obviousl did not test it while playing and surfing tables.

[duck_butter]

Thanks again Juk, I just modified the run.bat.

On a different note, I must be doing something wrong here:

I closed out the freephg.exe and then cut and paste all of the hand history files (hhfs) it had recorded into my Hand History folder in my Party Gaming/Hand History directory.
However, when I try to force import with Poker tracker, it says it reads 8 files, but doesn't actually import any of the data.

Could it be because the hand history files Party autorecords while you're playing are txt docs and these are hhfs? You know what I am doing wrong here?

Thanks a bunch!

-dB

[jukofyork]

[ QUOTE ]
Thanks again Juk, I just modified the run.bat.

On a different note, I must be doing something wrong here:

I closed out the freephg.exe and then cut and paste all of the hand history files (hhfs) it had recorded into my Hand History folder in my Party Gaming/Hand History directory.
However, when I try to force import with Poker tracker, it says it reads 8 files, but doesn't actually import any of the data.

Could it be because the hand history files Party autorecords while you're playing are txt docs and these are hhfs? You know what I am doing wrong here?

Thanks a bunch!

-dB

[/ QUOTE ]
If you want to output the files as .txt, then use the option "-e txt" aswell.

To import the hands as .hhf files, you will need to use the lightning bolt importer in PT and setup PT to import observed hands.

Juk [img]/images/graemlins/smile.gif[/img]