Quote:
Originally Posted by Shininggg
i ran into a weird problem here i'll try to explained as much as i can:
It seems that in order for the Hud to appear it has to do it before the auto_import process...
Let's say i leave the interval at 10 (default) and start auto-import, the main HUD window appear but the stats aren't. I can see in the command line:
HUD_main starting
Using db name = fpdb
Hands are importing fine by the way no error in the cmd window
then i closed the fpdb UI (hence stoppping the auto-import process) then TADAM stats appear (i reproduced it a couple time just to make sure...)
So i tried increasing the interval, just to see if the stats would appear before the auto-import process and turns out that if leave enough time for the stats to appear (which depend on the num of table you're playing) everything will works fine
example if i play 4 table i have to increase the interval to 90sec so that the stats appear
My setup is under windows xp, and i'm not using postgreSQL
You don't really need to read this next paragraph.
I think I know what is going on here, I just don't know why. When fpdb starts the HUD, the HUD is a separate program and the two are connected by a pipe. A pipe is just an operating system thingie that lets the two programs communicate. When fpdb imports a hand it writes the hand number to the pipe, the HUD sees that hand number show up on the pipe and the HUD updates the stats based on that hand. Operating systems like to buffer output, that is, they save it up until they have enough to send and then send what they have saved. fpdb turns off buffering, so that the hand number gets sent immediately.
So it sounds like Windows is buffering the pipe output. So fpdb is busily importing hands, but nothing gets to the HUD until the buffer is full. That is why you see stats sooner when you have 4 tables open and why longer intervals seem to make it work--I think shorter intervals and waiting longer would have the same result. I suspect that you also see stats on all 4 tables at the same time, when they should pop up as the hands are finished.
So the question is: why is Windows buffering when I told it not to? I just looked at the code and buffering is indeed turned off in the alpha3 and alpha4 versions. I am stumped. I have run the same code on my windows xp box and have not seen anything like this.
How are you starting fpdb?
Are you running anything unusual that might be overriding pipe settings on a global basis?
When you run with a shorter interval your terminal output looks something like this:
Code:
GuiAutoImport.import_dir done
HUD_main starting
Using db name = fpdb
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
Opened file /home/xxxx/Desktop/xxxxxx/HH20080917 Dejopeja II no all-in - $0.50-$1 Ante $0.05 - Limit Razz.txt and connected to MySQL on 192.168.1.100
Total stored: 1 duplicates: 0 partial: 0 errors: 0
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
Opened file /home/xxxx/Desktop/xxxxx/HH20080917 Dejopeja II no all-in - $0.50-$1 Ante $0.05 - Limit Razz.txt and connected to MySQL on 192.168.1.100
Total stored: 1 duplicates: 1 partial: 0 errors: 0
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
GuiAutoImport.import_dir done
When you run with a longer interval you get a whole bunch of these pairs:
Opened file /home/xxxx/Des ....
Total stored:
1 duplicates: 1 partial: 0 errors: 0
but the total stored is more than 1 probably