Optimizing PT performance for BIG databases...remote database?
 

Bit of a long story, I'm going to try to make it short:

I'm tired of PT taking what feels like hours to import a few thousand hands, when I'm datamining, on a top-notch rig (AMD X2 Dual 4400+, 2gb RAM, SATA 7200RPM drive, blah blah blah). Generally I'm mining a fairly large number of tables distributed across a few PCs with VMWare running, but sometimes PT just seems to take a ridiculous amount of time to import the hands. When it's doing this, the PC is basically usable for web browsing, AIM, but that's about it; I can't do much in the way of poker. Ideally I'd like to try to get my home computer setup so that I can continue to mine on some tables while playing on another -- so I've decided to move the DB off to one of my other computers. Anyone currently doing this? I'd like to streamline it as much as possible.

Here are the setups that I have:

For playing:

XP 4400+, Dual Core, 2gb RAM (DDR400/PC3200, soon to be 4gb), 2x 7200RPM SATA HDS (250gb and 320gb). DFI Lanparty UT-SLI NForce4 board. Connected to LAN via a gigabit card and Netgear GS105 gigabet switch. System seems to scream for everything except PT. Ideally I will be running PAHud and Party on this machine. I also frequently run multiple instances of VMWare either to datamine or to work on other projects where I need multiple clients of XP running.

Setup #2:

Older Northwood core P4 3.06ghz. 2gb RAM (PC2100). MSI 845PEMax2 motherboard, Adaptec 29160N U160 SCSI controller + Fujitsu Ultra320 15kRPM HD (36.7gb). Also has an older 60 or 80GB Deskstar HD (7200RPM) that I wouldn't mind using as a backup drive for the DBs / installation drive.

Since I'm effectively trying to start from scratch here, I'd appreciate opinions on the best way to set everything up, given that I intend on having multiple million+hand DBs being stored on the computer. I'm considering running PT on both computers, but only running the observed DB on one of them; any sense to doing this? One of the reasons I'm doing this now is that I plan on getting a lot of data stored, and am hoping to do at least some analysis on it later on (mostly blind defense and things like that).

Anyway. Long story, tried to make it short, mostly failed. Would appreciate any comments before I plunge headfirst into this.

Rob

Re: Optimizing PT performance for BIG databases...remote database?
 

I guess the big question is rather you need to run PT on the machine you are playing on or not. My guess it that it is not required.

If you can, then I would setup something like... FC5 on the older PC with PSQL, Samba and VMWare server. Setup a VM with XP for PT. Setup your poker apps to save HH to a Samba share, point PT from the other VM to that same share and to use PSQL on the FC5 box.

I am just not sure about PAHUD and what exactly you would need to do there. If you can just install the PSQL ODBC and ODBC DSN you should be good. Maybe just install PT on your poker manchine and get it setup to use the PSQL DB's and that should be enough for PAHUD and just never use the PT install on the poker machine. You would have to play with it, at PAHUD folks etc it will work without PT installed locally or not.

At least that way, you wouldn't be affected by the PT lag of importing hands.

Re: Optimizing PT performance for BIG databases...remote database?
 

[ QUOTE ]
When it's doing this, the PC is basically usable for web browsing, AIM, but that's about it; I can't do much in the way of poker.

[/ QUOTE ]

I have a very similar configuration to yours and I don't see this. CPU usage tops out at 40% (mostly postgreSQL). Something wrong here.

Remote DB should be fine for analysis.

Re: Optimizing PT performance for BIG databases...remote database?
 

[ QUOTE ]
[ QUOTE ]
When it's doing this, the PC is basically usable for web browsing, AIM, but that's about it; I can't do much in the way of poker.

[/ QUOTE ]

I have a very similar configuration to yours and I don't see this. CPU usage tops out at 40% (mostly postgreSQL). Something wrong here.

Remote DB should be fine for analysis.

[/ QUOTE ]

How many hands are you importing when this is the case? It's not that way for nonobserved hands, but when I'm mining, it's usually pulling about ~6k hands per hour.

Re: Optimizing PT performance for BIG databases...remote database?
 

Try reducing Poker Tracker's priority to below normal (ctrl-alt-delete, processes, right click ptrack2.exe, set priority).

Btw, I have database on remote machine, but it doesn't offer any speedups during import. I use monthly databases (each about 1mio mined hands) for observed hands to keep the imports reasonably fast. To avoid constantly rebuilding PAHud's cache, I've created monthly databases in advance (April-December) and included them all.

-pix

Re: Optimizing PT performance for BIG databases...remote database?
 

Hard to say. I'd estimate around 2K/hr, could be more. I mean, it's totally a non-issue for me, I wouldn't even know it's there.

Since you have everything spread over multiple PCs, it could be a network problem especially if your CPU usage is not spiking under task manager. I use NetBEUI, not TCP/IP.

Re: Optimizing PT performance for BIG databases...remote database?
 

With your proposed setup I would do the following: (I've been thinking about doing this for awhile now)

1. Move your Postgres databases to your server.
2. Increase Postgres' memory usages to about 75% of your server's memory.
2. Install PT on both server & main computer
3. Use PT on server for import; PT on main computer only for viewing stats

This would alleviate PT's and Postgres' CPU load on your main computer. On my machine, I'm looking at ~50-60% CPU usage at times.

You may notice a slight speed-up of imports with this situation. Probably nothing very notable if at all. The key IMHO is the reduced CPU load on your main computer...

Re: Optimizing PT performance for BIG databases...remote database?
 

To resolve this:

[ QUOTE ]
When it's doing this, the PC is basically usable for web browsing, AIM, but that's about it; I can't do much in the way of poker.

[/ QUOTE ]

do this:

[ QUOTE ]
Try reducing Poker Tracker's priority to below normal (ctrl-alt-delete, processes, right click ptrack2.exe, set priority).

[/ QUOTE ]

Why does Poker Tracker have to be so [censored] slow?
 

I think the main problem with PT is that their is some fundamental problem with it's design (either in it's schema or in the use of PowerBuilder code for it's parsers).

I agree that when PT was first designed then the sheer amount of data generated by datamining was never foreseen, but there seems to be very little work aimed at improving this aspect over the last 2 years.

The PAHUD and SS meta databases seem to be able to get round the slowness of retrieval, but by far the most frustrating part is the time it takes to import the hands (plus the strange exponential performance decay).

I have several million hand histories now collected and cannot face importing them into PT because of the stupid amount of time it would take to do this. The last time I tried, I borrowed a cutting edge machine (with raid drives and extreme amounts of memory) and it took something like 3 days to import 700k hands into a PGSQL DB. Then when I moved it back to my machine it was totally unusable and I had to give in (pre meta databases).

I then moved to using PokerManager. Since using PM I quite happily imported and used a 3 million hand DB without any of the problems I had with PT (no exponential import times, no machine lockups for 40 mins, no unusable DBs, overall 3-4x faster imports, smaller DB size, etc).

A) If more people were to look into using PM then I'm sure it would in turn become more popular and Ben (the SS author) would be more willing to work on it and update/improve it. Ultimately we would all benefit from this, yet everybody seem to be happy to keep using PT with all of the flaws.

B) Alternatively (if it is within copyright law), I am sure somebody could use the PT schema (if it is not the schema itself which is flawed...) and write much faster parsers for getting the data into the DB in the first place.

C) If outside of copyright law or the schema itself is fatally flawed, then perhaps somebody could sit down and completely redesign a "database" or schema. I'm not even convinced that using commercially available DBs is necessary and just creates unnecessary bloat.

Poker Tracker may have cornered the market when it comes to personal hand history analysis, but I feel there is a HUGE market (of frustrated PT users) just waiting for a decent solution to observed hand history import and retrieval.

Juk [img]/images/graemlins/smile.gif[/img]

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
I think the main problem with PT is that their is some fundamental problem with it's design (either in it's schema or in the use of PowerBuilder code for it's parsers).

I agree that when PT was first designed then the sheer amount of data generated by datamining was never foreseen, but there seems to be very little work aimed at improving this aspect over the last 2 years.

The PAHUD and SS meta databases seem to be able to get round the slowness of retrieval, but by far the most frustrating part is the time it takes to import the hands (plus the strange exponential performance decay).

I have several million hand histories now collected and cannot face importing them into PT because of the stupid amount of time it would take to do this. The last time I tried, I borrowed a cutting edge machine (with raid drives and extreme amounts of memory) and it took something like 3 days to import 700k hands into a PGSQL DB. Then when I moved it back to my machine it was totally unusable and I had to give in (pre meta databases).

I then moved to using PokerManager. Since using PM I quite happily imported and used a 3 million hand DB without any of the problems I had with PT (no exponential import times, no machine lockups for 40 mins, no unusable DBs, overall 3-4x faster imports, smaller DB size, etc).

A) If more people were to look into using PM then I'm sure it would in turn become more popular and Ben (the SS author) would be more willing to work on it and update/improve it. Ultimately we would all benefit from this, yet everybody seem to be happy to keep using PT with all of the flaws.

B) Alternatively (if it is within copyright law), I am sure somebody could use the PT schema (if it is not the schema itself which is flawed...) and write much faster parsers for getting the data into the DB in the first place.

C) If outside of copyright law or the schema itself is fatally flawed, then perhaps somebody could sit down and completely redesign a "database" or schema. I'm not even convinced that using commercially available DBs is necessary and just creates unnecessary bloat.

Poker Tracker may have cornered the market when it comes to personal hand history analysis, but I feel there is a HUGE market (of frustrated PT users) just waiting for a decent solution to observed hand history import and retrieval.

Juk [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]

PM looks good; I'll keep it in mind for some use in some of the analysis I hope to do on the larger databases. Do you know if there are any plans for any HUDs in the future to use/support it?

Rob

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
[ QUOTE ]
I think the main problem with PT is that their is some fundamental problem with it's design (either in it's schema or in the use of PowerBuilder code for it's parsers).

I agree that when PT was first designed then the sheer amount of data generated by datamining was never foreseen, but there seems to be very little work aimed at improving this aspect over the last 2 years.

The PAHUD and SS meta databases seem to be able to get round the slowness of retrieval, but by far the most frustrating part is the time it takes to import the hands (plus the strange exponential performance decay).

I have several million hand histories now collected and cannot face importing them into PT because of the stupid amount of time it would take to do this. The last time I tried, I borrowed a cutting edge machine (with raid drives and extreme amounts of memory) and it took something like 3 days to import 700k hands into a PGSQL DB. Then when I moved it back to my machine it was totally unusable and I had to give in (pre meta databases).

I then moved to using PokerManager. Since using PM I quite happily imported and used a 3 million hand DB without any of the problems I had with PT (no exponential import times, no machine lockups for 40 mins, no unusable DBs, overall 3-4x faster imports, smaller DB size, etc).

A) If more people were to look into using PM then I'm sure it would in turn become more popular and Ben (the SS author) would be more willing to work on it and update/improve it. Ultimately we would all benefit from this, yet everybody seem to be happy to keep using PT with all of the flaws.

B) Alternatively (if it is within copyright law), I am sure somebody could use the PT schema (if it is not the schema itself which is flawed...) and write much faster parsers for getting the data into the DB in the first place.

C) If outside of copyright law or the schema itself is fatally flawed, then perhaps somebody could sit down and completely redesign a "database" or schema. I'm not even convinced that using commercially available DBs is necessary and just creates unnecessary bloat.

Poker Tracker may have cornered the market when it comes to personal hand history analysis, but I feel there is a HUGE market (of frustrated PT users) just waiting for a decent solution to observed hand history import and retrieval.

Juk [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]

PM looks good; I'll keep it in mind for some use in some of the analysis I hope to do on the larger databases. Do you know if there are any plans for any HUDs in the future to use/support it?

[/ QUOTE ]
I think it comes down to the fact that Ben spent ages getting it to the stage where it is now, but there was just an overall lack of interest in it (I agree it needs polishing and can be improved on, but on the other hand I can understand that if their is no real PM user-base then their is no incentive to do this...).

I looked into it and did manage to figure out how to query the FireBird DB from C/C++ and it looks like it wouldn't actually be that hard to get GT+ to use the PM DB rather than the PT DB (I have some code snippets that will let me send queries to the DB and Ben published a list of helpful queries in the PM forum to help).

I think it's a chicken and egg problem. Everything supports PT because it got in their first, so they are tied to using PT. Nobody wants to give up their tools which rely on PT, but I'm pretty some nearly everybody would appreciate being able to handle much more data without all the problems associated with PT.

Juk [img]/images/graemlins/smile.gif[/img]

Re: Why does Poker Tracker have to be so [censored] slow?
 

juk,

Do you use a HUD at all? I saw that PM had one included, but people seemed to be complaining about how well it worked. With a HUD, it seems like it'd be quite a good product.

Rob

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
Do you use a HUD at all? I saw that PM had one included, but people seemed to be complaining about how well it worked. With a HUD, it seems like it'd be quite a good product.

[/ QUOTE ]
Yep, I did use the PM HUD but agree it needs some work (and is Party only atm), but I'm not really one for using vast amounts of stats whichever HUD I use (VPIP/PFR/AGR/WtSD/#Hands).

I'm pretty sure if more people tried PM and took an interest, then it could develop into a much better product than either PT (or PO) for dealing with large amounts of data.

Juk [img]/images/graemlins/smile.gif[/img]

Re: Why does Poker Tracker have to be so [censored] slow?
 

Hi all,

just found this interesting tit-bit on the PT Postgres forum:
http://www.pokertracker.com/forum/viewtopic.php?t=15282

Good news: Looks like PT import may get near a 50% boost in speed if this is accurate - I just made some small import logs myself and it looks accurate, but I didn't really do a great deal of study on the matter. It was only posted today, but it seems like a fairly simple change for PT Pat to make [img]/images/graemlins/smile.gif[/img]

Bad news: I'm gonna have to go in to work tomorrow and scour the database functions we use and purge all occurences of SELECT MAX(..., fun times [img]/images/graemlins/smile.gif[/img]


Network setup - FWIW I think ideal setup would be three computers on the gigabit LAN

Computer 1 - Playing machine, decent spec - (Your current playing machine sounds overly capable). PT installed but only for session review etc. No PT imports runnning on this machine, HH folder shared on network. use VMs to mine hands with space capacity.

Computer 2 - Postgres server, Linux? decent CPU, fast disk (iRAM?), plenty fast RAM. Prolly can run a VM or 2 on this also.

Computer 3 - PT import machine, Very fast single core CPU (Maximum GHz, PT won't use a second core - overclock the P4 maybe?), and pull played/mined hands from network share, import to DB on Computer 2.

Would likely be a nice setup [img]/images/graemlins/smile.gif[/img]

dave.

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
Hi all,

just found this interesting tit-bit on the PT Postgres forum:
http://www.pokertracker.com/forum/viewtopic.php?t=15282

Good news: Looks like PT import may get near a 50% boost in speed if this is accurate - I just made some small import logs myself and it looks accurate, but I didn't really do a great deal of study on the matter. It was only posted today, but it seems like a fairly simple change for PT Pat to make [img]/images/graemlins/smile.gif[/img]

Bad news: I'm gonna have to go in to work tomorrow and scour the database functions we use and purge all occurences of SELECT MAX(..., fun times [img]/images/graemlins/smile.gif[/img]


Network setup - FWIW I think ideal setup would be three computers on the gigabit LAN

Computer 1 - Playing machine, decent spec - (Your current playing machine sounds overly capable). PT installed but only for session review etc. No PT imports runnning on this machine, HH folder shared on network. use VMs to mine hands with space capacity.

Computer 2 - Postgres server, Linux? decent CPU, fast disk (iRAM?), plenty fast RAM. Prolly can run a VM or 2 on this also.

Computer 3 - PT import machine, Very fast single core CPU (Maximum GHz, PT won't use a second core - overclock the P4 maybe?), and pull played/mined hands from network share, import to DB on Computer 2.

Would likely be a nice setup [img]/images/graemlins/smile.gif[/img]

dave.

[/ QUOTE ]

3 comps is overkill, unfortunately, for my office. I'll probably just have the Import comp be the same as the SQL server unless there really seem like there will be issues with doing that. Having the SCSI 15kRPM HD should really help speed things up I think.

Rob

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
and write much faster parsers for getting the data into the DB in the first place.

[/ QUOTE ]

Brilliant idea. I'll start tonight.

rvg

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]

3 comps is overkill, unfortunately, for my office. I'll probably just have the Import comp be the same as the SQL server unless there really seem like there will be issues with doing that. Having the SCSI 15kRPM HD should really help speed things up I think.

Rob

[/ QUOTE ]

3 comps is indeed a bit of overkill - so long as the play computer is not doing the import I expect it will be smooth runnings [img]/images/graemlins/smile.gif[/img]

dave.

Re: Why does Poker Tracker have to be so [censored] slow?
 

I'm kinda having the same problem. After I start up I get this error constantly Import Finished With Errors - The import finished but there were errors. Open the Utilities/Error Log Display/Maintenance window to see the errors - 114 file(s) read - 0 new hand(s) were imported.

should I just purge all the errors or should I be doing something else?

Also when I try to compact the database it it starts making a backup of the database and then the error comes up: Compact failed! Make sure you dont have the database open in another program (like Gametime+ or PokerAce Hud)

I dont have any of those things open and I even have party closed. What should I do about this? This is my first database and I'm still learning everything about PT. Thanks for any help.

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
[ QUOTE ]
and write much faster parsers for getting the data into the DB in the first place.

[/ QUOTE ]

Brilliant idea. I'll start tonight.

rvg

[/ QUOTE ]

This would be nice.

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
I think the main problem with PT is that their is some fundamental problem with it's design (either in it's schema or in the use of PowerBuilder code for it's parsers).


[/ QUOTE ]

It appears that there is a leak in their code, I think they are not po0ling their db connections or not releasing them them somehow. There is a limit where it just hits a wall and db connections and memory goes up and performance goes down, but I haven't really figured it out since i cant do anything about it anyways.

The schema's allright, a few little things that get into any software, especialy when you figure they added on sites and functionality with upgrades.

There are lots Id do differently, but when I look at any db that I designed, by the time I get to release, Id say the same thing. BUT if just a few indexes and constraints were added i think it would help a lot, but you would have to know the exact t-sql the PT client uses.


enough ramblings .. thanks juk for the link (again)

Re: Why does Poker Tracker have to be so [censored] slow?
 

probably worth a post on the pokertracker forums rather than here.

Re: Why does Poker Tracker have to be so [censored] slow?
 

if anybody is interested, I wrote a clone as a proof of concept last year for part of my undergraduate work that I am willing to continue work on if there is interest. If I release it I would release it as under the GPL.

The code is all C# and uses mysql for a backend. The schema I designed is quick for retrieval, somewhat slower for insertions, but still several times faster than PT for both. It appears to scale well, but I only had a party parser and could only come up with about 40K hands I think when I was testing it.

If anybody is interested in helping with coding, testing, providing test data, or just generally interested PM me.

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]

BUT if just a few indexes and constraints were added i think it would help a lot, but you would have to know the exact t-sql the PT client uses.


[/ QUOTE ]

FWIW, you can get the exact sql used by enabling full logging by editing postgres.conf - (log_connections = true, log_statement = 'all')

From my unknowledgeable glances at the log file, it would seem the main problem is PT parsing all the HH files and generating all the SQL prior to executing it - it seems there is something (nested loops?) in the HH parser / SQL generator that causes an almost exponential increase in CPU time, as noticed by people importing huge numbers of hands slowly, finding it much faster to divide the hands in to smaller blocks and import each block sequentially.

There are some SELECT MAX(id) commands in there (as referenced in my previous link) that could be re-written to improve speed, but I'm fairly sure the major time sink is in the parser rather than in the execution of the SQL generated.


dave.

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
if anybody is interested, I wrote a clone as a proof of concept last year for part of my undergraduate work that I am willing to continue work on if there is interest. If I release it I would release it as under the GPL.

The code is all C# and uses mysql for a backend. The schema I designed is quick for retrieval, somewhat slower for insertions, but still several times faster than PT for both. It appears to scale well, but I only had a party parser and could only come up with about 40K hands I think when I was testing it.

If anybody is interested in helping with coding, testing, providing test data, or just generally interested PM me.

[/ QUOTE ]

Was this an exact clone of the PT table structure?

If so, a few adjustments to the parser element to make it work with existing PT postgres databases could be incredibly useful to many on this forum, I would think.

dave.

Re: Why does Poker Tracker have to be so [censored] slow?
 

No, the database schema was different to some degree, I don't remember how much.

I'll take some time tonight and look at both of the schemas and see how much modification would be necessary.

Re: Why does Poker Tracker have to be so [censored] slow?
 

Some more info: I am running the access PT database right now for whatever reason, so I don't have the PT schema handy. Not a big deal, I've been going to convert to postgres because I need to anyway. Ever run an access db that is 500MB? Don't do it.

The guy that is rewriting the parser is trying to make it so that it will take in a file that specifies the hand history format in EBNF using regular expressions, and will from there be able to create a parser/compiler. However he is busy with whatever, I'm going to try to get him to explain the plan to me enough so I can take over his code.

The code that fills my database and the PT database cannot be that different as we both are representing the same information. Mine was just a lot more compact, it has been half a year since I have worked on the schema though, so I could be fuzzy.

I have a lot of things going on this week, trying to figure out if I want to continue my education and be a bum for 3 more years or if I want to get a real job, I'm not sure which would make it easier to pursue outside projects like this one. I will try to figure out if my parser can be used to import for large volume imports into the PT database, but it will be the end of the week before I have any solid ideas.

Re: Optimizing PT performance for BIG databases...remote database?
 

Besides what others have said, if you haven't already, turn off autorate when importing.

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
[ QUOTE ]
and write much faster parsers for getting the data into the DB in the first place.

[/ QUOTE ]

Brilliant idea. I'll start tonight.

rvg

[/ QUOTE ]

I am still working on this - should have some metrics in the next couple of weeks and a beta shortly afterwards.

rvg

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]


From my unknowledgeable glances at the log file, it would seem the main problem is PT parsing all the HH files and generating all the SQL prior to executing it - it seems there is something (nested loops?) in the HH parser / SQL generator that causes an almost exponential increase in CPU time, as noticed by people importing huge numbers of hands slowly, finding it much faster to divide the hands in to smaller blocks and import each block sequentially.


[/ QUOTE ]

I have postgres running on a linux machine that is much lower spec than my windows machine. when importing, load on the linux machine is very low, however the windows machine goes to pretty much 100%. so I def agree that the bottleneck is in the parser/generating the sql rather than the db work itself.

Re: Why does Poker Tracker have to be so [censored] slow?
 

There is tremendous room for improvement in the PT algorithm for parsing/loading HH's. It's obvious if you just use Windoze taskmgr and see that PT is CPU bound during the HH loading.

I think someone should write a hand parser that bypasses PT and updates the PTAGG database directly from HH's. To prevent data duplication, just add a table to the PTAGG DB that contains all the hand #'s that have already been parsed. And of course convice Josh of PokerAce fame to use the PTAGG DB rather than his own custom DB.....

Then just use PT for it's original purpose.....analysis of your own play [img]/images/graemlins/smile.gif[/img]

There.... I just solved most of the CPU load problems of online poker players LOL!

G'luck all,
LVGamb00ler

Re: Why does Poker Tracker have to be so [censored] slow?
 

[ QUOTE ]
if anybody is interested, I wrote a clone as a proof of concept last year for part of my undergraduate work that I am willing to continue work on if there is interest. If I release it I would release it as under the GPL.

The code is all C# and uses mysql for a backend. The schema I designed is quick for retrieval, somewhat slower for insertions, but still several times faster than PT for both. It appears to scale well, but I only had a party parser and could only come up with about 40K hands I think when I was testing it.

If anybody is interested in helping with coding, testing, providing test data, or just generally interested PM me.

[/ QUOTE ]

Sounds awesome, I'd love to have a look and see if I can improve/work on it. Given you a pm