FPHG available

[jukofyork]

[ QUOTE ]
Alright, here's a problem I'm having. I've read through pretty much this whole thread and did not see anyone else with a similar problem. The program is writing a file for each table I have open, as is expected. The problem is that it is only writing a fraction of the hands that occur at each table. For a table that's been open for the past 20 minutes, it has recorded three hands, and the timestamps are each 5-6 minutes apart. Each time my PT import runs (every 5 minutes) I only get 5-6 new hands. I have a brand new, fast computer so I don't think there is a problem with FPHG not getting the required processing power. Any ideas? Thanks in advance!

[/ QUOTE ]
I agree, nobody else seems to have had this problem before (or at least as severe as this).

Are you using the batch file or running the exe directly? (by using the run.bat file to run FPHG it puts it into low priority mode which could do this).

Here are a few things to try, I will list them in order:

(1) Edit run.bat to the following:

freephg.exe -d 0

(2) Edit run.bat to the following:

freephg.exe -p 2

(3) Edit run.bat to the following:

freephg.exe -a 1

Then use run.bat to run FPHG rather than running the executable directly. If you don't have CLI stuff installed for XP and can't run the batch file, then just make a shortcut and add the options into the "target" box.

If it turns out to be (1), then try using a larger delay like:

freephg.exe -d 100

and slowly increase this until the problem kicks in.

If it turns out to be (2), then this will just mean something else was eating the CPU time and you need to look into what is running on your system.

If it turns out to be (3), then it means the alignment of hands is different for your system. If this is the case then post here and I will tell you how to make a log you can send using the -prof option.

I hope one of these works. [img]/images/graemlins/smile.gif[/img]

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

EDIT: And sorry if I sounded mad in may last post as I am always happy to help, but I just had maybe 10-15 PMs and emails in the last day, all from people who couldn't be bothered reading the thread... [img]/images/graemlins/smile.gif[/img]

[challenger84]

Ok, I'll try those things and get back to you. Thanks again.

[awr000]

do you have a dual core or hyper threaded processor?

[jukofyork]

[ QUOTE ]
do you have a dual core or hyper threaded processor?

[/ QUOTE ]
Did this actually cause anybody any problems (I just remembered this sub-thread from way back).

If this is the case then did changing the affinity make any difference?

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

[challenger84]

Well, I rebooted my computer and let it run for a while and it seems to be running normally now. I'll let you know if I experience any more problems.

[omgwtf]

I have seen the same thing. Here's my best guess as to the cause. When you have MTT lobby windows open, Party sometimes just churns on the CPU, especially if you have multiple MTTs with large numbers of participants. Probably some poor coding in the searching/sorting/organizing on the MTT dialog. This eats the CPU and competes with FPHG.

The other problem is that the longer it runs, the more hand histories that need to be scanned, increasing the amount of CPU required by FPHG.

I often multitable MTTs and always keep the MTT lobby open. I noticed this problem before FPHG, but now FPHG is requiring its own chunk of CPU. I have a dual core Athlon 4800 w/2G RAM, and even this bogs down badly sometimes. For me, though, it isn't too big of a problem, because I mainly use it so that I can observe tables (how did he get all those chips when I wasn't looking???) while multitabling, not to import into PT.

If you are trying to generate HHs to import into PT, try closing all MTT lobbies.

[yellowbluebus]

I was wondering if anyone encountered the following situation with FPHG. I have two different databases, one for datamining purposes and the other one for my own play. I would like to be able to datamine and play at the same time. However, the way I have PT currently setup would import my own hands into the main database, and the observed ones into the datamining database. Now, FPHG picks up the hand histories for my own play as well. I don't want to end up with duplicate hand histories in both databases.

[yellowbluebus]

[ QUOTE ]
[ QUOTE ]
There shouldn't be a problem with this, as the .hhf are stored in just the same way as they always were in memory. I think PT should detect that their are duplicate hand #'s and ignore them? (I not sure on this though, maybe somebody else can clarify this).

[/ QUOTE ]As PT imports any hand, it checks to see if the hand# is already imported. Therefore you don't need to worry about double importing.
-Sam

[/ QUOTE ]

Is this still true for PT importing into 2 different databases?

[yellowbluebus]

OK, I just did a quick trial and found out that PT doesn't import hand histories that have already been processed even if it imports from two different directories into two different databases.

[fyodor]

[ QUOTE ]
I have seen the same thing. Here's my best guess as to the cause. When you have MTT lobby windows open, Party sometimes just churns on the CPU, especially if you have multiple MTTs with large numbers of participants. Probably some poor coding in the searching/sorting/organizing on the MTT dialog. This eats the CPU and competes with FPHG.

The other problem is that the longer it runs, the more hand histories that need to be scanned, increasing the amount of CPU required by FPHG.

I often multitable MTTs and always keep the MTT lobby open. I noticed this problem before FPHG, but now FPHG is requiring its own chunk of CPU. I have a dual core Athlon 4800 w/2G RAM, and even this bogs down badly sometimes. For me, though, it isn't too big of a problem, because I mainly use it so that I can observe tables (how did he get all those chips when I wasn't looking???) while multitabling, not to import into PT.

If you are trying to generate HHs to import into PT, try closing all MTT lobbies.

[/ QUOTE ]

nah... that wasn't it for me