Ok. I started 3 miners. 1 master and 2 slaves.
The slaves are working ok. The master is reporting that mining for block has finished. But its the same block over and over again
2014-09-07 04:08:52.499 INFO 3953 --- [taskScheduler-2] ish.burst.ms.services.MiningService : Stopped mining {f4eb42d8-d1e4-3676-8a3f-5f9879758ca6} due to block change.
2014-09-07 04:08:52.500 INFO 3953 --- [taskScheduler-2] ish.burst.ms.services.NetStateService : Could not fetch block data from pool
On the dashboard it displays the correct block and the generating hash. Also reporting how many time a plot was searched.
Is it something bad or does it run even with these problems?
edit: the plot file used by the master isn't finished yet if it matters
Also, mining official v2 pool. Not Urays pool
So the {f4eb42d8-d1e4-3676-8a3f-5f9879758ca6} is the plot file id that lines up with the UUID you see in the UI... in hindsight i probably should have just left its representation as the usual address_noncestart_number_stagger id.
If a new block is announced before it has finished scanning the plot it will tell you it stopping mining the plot.
The pool situation is a bit of a mess. Urays pool actually uses a completely different api and mining methodology, so currently the v1.1 jar only will mine urays. I am putting in some code to try and detect between the two types of pool, and switch mining modes accordingly. If you had built from source earlier today its probably running the official pool version code I had in there, but after some testing i found that it might not actually be getting any shares accepted by the pool, even if the pool is returning the success message, so I pulled that code, and left in Urays, which actually tells you if you are being rejected.
The burst pool scene is a little chaotic at the moment, so I hope everyone bears with the community as we all try and adjust.