Thanks everyone for supporting me !

Every algo in the miner has its own devfee address, so for normalv7 its XMR, but from my calculations roughly 70% usage of SRBMiner is for heavy algo, probably because of Haven and Loki being the most profitable.
In the time i added heavy algo, the only coin was sumo, so that's why the devfee was on sumo.

Really thank you guys again!

of course watchdog must be enabled for this to work

yup, this is how it works.

Watchdog instead of trying to restart your miner after 3x45 sec of 0 hashing, runs the script you define, where you can kill the process, reboot windows, practically do anything you want in your script.

config.txt :

"reboot_script" : "reboot-windows.bat"

PS: pisem na engleskom sve zbog ostalih da bi i oni znali o cemu se radi i da ako neko naidje sa istim problemom da zna kako da resi.

Added a link in TIPS section on first page

Thanks for the tool 

Other miners have their own pools, where they do the devfee mining, but it would be too much to maintain those pools + work on the miner + work my 8-16h time job.
I have an idea how will i manage this without making own pools.

Regarding the stability thing, are you sure its related only to 1.5.8 ? There really isn't anything 'new' in that version that could cause GPU-Z crashing.

If some of you have older versions working better than the latest, i willl re-compile them all with the new devfee pool for heavy, and re-upload to mega.

Thanks for your support guys 

Version of miner?

From 1.5.5.1 there is a job_timeout parameter set to default of 15 minutes.
When no new job is received for 15 minutes it reconnects to your pool.

On your screenshot miner is not stuck AFTER the devfee, but BEFORE, there was a big pause before the devfee, which to admit looks interesting because miner did not freeze.
Logs of this would be interesting to see.

Also those file are not garbage, they are cached files, meant to speed up the compile process.

From the logs i can see that this isn't probably related to devfee-user pool switching, because after the devfee finished, you got jobs and accepted results from your pool, so the switchback was successful.

[2018-06-03 03:09:20] switch_pool: Disconnected from devfee pool, now mining for user
[2018-06-03 03:10:26] hashrate: GPU0: 964 H/S [BUS:5]
[2018-06-03 03:10:26] hashrate: GPU1: 1013 H/S [BUS:6]
[2018-06-03 03:10:26] hashrate: GPU2: 1017 H/S [BUS:2]
[2018-06-03 03:10:26] hashrate: GPU3: 964 H/S [BUS:4]
[2018-06-03 03:10:26] hashrate: GPU4: 952 H/S [BUS:1]
[2018-06-03 03:10:26] hashrate: Total: 4910 H/S
[2018-06-03 03:10:59] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"010193e4ccd805375fd1190a992e2b57929b47ae079a998a31bc7e1c11111a5a43e932b87519c20 0000000e510944a66dda1a13a8c31101b4cd678c25c109320e76a7936b82ff0fc10938201","job_id":"436392239714041","target":"d96f0000"}}
[2018-06-03 03:10:59] pool_have_job: Pool sent a new job (ID: 436392239714041)
[2018-06-03 03:11:09] miner_result: Sending user result to pool
[2018-06-03 03:11:09] json_send: {"method":"submit","params":{"id":"316536043444648","job_id":"436392239714041","nonce":"964033b3","result":"23e46068b4c15131a3d638b862f4988b4f810f82aa7b46a2d4cf0a91360b0000"},"id":1}
[2018-06-03 03:11:09] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[2018-06-03 03:11:09] miner_result: Pool accepted result 0x00000B36


also there are new jobs/accepted shares after this before the fun begins :

[2018-06-03 03:31:29] json_receive: {"id":1,"jsonrpc":"2.0","error":{"code":-1,"message":"Unauthenticated"}}
[2018-06-03 03:31:29] miner_result: You are not authenticated to the pool
[2018-06-03 03:31:29] miner_result: Pool rejected result 0x00003690 (unauthenticated)
[2018-06-03 03:31:29] miner_result: Network error
[2018-06-03 03:31:29] miner_result: Network error

The 0 hashing speed in this case is normal, because the GPU's are not working on any job.
This looks like some kind of pool problem to me.

That is nice, i only changed a few unrolls in cl in previous version that boosted my 580 8g only about 0.2-0.3%, looks like vegas like that even more 

If you set intensity in gpu_conf, the setting on top of the config will get disabled, so the one from gpu_conf will be used.

thank you, yes its enough if you were using one of the newer versions > 1.4.0

V1.5.8
- Fixed a bug in pool switching process
- Fixed a bug in watchdog's "reboot_script"
- Changed default devfee pool for Heavy algo

+ I would like to politely ask everyone if they appreciate my work, to switch their miners to this new version.

The default devfee pool for heavy algo was pool.sumokoin.com, which is under the control of the origin Sumo team.
They self-decided, without any community voting or anything to switch their algo back to now ASIC friendly Cryptonight from block 137500.
That will happen in about two days.
What this means to users of SRBMiner/Me ? On previous versions if you mine any coin on 'heavy' algo from monday, the devfee will connect to pool.sumokoin.com using 'heavy' algo,
but the pool will be using classic CN, so shares will be ALL rejected, and i won't be getting the 0.85% fee.


Thank you in advance, if you are going to support me and going to switch to this version.

how is that time is jumping :

16:56:39
17:03:33
16:57:40
16:57:17

after that is all good.

Have you turned on logging as i asked?

This is how it works :

Gpu gets a job to work on and returns results. Those results are then verified on the CPU, and if the CPU gets the same result as GPU did, that is a valid share and is sent to the pool.
If the GPU result isn't the same the result CPU got, that is a compute error, and that share won't be sent to the pool, because its not valid.

Compute errors can happen for a few reasons: bad timings, too much overclock/underclock, too high intensity.

yes i decided finally to put a virus into it, now is time to steal all your pictures from my documents

also version 1.5.6, 1.5.5 and so on

Kernel 1, that's for newer cards.
Also if you dont set it , it will be automatically set to 1.

Not there, you put it in gpu_conf :


"gpu_conf" :
[
   { "id" : 0, "intensity" : 80, "worksize" : 8, "threads" : 1, "kernel" : 1},
   { "id" : 1, "intensity" : 40, "worksize" : 8, "threads" : 2, "kernel" : 2},
   { "id" : 3, "intensity" : 30, "worksize" : 8, "threads" : 2, "kernel" : 3},
   { "id" : 4, "intensity" : 90, "worksize" : 8, "threads" : 1, "kernel" : 4}
]

What GPU's do you have?

nooo, they will fork next week, probably friday
So it's not that algo , yet.

it means you are using wrong algorithm. What are you trying to mine?