New Software Announcement - SIXTH SENSE - Page 64

SixthSense · #**631** 08-20-2006, 02:31 PM

[ QUOTE ]
Another issue:
So I recently REPLACED a DB on my laptop with one of the very same name. E.g. I had postgres database XYZ on my laptop, then used the SQL Database functions window in PT to delete it completely, and copied over a NEWER version of that same XYZ DB from my desktop (which i use to mine).

So essentially I simply replaced the DB with one of the same name, but with 200,000 or so new hands in it. But I fire up PTAGG, expecting it to start importing all the new hands, but it doesn't seem to recognize that there's a whole batch of new hands (albeit in the DB of exactly the same name.)

Is there a way to get it to recognize these new hands?

[/ QUOTE ]

Based on what you describe, PTAgg *should've* found the new hands and imported them. It stores a "Last GameID" for each database, and checks to see when it goes higher. Maybe if for some reason that 2nd database you had started at a higher GameID? That would be strange though, I can't think of a case that would cause that.

I've heard other reports that PTAgg doesn't always import new data, so its something I'm looking into. When I find something I'll let everyone know. Also, if you notice any obvious patterns in something that causes it please let me know too.

-Ben

SixthSense · #**632** 08-20-2006, 02:32 PM

[ QUOTE ]
n/m - I'm experiencing really slow scanning but I think it may be my system..

[/ QUOTE ]

Check some of the previous pages in this thread that talk about slowdowns from Party's monster tables. The solution is to use the de-monster AHK script also on this board.

-Ben

SixthSense · #**633** 08-20-2006, 02:33 PM

[ QUOTE ]
-its showing 1.7 for a 6-handed table where I have stats on all 6 players. On another 2.8 where I have stats on all 6 players.

I assume the data field is some how weighted towards some statistical measure because its not just the number of players with stats at a table.

[/ QUOTE ]

[ QUOTE ]
Not for me - they are always integer numbers (although stated as 5.0, 6.0 etc). Weird.

[/ QUOTE ]

Yes, there is a weighting going on. Also, there's an option in the Custom User Scoring called "Use Convergence", if this is turned off you'll just get integer values, otherwise they are scaled for players < 300 hands.

-Ben

SixthSense · #**634** 08-20-2006, 02:34 PM

[ QUOTE ]
Ben,

This has been going on for a while and it's mildly annoying: there seems to be a timing problem with clicking the join button and the subsequent table opening. I use Open and Join and almost half the tables and up open, but NOT joined.

[/ QUOTE ]

Thanks. I'm not the expert on the AHK scripts, Dan is, but I'll forward this to him.

-Ben

Hoopster81 · #**635** 08-20-2006, 04:39 PM

[ QUOTE ]
The pricing will be $15, $30, and $45 per month for the Bronze, Silver, and Gold levels.

[/ QUOTE ]

[img]/images/graemlins/shocked.gif[/img]

Back In Black · #**636** 08-20-2006, 05:50 PM

[ QUOTE ]
[ QUOTE ]
The pricing will be $15, $30, and $45 per month for the Bronze, Silver, and Gold levels.

[/ QUOTE ]

[img]/images/graemlins/shocked.gif[/img]

[/ QUOTE ]

Yeah....This is kind of way more than I was expecting. Looks like I'll be going back to PokerTableScan. Oh well. It was a fun ride while it lasted.

Back In Black · #**637** 08-20-2006, 05:58 PM

Why dont you guys release a pricing scheme also weighted on how many sites you're using 6thsense for? Isn't multiple site scanning what would take up the most bandwidth? If I only want to use it with Party, why should I pay the same amount as people who are acanning across 5 different sites?

bhudson · #**638** 08-20-2006, 06:23 PM

Wow... yeah back to PTS for me as well.. pity.

teddyFBI · #**639** 08-20-2006, 06:28 PM

[ QUOTE ]
[ QUOTE ]
Another issue:
So I recently REPLACED a DB on my laptop with one of the very same name. E.g. I had postgres database XYZ on my laptop, then used the SQL Database functions window in PT to delete it completely, and copied over a NEWER version of that same XYZ DB from my desktop (which i use to mine).

So essentially I simply replaced the DB with one of the same name, but with 200,000 or so new hands in it. But I fire up PTAGG, expecting it to start importing all the new hands, but it doesn't seem to recognize that there's a whole batch of new hands (albeit in the DB of exactly the same name.)

Is there a way to get it to recognize these new hands?

[/ QUOTE ]

Based on what you describe, PTAgg *should've* found the new hands and imported them. It stores a "Last GameID" for each database, and checks to see when it goes higher. Maybe if for some reason that 2nd database you had started at a higher GameID? That would be strange though, I can't think of a case that would cause that.

I've heard other reports that PTAgg doesn't always import new data, so its something I'm looking into. When I find something I'll let everyone know. Also, if you notice any obvious patterns in something that causes it please let me know too.

-Ben

[/ QUOTE ]

1) Oh, well this might help with figuring out the above. What is the GameID you speak of, and is it ordered by the DATE the hand was played, or when the HH was imported into PT, or something? Because think about what would happen if I imported a batch of HHs from Aug 21, for example, and then ran PTAGG, but then realized I had a bunch of HHs from Aug 1 through 20 that I hadn't imported, so I then imported those...if PTAGG asssigns GameID based on when the HH is imported, then no prob, b/c it will assign the older HHs a higher GameID and "find them"...but if it assigns GameID based on date the hand was played, then it will give LOWER GameIDs to the Aug 1 - 20 HHs, and then "skip" them tne next time it looks for "new" HHs. I'm not 100% sure that this is what happened in my case, because I do a lot of moving around and importing of HHs...but it's one explanation, no? Even if I'm right, it's not something that necessarily needs to be changed...still the user should probably be made aware that s/he should always import HHs in chronological order...

2)I have never been a huge fan of the "converge data" method (preferring, instead, a way that you could just tell SS to assign a full weight to players with a min # of hands), but I've gradually come to appreciate that it's not all that different...but as another poster alluded to, I think the NumData field (or whichever one tells you how many players you have data for at the table) is one that really should be done "my way", as opposed to the convergence way. Just intuitively: it doesn't make sense to "have data" on 2.7 out of 6 players at the table. The reason people want to see that field is for a quick look at how many of the players at the table they will have "reads" on. Anything less than a whole integer is a little confusing. This is more of a minor annoyance since my DBs are so robust, I usually don't even bother looking at that field anymore...still something for which I see where other ppl are coming from.

3) Pricing is just fine, guys. Don't fall for the 'guess i won't be using it' line.

goodguy_1 · #**640** 08-20-2006, 07:41 PM

[ QUOTE ]
3) Pricing is just fine, guys. Don't fall for the 'guess i won't be using it' line.

[/ QUOTE ]

I agree-the pricing is extremely reasonable especially with the 2p2 bonus code discount and the discount for long term subscription. I will be a 12 month gold subscriber for sure.

This thing pays for itself easily in one or two days for the month.