PT2 and nextpoker (ongame content)

[d0zerz]

I'm trying to set up PT2 with nextpoker, and am having some problems.

I'm running Postgres, and have installed the SQLLite ODBC drivers, am running PT 2.17.02.

nextpoker creates a UserxxxxxStatistics.db file in the \Resources\Databases\ directory, which is where I have PT2 pointing at when I open the "Auto-Imoprt PokerRoom (Ongames Skins)" window.

When I read from the database, it appears to read the hands, but then when it goes through the hands, it finishes with an error for each hand "Error - duplicate seats found for game...", and 0 hands are actually imported.

Any ideas?

[ptrack pat]

This indicates the PokerRoom database file you have PT importing from is corrupt.

Under the Statistics menu on the lobby window you need to select "Advanced" > "Create Statistics File". Give it a name and then it will start to use a different file than the one that is corrupted. In Poker Tracker, on the File/Auto-Import PokerRoom (and skins) Hand Histories window click the Configure Hand History Files button and tell PT about this new file. Note also that you can delete the pointer to the older db file so PT doesn't keep trying to look at that each time and continue giving errors.

[d0zerz]

Thanks pat,

...weird because I tried deleting the .db file and having the app re-create it, but that didn't work...

the "create statistics file" however, did work. The first time.

The second time I got the same problem again. Maybe I'll have to use the PT "reset DB" after every session, which also seems to fix the import issue...

[ptrack pat]

The reset DB's button deletes all the hands from the Ongame .db file but you shouldn't be getting these kinds of errors like this.

Do you multi-table a lot of tables?
Do you get frequent disconnects?

[d0zerz]

I don't get disconnects very often if at all, but I do average 6-9 tables.

Yesterday was my first 'real' session at nextpoker, and I played 6 tables for about 300 hands, which all imported correctly. (I did a reset DB before the session).

I don't mind resetting the DB before or after every session...letting that db file get too big slows down imports anyway, right?

[ptrack pat]

Right, resetting after each session would be OK.

BUT PLEASE NOTE!!! -- The Ongame software has a severe lag in the time that it takes them to write the hand histories to the database file when you multi-table like this. So I always suggest that when you are done playing leave the Ongame lobby window open for up to an hour afterwards so that it can catch up and write all the hands. So I wouldn't do the reset right after you are done playing. Leave the lobby window open, use the Force Import button on the auto-import window to make sure it's got all the hands imported and then use the reset db's option.

[d0zerz]

Right, resetting after each session would be OK.

BUT PLEASE NOTE!!! -- The Ongame software has a severe lag in the time that it takes them to write the hand histories to the database file when you multi-table like this. So I always suggest that when you are done playing leave the Ongame lobby window open for up to an hour afterwards so that it can catch up and write all the hands. So I wouldn't do the reset right after you are done playing. Leave the lobby window open, use the Force Import button on the auto-import window to make sure it's got all the hands imported and then use the reset db's option.

Maybe I'll just do the reset at the start of each session then, before I've loaded the ongame software.

So what happens if at the end of my session, I close down all my tables, then the lobby...surely then it has to flush all unwritten hands to its database, no? Or does it cache them in another persisted file before committing them to its local *.db file?

As a software developer myself, I don't envy your task of having to support these often updated hand history formats across all the different sites :o

[ptrack pat]

So what happens if at the end of my session, I close down all my tables, then the lobby...surely then it has to flush all unwritten hands to its database, no? Or does it cache them in another persisted file before committing them to its local *.db file?

From what I have seen based on problems with other users the hand are never written, they are gone for good. It doesn't write the rest of the hands and when you log back in later it doesn't pick up where it left off, they are just lost for good.