Great minds think alike, I guess. I am not a Python expert yet, so I was thinking of a quick and dirty way to show/hide windows without using those calls. Setting the Opacity is what I was thinking too. If I ever get a machine set up as a development environment, I'll chip in a bit. Having issues at the moment.

I have already tested this to some extent and found that the Stat windows do not cause this as often, but it does happen occasionally. I DID NOT, however, test it by hiding a few player Stats so I will try that tonight and report back.

I'll eventually get setup to actually just mod the code and tell you guys what works, but as of now, I am having a problem in that I am running x64. So, I have to get the 64-bit versions of the modules. Problem is that a few of them will require that I use the latest GTK. Not a problem for me, but I don't want to break compatibility with the current releases of FPDB.

COKE_MAN,

If you're using Windows, I can guarantee that if you use all 32-bit modules and 32-bit python, it works. I was not able to find all the modules needed to make fpdb work in x64 form, the last time I looked.

Just fyi, I have fpdb working in x64.

Ok, I'll install the 32-bit version of Python and see what happens. I have the 64-bit installed and that requires at least the 64-bit numpty and matplotlib modules. From there, it snowballed.

Chazz, Yes, FPDB works fine on x64. I am setting up a Python development environment and I want to maintain compatibility with the current devs.

Ran several of these tests last night. With the Mucked cards disabled and windows overlapping, there is still a flicker, but not as bad. What it does here is when the Stat windows redraw or update, the table they are attached to pops to the top for a split second, then goes back to its original spot in the stack. Just as a reminder, this is on PokerStars, Win7 x64. I also tested it in a Win7 x32 VM and the behavior was still there.

I'm a dev

This website has a bunch windows installers for the python dependencies including 64 bit numpy and matplotlib - http://www.lfd.uci.edu/~gohlke/pythonlibs/

Great I'll stick with what I've got working right now. Part of the reason I still use Windows is because I'm sick of spending all my time messing with my system, rather than getting work done

So you guys can be the x64 guinea pigs ..

I have recently download the software on my winodws 7 PC. The HUD and autoimporter are working well but I cannot use any of the other functionality. When I hit control P the player stats page come up. My FT(the only site I am using) screenname appears correctly. However when I click on the refresh bar there is no response. Can anyone help? I am playing HE exclusively on FT.

Right. That's where I am getting my x64 modules too. Great site. Problem is a lot of those require GTK 2.20 and the current FPDB is using an earlier version. Nothing irritates me more than when a member of my development team here jumps to a newer version of a library without telling us and breaks the rest of our compatibility. I don't want to be that guy on the project.

Plus, anything developed/compiled on the x64 will not run on the x32 when deployed. I guess we could just point out to the FPDB devs what lines were changed and they can implement those changes at their leisure. Shrug.

For now, I am thinking I may contain this in a x32 VM. My last tests were against this VM and it wasn't so bad. Plus it gives me one dedicated resource for poker and that makes managing it much easier.

I don't see why using a newer version of gtk would give you a problem. The only requirement I see is that Pygtk has to be version 2.0 or higher, which implies a gtk version of 2.0 or higher.
The version of gtk in the exe version doesn't matter to you if you are installing an environment for development. When I was making the exe version, I just used the most recent stable gtk, _or_ the same one I used in the previous build. This is arbitrary, as long as it works.

Numpy and Matplotlib are only used for graphing, so you don't really need them to do work on the hud. You will get a nagging message, but it should work ok.

You can get development questions answered faster if you come to the #fpdb channel on freenode.net.

EDIT:
numpy is also needed to calculate the variance in the ring player stats--but as long as you are just working with the HUD and doing autoimports, you are fine without numpy or matplotlib

BTW: I agree that setting up a dev env for python/gtk is painful. That's why there is an exe version for users.

Developed no, compiled yes. Right now only one person is handling the compiling and i'm happy to say he knows far more about it than I.

Mostly giving my agreement here, getting a _newer_version of any library should not cause problems. If it does, then it's definitely a reason to change/fix fpdb (or the library), and the sooner we find these the better
Sticking to old libs is pure hell in the long run anyways. (One exception to this is currently Python3, since at least pygtk has not made a py3-version yet we can't update to that)
As for the x64/x86 thing, the _code_ should be 100% compatible. I'm not sure about CPython bytecode (*.pyc), but in any case, this is only relevant when packaging. Also i'm certain at least some of the devs (me) use 64bit Python, and I'm pretty sure that some of the devs use 32bit Python, so basically don't worry about it. Only problem is the PITA of finding installers for all the libs in Windows (end-users with Windows: note that this does not affect you due to the .exe installer).

Which version of fpdb?

Ok, guys. Points taken. I just didn't want to start working on something, fix it, say "hey this uses the .MagicFixEveryThing function in GTK 2.20," and have someone say "we can't use that yet, bonehead."

I'll get it all set up and see if I can contribute anything useful.

If the GTK people ever fixed things, the world would be a better place (i keed, i keed)

Thx. I won't get into the Daylight Savings issue , just kidding.

Dog

V.20 or higher I believe. Downloaded within the last two weeks. Any help would be appreciated.

I am using fpdb full time now and it's great. Thanks for the effort.

I do have one issue, though. I have noticed that when I am playing sometimes the HUD just stops working (it freezes and the stats don't update). After I restart it, it works fine again.

But here's my question: If it freezes and I restart it after a number of hands were missed, will it automatically import those hands it missed?

I am using fpdb on Linux (Ubuntu Maverick) and using Full Tilt with Wine.

The HUD and fpdb are different programs, running separate processes. If only the HUD goes down, fpdb will continue to autoimport. If this happens, you could go to bulk import and just import today's files, just to be sure. Duplicate HHs will not be imorted. If you start fpdb from a command line, you will get a summary of hands imported, duplicates, and errors.

Can you give me more info on the freeze? Do you have any idea what was going on when it happened? Please let me know if it happens again and any insight about what was going on.

Gnome or KDE (or other)? FTP seems very unstable with Ubuntu/KDE for me. I only test on Ubuntu though.

Unfortunately I don't know what happens. It just randomly freezes. I will notice the HUD stats aren't updating and often the player name is different than the person sitting down (a result of the fact they have sat down since it froze). I have some Python programming experience, but I am not sure if I am advanced enough to debug something like this. I haven't looked at any of the code.

BTW, I am using fpdb v0.20.906 (the testing version) and used the .deb on the website to install it.

I'm using Gnome. And yeah, FTP is a bit unstable with Wine for me too. It will randomly crash (turn grey and freeze, then I have to do a kill from the command line). I think the FTP crashes have something to do with audio. Sometimes the sound will freeze and then a few minutes later I get the "the client has crashed" message. I am using OSSv4 for audio (as I hate ALSA). I don't know if that has anything to do with it or not. I can only hope some of the WINE development team are poker players and make it a priority to get FTP working.

Oh and BTW, have you guys thought about opening an Ubuntu PPA so that us Ubuntu users can stay up to date without having to manually check this thread or the WIKI?

And one more thing: can you tell me which stat abbreviation shows how often a villain folds to a cbet? Is it fold_f? If so, then that stat is always at 0 for every villain no matter how many hands I have on them.

Also the three_B stat is confusing to me as well. Some people in my database have a 3bet % that is the same as their PFR %. However, I know this can't be right because I play often with these people and they don't 3bet every time.

I use Arch Linux with xfce and am still using wine 1.1.32 (because it works so well). I also use OSS, but don't use pulse audio. I have only rare problems with Full Tilt--I don't remember the last freeze. You might want to keep an eye on the wine appdb page for full tilt. A lot of the guys there have problems with FTP on ubuntu.

There has not been any discussion of setting up a PPA for fpdb, AFAIK. Some of the devs use Ubuntu, so it is not out of the question--maybe they will chime in.

You can always get a list of the legal stats and their descriptions by running Stats.py from the command line. I notice that fold to 3bet data is available in the db, but there is no hud stat for it (+ some other useful stats). I will go ahead and start implementing some of those stats, starting with fold to 3bet.

three_b is the % of the 3 bet opportunities that the player actually 3bet.

It would be cool if that's done.

Ok, cool. What is the fold_f stat? I assume it means folds on the flop to a cbet. That is the stat I am most interested in right now. A "fold to cbet" stat. (not fold to 3bet, though that would be nice too).

Me, me, me! I know this one! I can help!

If I'm not wrong, there's no a "fold to cbet" stat,
but you have two options:
fold_f
or
ffreq_0
Not sure about the difference between them

Yeah, what you say about the three_B sounds weird to me too.
PFR has to be bigger to three_B cause you can ReRaise only
is there's a Raise before.

Sorry for my english, I hope that helps you.