I dont have anything that specifically triggers it yet, and i'm coming up short on ideas why it would.
Sadly - not yet. Its something we are looking at with the next db schema upgrade- expanding the HandsPlayer table to have most of the individual values for HudCache in it so we can rebuild the cache (or subsets of the cache) primarily so creating session data/stats becomes possible.

I'm doing this now, as it happens, as I've had to re-create my database. The improvement is quite significant.

The import speeds for INNODB are:

Total stored: 50 duplicates: 0 partial: 0 errors: 0 time: 3.12080478668
Total stored: 62 duplicates: 0 partial: 0 errors: 0 time: 3.21394014359
Total stored: 29 duplicates: 0 partial: 0 errors: 0 time: 1.57156395912
Total stored: 42 duplicates: 0 partial: 0 errors: 0 time: 2.02770709991
Total stored: 25 duplicates: 0 partial: 0 errors: 0 time: 1.35693788528
Total stored: 82 duplicates: 0 partial: 0 errors: 0 time: 4.49442195892

And for MyISAM, working on the same files:

Total stored: 50 duplicates: 0 partial: 0 errors: 0 time: 2.44788789749
Total stored: 62 duplicates: 0 partial: 0 errors: 0 time: 2.25488519669
Total stored: 29 duplicates: 0 partial: 0 errors: 0 time: 1.0653860569
Total stored: 42 duplicates: 0 partial: 0 errors: 0 time: 1.45321798325
Total stored: 25 duplicates: 0 partial: 0 errors: 0 time: 0.952408075333
Total stored: 82 duplicates: 0 partial: 0 errors: 0 time: 2.91316795349

I wasn't planning to do a comparison, but after deleting my old database I forgot to convert the new one to MyISAM. The second set of figures show what happened when I deleted the database once again, converted it to MyISAM, and then started re-importing.

P.S. Curiouser and curiouser! I'm about to send Steffen an error report, as this has just happened:

When the bulk importer has finished I'll see if I can find out what went wrong here (it's happened twice now).

Thanks for this comparison. That speed increase is not to be ignored, but I'm not sure how we will go about making myISAM an option or how soon we will get on it. This is a known bug.

I've tried this; it hasn't worked.

The statistic is not consistent. In my last session I noticed it going down, i.e. from 1/16 to 0/14 (or something like that). But it was wrong to begin with; after clearing out my database I imported a few thousand hands and my stat was (I think) the obviously wrong 0/15 -- which I found a bit insulting, to be honest; I may play a nitty game, but even I don't play that tight.

I'll have a look at the code, but any advice at this point would be gratefully received.

It turns out that fastStoreHudCache hasn't been switched off at all. How do you switch it off? I've added fastStoreHudCache="False" in the config file; I've changed line 29 of fpdb_save_to_db.py; but it's still using the fast version (I've added print statements to verify). What's going on?

Edit: I've worked this out for myself now (see below).

Thanks for this.... Hmm j'm not sure.

fpdb_simple has had a lot of recent cleanups - convert3B4B and the functions that call it might be a starting point. We've discovered at least 1 place where xrange couldn't be used in place of range.

If you can identify a specific hand or (or couple) where the values are changing incorrectly i'll track it down...

Just read your next post.

Eratosthenes was working on a config option and defaults for that and we had a couple of problems with "True" vs True and "False" vs False (ie string v literal) though i'd thought that was fixed now.

Are you using a recent pull from him?

Yes, I am. I should be up to date as of a few hours ago.

I've had another look and found out what was wrong with the code. Exactly as you said, a string-versus-literal confusion. In fpdb_save_to_db.py change this

fastStoreHudCache = False if import_options['fastStoreHudCache'] == 'False' else True

to this

fastStoreHudCache = False if import_options['fastStoreHudCache'] == False else True

I'll go through the process again, starting my DB from scratch, and see if the statistic now appears correct. Wish me luck!

I found and fixed a few more of these in fpdb_save. I also grepped through the dir and found one in Configuration.py in an option nobody uses. Those are fixed and corrected code is pushed to my repo.

ES--sorry to put you on the reimport treadmill. Let us know it you 3bet stat looks right after you have reimported.

It's no bother; done now. The 3-bet figures now look reasonable. The fault must be in the fast storage procedure somewhere.

I did a search and could not find anything.

Is there any way to get fpdb to work with UltimateBet (7 card stud specifically)?

Thanks!

We don't have hand history import support for UB--so no.

Is there decent 7 stud action on UB? What about stud8 and razz? Does UB have HORSE?

Anybody who pulled from my repo in the last week or so probably has hosed 3 bet stats. You should pull from my repo now (quick before I break something!), recreate your tables and reimport.

What part of the code have you changed? The upshot of my experimentation is that the 3-bet statistics are messed up by fpdb_simple.storeHudCache2; the last thing I did was to switch back to the slow version (fpdb_simple.storeHudCache) and the statistic made sense again (after re-importing). So have you specifically corrected the 3-bet storage in the fast version (it would have to have been within the last 24 hours, as I was up to date beforehand)?

P.S. I've answered my own question; you needn't bother to reply. I see you've made fastStoreHudCache = False by default. It's a pity there's something up with the fast version.

when i click on ftdp.py,it pop up a window and atuomatically close itself..

This is an unrelated matter.

In Hud.py, the new version of reposition_windows

doesn't work. There must be something wrong with the way the code is trying to iterate over the windows. I'd rather leave that one for an experienced Python programmer to sort out. The old version works, however:

Is there an error message in fpdb-error-log.txt?

If you can't even see the main window, this might be because you didn't first set up the database (as per the readme).

can't connect to database.
anyone knows how to specify it to link to postgresql instead of mysql?

Where in Manchester? Not a stalker or anything, just interested to know. I live in Salford.

A

You need to change the database element at the bottom of your HUD_config.xml file. For postgres it needs to look like this:
This assumes that you have created a db on your local machine and set up a user named "fpdb" with password "YourPassword".

Y, I ran in to this yesterday, too. I rolled out of bed with the intention of fixing this, but haven't started yet.

i just intalled the fpdbEnvInstaller0.2.exe and restart my pc and it is connecting to mysql. so i change the mysql to postgresql but it still dones't work.
can you tell me where and how to setup a database?i can't find it in readme.

how to setup mysql in the wiki

I'm completely lost, please help!

I've spent the last hour and a half reading through the first 30 some pages of this post. I am trying to install this program and nothing is working.

I already have postgres installed with HM and PT2 and PT3. When I ran the fpdb installer, it installed (I think) but never promted me for any information (ie the database and password info). Python seems to have installed for me as well as the numpy and matplot libraries. Am I missing something? When I try to run the fpdb.py file, it just opens up a command prompt and says something about error files being rerouted to another location, then closes and nothing happens.

Do I need to uninstall everything and reinstall? Do I need to set up something prior to installation in pgadmin so that it prompts me? If so, how do I do this?

Ugg...

Thanks for your replies

check your fpdb-error-log or HUD-error(in your fpdb dir) and see what are the error messages

Here is what I'm getting:

Traceback (most recent call last):
File "C:\Documents and Settings\Travis\Desktop\fpdb_0.10\pyfpdb\fpdb.py", line 464, in <module>
me = fpdb()
File "C:\Documents and Settings\Travis\Desktop\fpdb_0.10\pyfpdb\fpdb.py", line 377, in __init__
self.load_profile()
File "C:\Documents and Settings\Travis\Desktop\fpdb_0.10\pyfpdb\fpdb.py", line 275, in load_profile
self.settings['db-password'])
File "C:\Documents and Settings\Travis\Desktop\fpdb_0.10\pyfpdb\fpdb_db.p y", line 65, in connect
self.db=MySQLdb.connect(host = host, user = user, passwd = password, db = database)
File "C:\Python25\lib\site-packages\MySQLdb\__init__.py", line 74, in Connect
return Connection(*args, **kwargs)
File "C:\Python25\lib\site-packages\MySQLdb\connections.py", line 170, in __init__
super(Connection, self).__init__(*args, **kwargs2)
_mysql_exceptions.OperationalError: (1044, "Access denied for user ''@'localhost' to database 'fpdb'")