[HUD] Free, open source poker tracking software: FPDB - (Version 0.40.5) - Nov 14, 2013
this page http://****************/apps/mediawik...e_Combinations shows the list of pre-requisite packages you will need.
I don't think you need mysql or postgres, because sql-lite is used now.
From memory, be careful with GTK+ and python - you may get conflicts/problems if the package is already installed and needed by other software on your system.
If you aren't familiar with setting up and troubleshooting these packages, I would recommend waiting for the next release of fpdb.
hmmm any idea when the next release is going to be?
I haven't read through the 200 pages, just a quick question: Does it still work and should a micro stakes player bother with this / will it benefit me?
Great work either way
Great work either way
My hud displays vpip,pfr, sb steal bb ,steal, steal. This info within itself has been very valuable. I play 25nl fr and playing with hud has been very helpful.
Before you do anything, make sure you understand how utilize the numbers. No point in having these stats if you don't know how to use them.
Hi, I'm currently using two versions of fpdb, 0.20-20100305-python-distribution and 0.12-20100213.exe. Both under Windows XP.
The first one I installed after I found out that the second one seriously miscalculated the totalProfit field in the database when confronted with all-in calls in pokerstars-files. And the more recent .exe distribution didn't work at all.
However when I install the first one, Python and all the requiered libraries it wouldn't work either. Found out that this was a problem with MathplotLib. Hence uninstalled that one. And thus now I use the first one for importing and hud and the second one for graphing and such.
So far for the situation sketch.
1) The 0.20-20100305-python one still doesn't import pokerstars hands correctly yet. The error is small though. It seems that it ignores the "posts small blind" part of lines saying something like "... posts Big Blind & posts Small Blind".
2) The 0.12-20100213-exe one has some problems with the session-viewer. And from my reading of the code of the 0.20-20100305-python one (I never wrote Python before) it's still wrong there. I'll try here to state the problems and the possible solution to it.
2.1) The last played session is not included in the candlestick-graph nor the table below it. solution: line 267 of GuiSessionViewer.py should be replaced with:
diffs.append(THRESHOLD + 1) # last hand of last session
# should be marked as an end of session hand to make
# certain the last session gets included by the next
# indexing statement
index = nonzero(diffs > THRESHOLD) # This array represents
# the indexes into 'times' for start/end times of sessions
2.2) In the table at the bottom the hands-collumn is of by 1. Solution: line 287 should be replaced with:
hds = index[0][i] - last_idx + 1 # Number of hands in session
2.3) Something is wrong with the conversion of the time to local-time. Sollution: I don't know.
2.4) The Hands/Hour doesn't display the hands/hour but (an approximation of) minutes in session. Sollution: replace line 291 with
minutesplayed = (times[index[0][i]] - times[last_idx])/60 + 1
# minutes played (approx)
# +1 to make certain it's different from 0 and hence assuming
# the last hand had a duration of 1 minute instead of 0 minutes.
# (I know it's a hack, but it solves possible issues 1 hand-sessions)
# This line should really read something like
# minutesplayed = (EndTimeOfHand(index[0][i]) - times[last_idx])/60
hph = hds*60/minutesplayed # Hands per hour
also nice would be to show both of the above in the table aswell as adding a winnings/hour-cullumn = won*60/minutesplayed
2.5) The winnings/losses of the last hand of every session are ignored. Solution: replace line 292 with:
won = sum(winnings[last_idx:index[0][i]+1])/100.0
3) The HUD has some issues too.
3.1) The hud frequently crashes. I think these crashes happen when there is a player at the table with special UTF8 chars in there name. If that's the case, it might be a good intermediate sullution to filter those symbols out of the name. It's better to loose some chars in the name then a HUD that crashes.
3.2) This one is really anoying and I only noticed it when I started playing multiple tables. Fair enough my system is not one of the most recent but still. Here goes. When the autoimporter sends a hand to the HUD with mucked hands, it in turn wants to make windows to display the known cards. However when it does this it starts messing with the Z-order of all the opened tables. My system doesn't handle all this redrawing very fast, but it would even be annoying if it was speedy, because when you seriously multitable you don't want tables that wait for your action to flash away. So Pokerstars.exe should be the only program that handles the Z-order of it's windows. If it was up to me, and if I would know how (Python is new to me, but gtk is mysterious to me) I would rewrite the HUD such that it delays it's updates for a table until it is the topmost in the Z-order. I would allready be happy if you could tell me how to temporarily dissable the showing of the cards (mucked, common, hero's). That way only player-HUD-windows for new tables and new players on existing tables (both less frequent) would trigger the Z-order-flashing.
Let me conclude by saying that I thank all developers of fpdb for writing this great tool. Yes it may contain bugs and have some issues here and there, but it is available and getting better. Also it's great to be able to pick this up and not having to develop my own.
The first one I installed after I found out that the second one seriously miscalculated the totalProfit field in the database when confronted with all-in calls in pokerstars-files. And the more recent .exe distribution didn't work at all.
However when I install the first one, Python and all the requiered libraries it wouldn't work either. Found out that this was a problem with MathplotLib. Hence uninstalled that one. And thus now I use the first one for importing and hud and the second one for graphing and such.
So far for the situation sketch.
1) The 0.20-20100305-python one still doesn't import pokerstars hands correctly yet. The error is small though. It seems that it ignores the "posts small blind" part of lines saying something like "... posts Big Blind & posts Small Blind".
2) The 0.12-20100213-exe one has some problems with the session-viewer. And from my reading of the code of the 0.20-20100305-python one (I never wrote Python before) it's still wrong there. I'll try here to state the problems and the possible solution to it.
2.1) The last played session is not included in the candlestick-graph nor the table below it. solution: line 267 of GuiSessionViewer.py should be replaced with:
diffs.append(THRESHOLD + 1) # last hand of last session
# should be marked as an end of session hand to make
# certain the last session gets included by the next
# indexing statement
index = nonzero(diffs > THRESHOLD) # This array represents
# the indexes into 'times' for start/end times of sessions
2.2) In the table at the bottom the hands-collumn is of by 1. Solution: line 287 should be replaced with:
hds = index[0][i] - last_idx + 1 # Number of hands in session
2.3) Something is wrong with the conversion of the time to local-time. Sollution: I don't know.
2.4) The Hands/Hour doesn't display the hands/hour but (an approximation of) minutes in session. Sollution: replace line 291 with
minutesplayed = (times[index[0][i]] - times[last_idx])/60 + 1
# minutes played (approx)
# +1 to make certain it's different from 0 and hence assuming
# the last hand had a duration of 1 minute instead of 0 minutes.
# (I know it's a hack, but it solves possible issues 1 hand-sessions)
# This line should really read something like
# minutesplayed = (EndTimeOfHand(index[0][i]) - times[last_idx])/60
hph = hds*60/minutesplayed # Hands per hour
also nice would be to show both of the above in the table aswell as adding a winnings/hour-cullumn = won*60/minutesplayed
2.5) The winnings/losses of the last hand of every session are ignored. Solution: replace line 292 with:
won = sum(winnings[last_idx:index[0][i]+1])/100.0
3) The HUD has some issues too.
3.1) The hud frequently crashes. I think these crashes happen when there is a player at the table with special UTF8 chars in there name. If that's the case, it might be a good intermediate sullution to filter those symbols out of the name. It's better to loose some chars in the name then a HUD that crashes.
3.2) This one is really anoying and I only noticed it when I started playing multiple tables. Fair enough my system is not one of the most recent but still. Here goes. When the autoimporter sends a hand to the HUD with mucked hands, it in turn wants to make windows to display the known cards. However when it does this it starts messing with the Z-order of all the opened tables. My system doesn't handle all this redrawing very fast, but it would even be annoying if it was speedy, because when you seriously multitable you don't want tables that wait for your action to flash away. So Pokerstars.exe should be the only program that handles the Z-order of it's windows. If it was up to me, and if I would know how (Python is new to me, but gtk is mysterious to me) I would rewrite the HUD such that it delays it's updates for a table until it is the topmost in the Z-order. I would allready be happy if you could tell me how to temporarily dissable the showing of the cards (mucked, common, hero's). That way only player-HUD-windows for new tables and new players on existing tables (both less frequent) would trigger the Z-order-flashing.
Let me conclude by saying that I thank all developers of fpdb for writing this great tool. Yes it may contain bugs and have some issues here and there, but it is available and getting better. Also it's great to be able to pick this up and not having to develop my own.
2) The 0.12-20100213-exe one has some problems with the session-viewer. And from my reading of the code of the 0.20-20100305-python one (I never wrote Python before) it's still wrong there. I'll try here to state the problems and the possible solution to it.
2.1) The last played session is not included in the candlestick-graph nor the table below it. solution: line 267 of GuiSessionViewer.py should be replaced with:
diffs.append(THRESHOLD + 1) # last hand of last session
# should be marked as an end of session hand to make
# certain the last session gets included by the next
# indexing statement
index = nonzero(diffs > THRESHOLD) # This array represents
# the indexes into 'times' for start/end times of sessions
2.2) In the table at the bottom the hands-collumn is of by 1. Solution: line 287 should be replaced with:
hds = index[0][i] - last_idx + 1 # Number of hands in session
2.3) Something is wrong with the conversion of the time to local-time. Sollution: I don't know.
2.4) The Hands/Hour doesn't display the hands/hour but (an approximation of) minutes in session. Sollution: replace line 291 with
minutesplayed = (times[index[0][i]] - times[last_idx])/60 + 1
# minutes played (approx)
# +1 to make certain it's different from 0 and hence assuming
# the last hand had a duration of 1 minute instead of 0 minutes.
# (I know it's a hack, but it solves possible issues 1 hand-sessions)
# This line should really read something like
# minutesplayed = (EndTimeOfHand(index[0][i]) - times[last_idx])/60
hph = hds*60/minutesplayed # Hands per hour
also nice would be to show both of the above in the table aswell as adding a winnings/hour-cullumn = won*60/minutesplayed
2.5) The winnings/losses of the last hand of every session are ignored. Solution: replace line 292 with:
won = sum(winnings[last_idx:index[0][i]+1])/100.0
2.1) The last played session is not included in the candlestick-graph nor the table below it. solution: line 267 of GuiSessionViewer.py should be replaced with:
diffs.append(THRESHOLD + 1) # last hand of last session
# should be marked as an end of session hand to make
# certain the last session gets included by the next
# indexing statement
index = nonzero(diffs > THRESHOLD) # This array represents
# the indexes into 'times' for start/end times of sessions
2.2) In the table at the bottom the hands-collumn is of by 1. Solution: line 287 should be replaced with:
hds = index[0][i] - last_idx + 1 # Number of hands in session
2.3) Something is wrong with the conversion of the time to local-time. Sollution: I don't know.
2.4) The Hands/Hour doesn't display the hands/hour but (an approximation of) minutes in session. Sollution: replace line 291 with
minutesplayed = (times[index[0][i]] - times[last_idx])/60 + 1
# minutes played (approx)
# +1 to make certain it's different from 0 and hence assuming
# the last hand had a duration of 1 minute instead of 0 minutes.
# (I know it's a hack, but it solves possible issues 1 hand-sessions)
# This line should really read something like
# minutesplayed = (EndTimeOfHand(index[0][i]) - times[last_idx])/60
hph = hds*60/minutesplayed # Hands per hour
also nice would be to show both of the above in the table aswell as adding a winnings/hour-cullumn = won*60/minutesplayed
2.5) The winnings/losses of the last hand of every session are ignored. Solution: replace line 292 with:
won = sum(winnings[last_idx:index[0][i]+1])/100.0
I'll take a look at the code you have up there in the next couple of days - thanks for spending some time on it.
3) The HUD has some issues too.
3.1) The hud frequently crashes. I think these crashes happen when there is a player at the table with special UTF8 chars in there name. If that's the case, it might be a good intermediate sullution to filter those symbols out of the name. It's better to loose some chars in the name then a HUD that crashes.
3.1) The hud frequently crashes. I think these crashes happen when there is a player at the table with special UTF8 chars in there name. If that's the case, it might be a good intermediate sullution to filter those symbols out of the name. It's better to loose some chars in the name then a HUD that crashes.
There has been some work on making utf8 parse and display correctly.
What are your symptoms for a hud crash? It is more likely a parser crash, or sqlite concurrency issues.
3.2) ... it does this it starts messing with the Z-order of all the opened tables. ... So Pokerstars.exe should be the only program that handles the Z-order of it's windows ... rewrite the HUD such that it delays it's updates for a table until it is the topmost in the Z-order.
Delaying the display would require monitoring focus, which i don't think we want to do.
So whenever a hud window is attached you are receiving a focus switch. The HUD isn't my area of expertise unfortunately
I play tiled, but i don't believe this an issue under linux though. Eleatic Stranger had 24 tables running in 2 stacked piles without seeing this issue (E.S. Are you still able to do this?)
Sorrow
Any word on cbet or an update of fpdb?
gimick did some work on cbet, and I applied his patch to my dev tree. I have an email on the mailing list I need to review as well.
Release date... i'm not so sure. Its been real soon now for quite a while.
Sorrow
Release date... i'm not so sure. Its been real soon now for quite a while.
Sorrow
Hi all
Ive downloaded the current version and tried to install under XP. Installations stops pretty early and I get a standard windows error message. Since I am not an expert in this computer stuff at all I wanted to ask if anybody in here has an idea what to do.
Thanks a lot
Ive downloaded the current version and tried to install under XP. Installations stops pretty early and I get a standard windows error message. Since I am not an expert in this computer stuff at all I wanted to ask if anybody in here has an idea what to do.
Thanks a lot
Can i get this patch?
Sorrow, first and foremost, ty for the quick reply.
Ok I'll look into getting git to work and downloading the dev tree.
If and when I get the dev tree working It'll probably still be without mathplotlib, so I won't be able to test the code out myself.
Unless you can tell me the versions of the requierement list used in the 0.12-20100213.exe, so I can try installing those to possibly get mathplotlib working. According to what I read on the internet it has something to do with Python/Mathplotlib/gtk that created the problem (loading some time-funtion from some dll which doesn't contain that function).
Hmm, I'll try to make a more spicific diagnosis next time it starts happening. But if I recall correctly, the crash repeats itself after I stop and then re-start the autoimporter multiple times (so this seems to rule out the concurrency issues). The HUD-main window displays (meaning it has been sent a hand by the autoimporter, meaning the import didn't fail (could have entered bad data in the db though), then it creates it's player-windows (I think), and then it crashes before those windows get correctly sized/formatted/filled in. So that's why I think it has something to do with the info it needs to display. Since numbers, dots and percentage-symbols don't give any problems in and off itself, what remains are the names themselves, or some problem with the data from the db. Also, restarting fpdb doesn't solve the problem with that table in question. Closing the problematic table does. And the problem tables allways have some person with exotic UTF8 chars in them like "ae" (atached to each other). Anyway as I said, I'll look into it further.
One question though in which modules and where is the UTF8 parsing being done and used? I might take a look at it myself.
[QUOTE=sorrow;18325499]The mucked card display isn't supposed to reorder windows at all, in the same way that the stats window update doesn't bring windows to the front. The intent is for either the window manager or the poker client to deal with focus, all we do is attach the hud windows as children and let the WM do the job of redrawing.
[\QUOTE]
To expand on this issue let me add, that not only the "mucked"-windows display this behavior. It also happens during creation (not the updating) of the "players"-windows etc. So what this suggests to me is that it is the creating (or attaching them as you call it) of these windows that results in this phenomenon. So the following might be a sollution to this problem:
Create all windows at the same time, keeping the visible-parameter (or whatever it is called for gtk) set to false until actually needed. Or alternatively create them empty with a completely transparent background until needed. I think this last one is most likely to work, since I don't get the Z-order-issue with every update of the player-windows. The first one, if it works, would be easier to implement I guess.
[QUOTE=sorrow;18325499]Delaying the display would require monitoring focus, which i don't think we want to do.
[\QUOTE]
Fair enough. However an active HUD would create some nice possibilities. But it's probably better to hold off on this until fpdb as a hole becomes more mature.
I'll take a look at this.
[QUOTE=sorrow;18325499]So whenever a hud window is attached you are receiving a focus switch. The HUD isn't my area of expertise unfortunately
[\QUOTE]
Multiple focus/Z-order-switches. Often interleaved with focus-switches initiated by the Pokerstars-software. It sometimes looks like the windows will keep dancing around in the Z-order.
Most probably Eleatic Stranger has a system that is way better up-to-date then my aged system
Until next time
Socratic
PS.: Does someone have any idea why some of my quote/un-quote tags don't get recognized?
Ok I'll look into getting git to work and downloading the dev tree.
Session viewer is definitely broken. I never actually got it to the point of fully working before moving onto something else, there were at least 4 or 5 'off by one' errors. My hope was someone would pick it up - or i'd get back to it.
I'll take a look at the code you have up there in the next couple of days - thanks for spending some time on it.
I'll take a look at the code you have up there in the next couple of days - thanks for spending some time on it.
Unless you can tell me the versions of the requierement list used in the 0.12-20100213.exe, so I can try installing those to possibly get mathplotlib working. According to what I read on the internet it has something to do with Python/Mathplotlib/gtk that created the problem (loading some time-funtion from some dll which doesn't contain that function).
One question though in which modules and where is the UTF8 parsing being done and used? I might take a look at it myself.
[QUOTE=sorrow;18325499]The mucked card display isn't supposed to reorder windows at all, in the same way that the stats window update doesn't bring windows to the front. The intent is for either the window manager or the poker client to deal with focus, all we do is attach the hud windows as children and let the WM do the job of redrawing.
[\QUOTE]
To expand on this issue let me add, that not only the "mucked"-windows display this behavior. It also happens during creation (not the updating) of the "players"-windows etc. So what this suggests to me is that it is the creating (or attaching them as you call it) of these windows that results in this phenomenon. So the following might be a sollution to this problem:
Create all windows at the same time, keeping the visible-parameter (or whatever it is called for gtk) set to false until actually needed. Or alternatively create them empty with a completely transparent background until needed. I think this last one is most likely to work, since I don't get the Z-order-issue with every update of the player-windows. The first one, if it works, would be easier to implement I guess.
[QUOTE=sorrow;18325499]Delaying the display would require monitoring focus, which i don't think we want to do.
[\QUOTE]
Fair enough. However an active HUD would create some nice possibilities. But it's probably better to hold off on this until fpdb as a hole becomes more mature.
Disable mucked: http://****************/apps/mediawik..._displaying.3F
[QUOTE=sorrow;18325499]So whenever a hud window is attached you are receiving a focus switch. The HUD isn't my area of expertise unfortunately
[\QUOTE]
Multiple focus/Z-order-switches. Often interleaved with focus-switches initiated by the Pokerstars-software. It sometimes looks like the windows will keep dancing around in the Z-order.
Until next time
Socratic
PS.: Does someone have any idea why some of my quote/un-quote tags don't get recognized?
I checked this against what I believe to be the current git-tree (new at git) and can say this problem with importing pokerstars hands still remains.
Socratic
Socratic
I used to play on 20-odd tables in the old days of Fpdb before the parsing code was re-written; this may have affected results. (It was just one stack of tables, not two; perfectly manageable if you can make instant decisions.) Most of the run-time seemed to be consumed by the Pokerstars client, strangely enough, considering that it doesn't have much work to do (but perhaps this is due to WINE & Linux).
Linux users' tip: Fpdb does not like certain window managers. Don't use Metacity (with GNOME); try Xfce, or some other similarly lightweight manager.
PS.: Does someone have any idea why some of my quote/un-quote tags don't get recognized?
Thanks for the patch. I'll try it.
Some of them didn't get formatted as quotes and just show the tags except that the starting tags show "quote" instead of "QUOTE". Edit: I found out why, myself. I used "\" instead of "/" in the closing tag.
This part of patching is the most questionable, because I don't really "know" Python that well. It can easely be understood what is meant. But it can just as easely be the wrong syntax to do what I'm trying to do. And since I'm unable to get mathplotlib working with the python-distribution I can't test it myself.
However if you test this and the other patches to the session viewer, please let us know. And maybe sorrow can put it in the dev-tree if they resolve the issues at hand.
Socratic
But it can just as easely be the wrong syntax to do what I'm trying to do. And since I'm unable to get mathplotlib working with the python-distribution I can't test it myself.
File "/home/matthew/ephemera/fpdb/pyfpdb/GuiSessionViewer.py", line 267, in generateDatasets
diffs.append(THRESHOLD + 1)
AttributeError: 'numpy.ndarray' object has no attribute 'append'
Can someone solve this? I don't understand the Numpy API, and the answer has not been forthcoming from Google.
It doesn't work, unfortunately, and my very limited knowledge of Python has given out. From the error log:
File "/home/matthew/ephemera/fpdb/pyfpdb/GuiSessionViewer.py", line 267, in generateDatasets
diffs.append(THRESHOLD + 1)
AttributeError: 'numpy.ndarray' object has no attribute 'append'
Can someone solve this? I don't understand the Numpy API, and the answer has not been forthcoming from Google.
File "/home/matthew/ephemera/fpdb/pyfpdb/GuiSessionViewer.py", line 267, in generateDatasets
diffs.append(THRESHOLD + 1)
AttributeError: 'numpy.ndarray' object has no attribute 'append'
Can someone solve this? I don't understand the Numpy API, and the answer has not been forthcoming from Google.
- replace line 36 with:
Code:
from numpy import diff, nonzero, sum, cumsum, max, min, append
Code:
diffs2 = append(diffs,THRESHOLD + 1) index = nonzero(diffs2 > THRESHOLD)
I installed the git-tree on one of my linux boxes. Edited GuiSessionViewer.py as per my own updated instructions, imported a couple thousand hands from my windows box and gave it a test-run.
Result, all hands got included (I.e. sum of Hds equals total number of hands)
Hands/hour look correct.
Winnings didn't crash, but I haven't investigated if it is correct now. However I think it's safe to assume it is.
to Sorrow: if you allow me, I'll be happy to commit those changes to the git ( after I find out how to do that offcourse)
Socratic
Result, all hands got included (I.e. sum of Hds equals total number of hands)
Hands/hour look correct.
Winnings didn't crash, but I haven't investigated if it is correct now. However I think it's safe to assume it is.
to Sorrow: if you allow me, I'll be happy to commit those changes to the git ( after I find out how to do that offcourse)
Socratic
If I may venture away from all the python "chatter" which most of us don't understand, I still can't get the latest version to work.
Is anyone who is using Windows (I'm using Vista) got the latest 0307 exe installer to work properly?
When I install it, and I did keep it in a separate directory from a previous FPDB (0122 version), first it tells me I'm running the wrong db version and I must recreate. After I recreate, which btw now makes my one working copy of fpdb no longer work.. sigh.. I attempt to do a bulk import. If I try and import more than one hh at a time, it goes into the stupid loop where the blue box/cursor just keeps banging it's head from left to right and doesn't import.
If I go back to the 0122 version, recreate again and do a bulk import, it works fine with exactly the same hh's.
Now, while I'm sure it is important that things like "cb3" stats, and other stats be tweaked, or colors be changed, font's changed etc. I think it's a bit more important that we have a basically working current version. Anyone having success on Windows? I KNOW in my heart that the bulk of those using this program are running some form of Windows. Programmers might love linux and various other operating systems, but a lot of us are stuck in the mud and the project seems to have gone off track and forgotten about the basic issues, IMHO.
I love what the program has developed to this point, and what all the contributors have done, but it "seems" to have gotten lost lately. I have no problem with people having more important issues. They ARE donating their time. But I fear I must move on, or resolve myself to using an older version that at least works fairly well and just live with the stats being not totally accurate.
Thanks and good luck in the future. I'll check back in a few months and see if there's been some forward moment and try again, as I really do like the concept.
Dog
Is anyone who is using Windows (I'm using Vista) got the latest 0307 exe installer to work properly?
When I install it, and I did keep it in a separate directory from a previous FPDB (0122 version), first it tells me I'm running the wrong db version and I must recreate. After I recreate, which btw now makes my one working copy of fpdb no longer work.. sigh.. I attempt to do a bulk import. If I try and import more than one hh at a time, it goes into the stupid loop where the blue box/cursor just keeps banging it's head from left to right and doesn't import.
If I go back to the 0122 version, recreate again and do a bulk import, it works fine with exactly the same hh's.
Now, while I'm sure it is important that things like "cb3" stats, and other stats be tweaked, or colors be changed, font's changed etc. I think it's a bit more important that we have a basically working current version. Anyone having success on Windows? I KNOW in my heart that the bulk of those using this program are running some form of Windows. Programmers might love linux and various other operating systems, but a lot of us are stuck in the mud and the project seems to have gone off track and forgotten about the basic issues, IMHO.
I love what the program has developed to this point, and what all the contributors have done, but it "seems" to have gotten lost lately. I have no problem with people having more important issues. They ARE donating their time. But I fear I must move on, or resolve myself to using an older version that at least works fairly well and just live with the stats being not totally accurate.
Thanks and good luck in the future. I'll check back in a few months and see if there's been some forward moment and try again, as I really do like the concept.
Dog
If I may venture away from all the python "chatter" which most of us don't understand, I still can't get the latest version to work.
Is anyone who is using Windows (I'm using Vista) got the latest 0307 exe installer to work properly?
When I install it, and I did keep it in a separate directory from a previous FPDB (0122 version), first it tells me I'm running the wrong db version and I must recreate. After I recreate, which btw now makes my one working copy of fpdb no longer work.. sigh.. I attempt to do a bulk import. If I try and import more than one hh at a time, it goes into the stupid loop where the blue box/cursor just keeps banging it's head from left to right and doesn't import.
If I go back to the 0122 version, recreate again and do a bulk import, it works fine with exactly the same hh's.
Now, while I'm sure it is important that things like "cb3" stats, and other stats be tweaked, or colors be changed, font's changed etc. I think it's a bit more important that we have a basically working current version. Anyone having success on Windows? I KNOW in my heart that the bulk of those using this program are running some form of Windows. Programmers might love linux and various other operating systems, but a lot of us are stuck in the mud and the project seems to have gone off track and forgotten about the basic issues, IMHO.
I love what the program has developed to this point, and what all the contributors have done, but it "seems" to have gotten lost lately. I have no problem with people having more important issues. They ARE donating their time. But I fear I must move on, or resolve myself to using an older version that at least works fairly well and just live with the stats being not totally accurate.
Thanks and good luck in the future. I'll check back in a few months and see if there's been some forward moment and try again, as I really do like the concept.
Dog
Is anyone who is using Windows (I'm using Vista) got the latest 0307 exe installer to work properly?
When I install it, and I did keep it in a separate directory from a previous FPDB (0122 version), first it tells me I'm running the wrong db version and I must recreate. After I recreate, which btw now makes my one working copy of fpdb no longer work.. sigh.. I attempt to do a bulk import. If I try and import more than one hh at a time, it goes into the stupid loop where the blue box/cursor just keeps banging it's head from left to right and doesn't import.
If I go back to the 0122 version, recreate again and do a bulk import, it works fine with exactly the same hh's.
Now, while I'm sure it is important that things like "cb3" stats, and other stats be tweaked, or colors be changed, font's changed etc. I think it's a bit more important that we have a basically working current version. Anyone having success on Windows? I KNOW in my heart that the bulk of those using this program are running some form of Windows. Programmers might love linux and various other operating systems, but a lot of us are stuck in the mud and the project seems to have gone off track and forgotten about the basic issues, IMHO.
I love what the program has developed to this point, and what all the contributors have done, but it "seems" to have gotten lost lately. I have no problem with people having more important issues. They ARE donating their time. But I fear I must move on, or resolve myself to using an older version that at least works fairly well and just live with the stats being not totally accurate.
Thanks and good luck in the future. I'll check back in a few months and see if there's been some forward moment and try again, as I really do like the concept.
Dog
Additionally, and I know this is too late, here is how you can avoid breaking your old/working copy when you go to try a new version that needs to create/recreate tables:
1- Back up your database. I don't know much about mysql on windows but most mysql installs I've encountered also bundle a program called mysqldump. I navigate to my working pyfpdb directory and use:
mysqldump -u [username] -p -Q --opt fpdb > fpdb-042110.sql
Put your mysql username after the -u, put the current date in the filename at the end (where I have 042110), and enter your mysql password when prompted.
2- Create a new empty database. If your old database is called fpdb, as in the above example, maybe make one called fpdb2. You can grant privileges to the same mysql user/pass combo you used for your original db.
Now you can edit your HUD_config.xml in the new version of fpdb, using the new, emtpy database. If it fails or you have issues, you can just go back to the old copy, who's HUD_config.xml references the old mysql database, which hasn't been touched.
I haven't had to do a bulk import so far, so I'll transfer a bunch of files onto this system and try out the bulk importer and see if I can get the same problem.
I don't have a vista system anymore, but hopefully Win7 is close enough.
I went all over the SourceForge and can't find them. Got a link? If you'd rather PM it to me, that will work. I assume I just pick up all the most recent files and dump them in the 0307 directory I created and it will work PERFECT!!
One thing I might be doing that is wrong and someone can jump in and tell me. I have not been "editing" the new config file. I just copied my previous hud_config.xml file into the pyfpdb directory. I did review it and it all seems basically the same. Naturally, my table setups are different, but the real issue has been the bulk import issue. Do I just need the fpdp.exe file?
Thanks
Dog
One thing I might be doing that is wrong and someone can jump in and tell me. I have not been "editing" the new config file. I just copied my previous hud_config.xml file into the pyfpdb directory. I did review it and it all seems basically the same. Naturally, my table setups are different, but the real issue has been the bulk import issue. Do I just need the fpdp.exe file?
Thanks
Dog
I went all over the SourceForge and can't find them. Got a link? If you'd rather PM it to me, that will work. I assume I just pick up all the most recent files and dump them in the 0307 directory I created and it will work PERFECT!!
One thing I might be doing that is wrong and someone can jump in and tell me. I have not been "editing" the new config file. I just copied my previous hud_config.xml file into the pyfpdb directory. I did review it and it all seems basically the same. Naturally, my table setups are different, but the real issue has been the bulk import issue. Do I just need the fpdp.exe file?
Thanks
Dog
One thing I might be doing that is wrong and someone can jump in and tell me. I have not been "editing" the new config file. I just copied my previous hud_config.xml file into the pyfpdb directory. I did review it and it all seems basically the same. Naturally, my table setups are different, but the real issue has been the bulk import issue. Do I just need the fpdp.exe file?
Thanks
Dog
Unfortunately I can't help here brot, i may be able to diagnose if I had a machine with the error - but remotely that will be hard.
Sorrow.
Dog
With the .exe version there is now patch, but it should exist the next time we release.
From your later comments you say that the session viewer works without the graph - i'm impressed. I figured that would fail pretty spectacularly.
There is a wiki page:
http://****************/apps/mediawik...e_Combinations
Listing the known working package combinations. ekdikeo had a functional python 2.6+matplotlib functioning aswell but that doesn't appear to be listed.
That code has def had some work since the last release, there are some python bugs that we are having to work around. ie. Converting a utf8 string to utf8 seems to crash :/
Charset.py in the dev tree.
The usual problem is that it gets inserted as xxxaexx and comes out of the db (which we try to match xxxaexx) as xxxaaeexx - its usually a 2 byte character converting to a 1 byte representation, and not being translated back again correctly.
To expand on this issue let me add, that not only the "mucked"-windows display this behavior. It also happens during creation (not the updating) of the "players"-windows etc. So what this suggests to me is that it is the creating (or attaching them as you call it) of these windows that results in this phenomenon. So the following might be a sollution to this problem:
Create all windows at the same time, keeping the visible-parameter (or whatever it is called for gtk) set to false until actually needed. Or alternatively create them empty with a completely transparent background until needed. I think this last one is most likely to work, since I don't get the Z-order-issue with every update of the player-windows. The first one, if it works, would be easier to implement I guess.
Fair enough. However an active HUD would create some nice possibilities. But it's probably better to hold off on this until fpdb as a hole becomes more mature.
I'll take a look at this.
I prefer to talk in terms of focus as we aren't responsible for z ordering at all, and neither should the poker client - thats entirely the job of the window manager.
When the player windows are created, they are created as child windows of the client window, which signals the window manager as to where in the display heap they exist. The act of attaching a new child window appears to be sending a focus signal to the parent window (on windows).
Pre-creating all of the windows and only updating them is a possible solution, but i think it would require a significant refactor (the windows are indexed by player name)
Figuring out how to prevent the focus signal might be the easier option.
Which tree?
I'm interested in the failing hand history too - carl dot gherardi at gmail.
Git is decentralised - anyone can create a tree, clones from any other. If they have common parents then it is possible to share code between them.
I wrote what i think is a decent quick start guide to git:
http://****************/apps/mediawik...itle=Git_intro
But the part i left out was publishing your tree so that other developers are able to see it.
I took a good look at your logs. It appears that the importer is actually crashing silently.
Can you send me: Data Build\HH20100108 Mirnaya III... please?
Your log file goes:
2010-03-29 23:05:56,986 - importer INFO Started at 2010-03-29 23:05:56.987000 -- 1267 files to import. indexes: auto
Import some files....
Read: HH20100108 Mirnaya III
2010-03-29 23:07:16,500 - parser INFO Parsing 44 hands
Never finish
You restart (or do something else)
2010-03-29 23:08:04,204 - importer INFO Started at 2010-03-29 23:08:04.205000 -- 10 files to import. indexes: auto
Data Build\HH20100106 Schlutia II fast might also be an issue too.
There was a pretty serious bug between those two versions that affected heads-up and any time someone was posting blinds and the button.
There was a second minor bug where action lines were being skipped over if a playername started with card.
The biggest issue has been time. Its not that we aren't concentrating on more important issues, its that no issues are being worked on. There was a flurry of activity during the Christmass period into Feb but since the last test release, none of the core developers have been doing much. Those that were stimulating the activity at the time have solved their 'itch'.
The bugbear of open source is that it takes a personal interest in the feature/bug/request etc to motivate someone to donate the time. The chatter is good thing - we have two new people taking an active interest in code that needs fixing, and it in turn stimulates the other devs into discussing and helping.
Sorrow.
If and when I get the dev tree working It'll probably still be without mathplotlib, so I won't be able to test the code out myself.
Unless you can tell me the versions of the requierement list used in the 0.12-20100213.exe, so I can try installing those to possibly get mathplotlib working. According to what I read on the internet it has something to do with Python/Mathplotlib/gtk that created the problem (loading some time-funtion from some dll which doesn't contain that function).
Unless you can tell me the versions of the requierement list used in the 0.12-20100213.exe, so I can try installing those to possibly get mathplotlib working. According to what I read on the internet it has something to do with Python/Mathplotlib/gtk that created the problem (loading some time-funtion from some dll which doesn't contain that function).
There is a wiki page:
http://****************/apps/mediawik...e_Combinations
Listing the known working package combinations. ekdikeo had a functional python 2.6+matplotlib functioning aswell but that doesn't appear to be listed.
Hmm, I'll try to make a more spicific diagnosis next time it starts happening. But if I recall correctly, the crash repeats itself after I stop and then re-start the autoimporter multiple times (so this seems to rule out the concurrency issues). The HUD-main window displays (meaning it has been sent a hand by the autoimporter, meaning the import didn't fail (could have entered bad data in the db though), then it creates it's player-windows (I think), and then it crashes before those windows get correctly sized/formatted/filled in. So that's why I think it has something to do with the info it needs to display.
Since numbers, dots and percentage-symbols don't give any problems in and off itself, what remains are the names themselves, or some problem with the data from the db. Also, restarting fpdb doesn't solve the problem with that table in question. Closing the problematic table does. And the problem tables allways have some person with exotic UTF8 chars in them like "ae" (atached to each other). Anyway as I said, I'll look into it further.
One question though in which modules and where is the UTF8 parsing being done and used? I might take a look at it myself.
One question though in which modules and where is the UTF8 parsing being done and used? I might take a look at it myself.
The usual problem is that it gets inserted as xxxaexx and comes out of the db (which we try to match xxxaexx) as xxxaaeexx - its usually a 2 byte character converting to a 1 byte representation, and not being translated back again correctly.
The mucked card display isn't supposed to reorder windows at all, in the same way that the stats window update doesn't bring windows to the front. The intent is for either the window manager or the poker client to deal with focus, all we do is attach the hud windows as children and let the WM do the job of redrawing.
Create all windows at the same time, keeping the visible-parameter (or whatever it is called for gtk) set to false until actually needed. Or alternatively create them empty with a completely transparent background until needed. I think this last one is most likely to work, since I don't get the Z-order-issue with every update of the player-windows. The first one, if it works, would be easier to implement I guess.
I'll take a look at this.
So whenever a hud window is attached you are receiving a focus switch. The HUD isn't my area of expertise unfortunately
[\QUOTE]
Multiple focus/Z-order-switches. Often interleaved with focus-switches initiated by the Pokerstars-software. It sometimes looks like the windows will keep dancing around in the Z-order.
Most probably Eleatic Stranger has a system that is way better up-to-date then my aged system
Until next time
Socratic
[\QUOTE]
Multiple focus/Z-order-switches. Often interleaved with focus-switches initiated by the Pokerstars-software. It sometimes looks like the windows will keep dancing around in the Z-order.
Most probably Eleatic Stranger has a system that is way better up-to-date then my aged system
Until next time
Socratic
When the player windows are created, they are created as child windows of the client window, which signals the window manager as to where in the display heap they exist. The act of attaching a new child window appears to be sending a focus signal to the parent window (on windows).
Pre-creating all of the windows and only updating them is a possible solution, but i think it would require a significant refactor (the windows are indexed by player name)
Figuring out how to prevent the focus signal might be the easier option.
I'm interested in the failing hand history too - carl dot gherardi at gmail.
I installed the git-tree on one of my linux boxes. Edited GuiSessionViewer.py as per my own updated instructions, imported a couple thousand hands from my windows box and gave it a test-run.
Result, all hands got included (I.e. sum of Hds equals total number of hands)
Hands/hour look correct.
Winnings didn't crash, but I haven't investigated if it is correct now. However I think it's safe to assume it is.
to Sorrow: if you allow me, I'll be happy to commit those changes to the git ( after I find out how to do that offcourse)
Socratic
Result, all hands got included (I.e. sum of Hds equals total number of hands)
Hands/hour look correct.
Winnings didn't crash, but I haven't investigated if it is correct now. However I think it's safe to assume it is.
to Sorrow: if you allow me, I'll be happy to commit those changes to the git ( after I find out how to do that offcourse)
Socratic
I wrote what i think is a decent quick start guide to git:
http://****************/apps/mediawik...itle=Git_intro
But the part i left out was publishing your tree so that other developers are able to see it.
Can you send me: Data Build\HH20100108 Mirnaya III... please?
Your log file goes:
2010-03-29 23:05:56,986 - importer INFO Started at 2010-03-29 23:05:56.987000 -- 1267 files to import. indexes: auto
Import some files....
Read: HH20100108 Mirnaya III
2010-03-29 23:07:16,500 - parser INFO Parsing 44 hands
Never finish
You restart (or do something else)
2010-03-29 23:08:04,204 - importer INFO Started at 2010-03-29 23:08:04.205000 -- 10 files to import. indexes: auto
Data Build\HH20100106 Schlutia II fast might also be an issue too.
There was a second minor bug where action lines were being skipped over if a playername started with card.
I love what the program has developed to this point, and what all the contributors have done, but it "seems" to have gotten lost lately. I have no problem with people having more important issues. They ARE donating their time. But I fear I must move on, or resolve myself to using an older version that at least works fairly well and just live with the stats being not totally accurate.
The bugbear of open source is that it takes a personal interest in the feature/bug/request etc to motivate someone to donate the time. The chatter is good thing - we have two new people taking an active interest in code that needs fixing, and it in turn stimulates the other devs into discussing and helping.
Sorrow.
Feedback is used for internal purposes. LEARN MORE