that's a different problem!
to solve this we need worker management in bithopper (both: client and pool side)

then we don't have that issue any more

should be easy...

just setup an apache with php (or something else) and make a redirect script (sth like this http://demo.loopip.com/integration_demo/search/php_reverse_proxy) which takes the url to retrieve (eg. http://localhost/statsproxy.php?url=#real stats page#

then change the pool.cfg to use your redirection.

wouldn't it be enough to just get the stats through tor and send the getworks directly?

there is no nice way to fix this issue on client side.
i guess its the pool-api which returns zero round_shares sometimes (maybe this is even made for us hoppers).

the only way i could imagine is to sanitize data. means: if i see there were zero round shares supplied and afterwards some very high i could just change the zeros to the start value.

but this doesn't work with ozcoin invalids handling (when ozcoin gets an invalid it just make the last round longer - means no "invalid" or "unpaid" shares - there you would see the exact same behavior)

but i don't like that idea: a graph has to show what it got from the pool. nothing else.

see it as a hint that this pools tries to cheat you (which is the reason i made this graph in the first place)

i'll see how far i get this evening
if i have time left i'll implement jqPlot graphs (similar to eligius one) where you could change time-range displayed and zoom in and out. but that depends on my time.

i'll fix it - its very easy.
i made a very simple mistake by only rendering the graph when role="mine". should be role.startsWith(mine) instead.
when i did this page i did not know about mine_slush or mine_nmc and such.

as i don't use slush i don't know why.

could you post a picture?

^^ please talk to c00w about that first..
i dont want to mess with the python

as soon as this info is available i'll add it and it'll merged to c00w's version.

as far as i understood c00w's recent changes bitHopper now has a kind of worker management (with share information)
i'll what i can do.

it could be that you need to keep the site open a while before it shows valid data...i just have to look at c00ws changes more closely (this evening...just working now) - if i understood him wrong and he made the worker managemant for pool workers i dont have any chance.

regarding: priorities: i thought about that also. wouldn't be that difficult. but not in the next version... maybe on saturday

Gern geschehen

as i rewrite the html stats page this evening anyway:

i could add an option to automatich switch all pools (except selected) to info/disable. as c00w made the possiblity to remember what it was (eg backup or mine_slush) i could also make a revert to defaults button.

if you have other suggestions i could make them too.

new version will be finished in about 15 hours from now (atm i am at work); c00w usually merge my html changes very fast

just klick the underlined text to edit it.

i will add this (together with role changes)
this evening

would be nice if everybody just take a look in the code before using it

but anyway: you should not use this fork.

i will not continue development
i'll integrate the stats graph in c00w's version later this evening
slice algorithm already available in another fork.

and c00w's a much better py dev than me

i'll add the stats graph this evening to c00w's version (still unsure if its gonna be a complete client-side approach [means graph data is only collected when browser is open] or if bitHopper itself send its data [means more traffic, more load])

(yes i changed the location, sorry. link ist http://<ip>/info

with pplns he is wrong.
he made the (wrong) assumption that the N in pplns means just N to round start. but with pplns some shares get double paid - which makes hopping useless.

score could be - i haven't dive into that yet

its a bad idea to use slush as a backup as many of your shares will go to hell.

i tried an approach of joining slush @300% and stay until they found a block. but it's just not working well - so i disabled it

not atm.
but on sunday i'll release my pool watch project which will print round-stats for as many pools as possible (even slush-a-like). it will be published as json, webservice and xml (which will all contain the same data) - and a field which tells the payout system they are using.

i won't make it advise any pool - thats your job. but there will be a site provide pool graphs and such things.

my hopper integration is atm very poor. its just a hopper restarter (with an 10secs delay before stopping the old one).

btw nofee blocks are easily detectable through mail (i always get the block found mail max 1min after they found a block).

what i think is curious about nofee:
with bithopper i get much more "pool downs" as with my miner. thats the reason i made an api for bithopper and switch my miner directly (there are still some pool downs and i still have a higher reject rate than usual (noofee is 5% atm for this round) - but its better as with the proxy). maybe they are trying to detect us and close the connection on a random basis - but i am not sure.

nice
could you also add my pool-stats graph? i use it for pool-fraud-detection - it really makes it a lot easier

i mean the blue line to the right (which is round shares per pool)

nice work.
could you also include my pool-round share graph from github? its very useful to detect pool fraud.
if you've done that, i'll switch to your version

maybe an invalid?

i didn't see any invalid block in their stats - and this one just disappeared. so it could be possible that they treat invalids just like longer rounds