Any reason off the top of your head why the tweak profile would be completely unresponsive? It mines the same without it and does not add a line (like in your video) "Applied Tweak Profile 5...." etc
Rig of vega 64's

{
"cryptonight_type" : "normalv4",
"intensity" : 0,
"tweak_profile" : 5,
"double_threads" : true,
}

Everything has been rock solid on the blockchain drivers. I'm not going to turn these systems upside down ATM to 'test'. Whatever you have done to try to squeeze more hash out of the cards was not done in testing the Blockchain driver. After a long time SRBMiner user, I guess I'll switch to XMR-Stack if the blockchain drivers are suddenly not being supported?

I don't know what to tell you.. but this is confirmed. I just went back to 1.6.2 and an immediate jump back to the normal hash on nano pool.

https://www.dropbox.com/s/n39hd08zwhwm85k/hash%20drop%20update%201.JPG?dl=0

SRBMiner in 1.6.2 (for this system, 8 cards)
https://www.dropbox.com/s/66l98fk97tnx41l/1.6.2.jpg?dl=0

SRBMiner in 1.6.4 (for this system, 8 cards)
(looks the same, but its just not getting the same share results)
https://www.dropbox.com/s/uky020294zdpbmz/1.6.4.jpg?dl=0

I'm getting a significant share drop on nanopool since upgrading to 1.6.4 from 1.6.2. Both machines doing the exact same thing

Everything appears normal within SRBMiner. Almost the exact hash numbers as 1.6.2. However, when I missed a payment, I went to investigate and I now realize my shares dropped by about 20-25%

https://www.dropbox.com/s/e76waamhah2dap1/hash%20drop.JPG?dl=0

----
Windows 10, blockchain with a bunch of Vega64's

Haven switch from Cryptonight Heavy next week to Cryptonight Haven (a slight variation on Heavy to shake Nice Hash influence). It would be nice to add this in now like you have with Stellite V4 so its ready to go at launch.

If you are using the default intensity... You are doing this all wrong. Learn how to optimize your rig..

RE: Awesome Miner
You will probably need to turn on Menu>Options>General> (Click) "Check for development versions"

Been emailing with Patrik at Awesome miner and he has added SRBMiner 1.5.1 to Awesome Miner now that it has an API.... which is .... emmm. Awesome!

It's not without some issues though. (Unless its operator error by me). I'm not sure if there are issues with the SRBMiner API or the Awesome Miner API implementation.
It seems to ignore the .bat file so you cant implement those triggers.
Also one of my 3 rigs is having huge communication issues which I cant figure out.. It shuts down then communication to Awesome Miner is totally lost until I restart both the awesome miner machine and the mining rig (restart the machine, not just the software)

Anyways.. Awesome miner implementation is a great happening. Now to just work out the bugs.

sweet.. This is currently the only problem in the autorestart chain

in my experience, I don't believe enable/disable undoes the under or overvolting, although I do perfer to do it after just to be sure.

I personally have Devcon autostart with windows.. Then OverdriveNTool start after it.

This feature of Devcon to start with SRBMiner will only become useful to me if we also add a restart miner on a drop below hashrate to monitor if the cards need to be enable/renable mid run.. 

Its not new to 1.5... but can you explain the kernel setting? I'm getting the periodic hang compiling kernel on GPU 1 (of an 8 card system).

"Some additional parameters you can use in gpu_conf:
"kernel" : 0-4 , IF 0, MINER WILL SELECT MOST SUITABLE KERNEL, OTHERS ARE : 1-FOR GCN CARDS, 2-FOR PRE-GCN CARDS, 3-FOR PRE-GCN EXPERIMENTAL 1, 4-FOR PRE-GCN EXPERIMENTAL 2"

I'm running Vega 64's. I don't know what GCN is referring to. Do I use setting 1?

Thanks

Ok still on 1.4.1 Yes I need to update, but via the changelog, I don't see any changes address this issue.

When I had the test Rig on 5 cards (Vega64) the 'reboot_script' system would kick in and reboot windows (10, 64b). All was good with the world. However I recently went to 8 cards in the system, now I'm getting a daily hang or 2 that does not restart. It just hangs and stays there. Something about the additional overhead not allowing it to advance realize its offline? I'm not sure..

I'm not sure what setting could be tweaked to make this more bulletproof.... Or what additional info I could provide you @doktor83?

Thanks

Thank you so much.

Figured out autostart of Devcon.exe and the start.bat with the blockchain driver.
Hashing at 2060-2070 on Vega 64s.
Auto reboots on fail and up and running automatically within 2 min.  

Rockin!

(Now just to play with tweaks on individual cards for less crashing)

I'm trying to use the individual GPU settings to change intensity for possible problem card, however, I can't get it to respond to the config file. It just responds to the topline (global) intensity of 120. If I delete that intensity line it just reverts to 0=auto. How do you get the individual GPU setting take president over the global settings?

also, I'm running blockchain driver. is this still optimal for this miner?

doktor83 loving the new miner! I'm still trying to automate the whole process. Running a stack of Vega's can be troublesome as we all know. Downtime kills everything. The new auto restart script is great but still having issues getting the miner to restart upon auto-reboot.

First off if I make a schedule to run "start.bat" or if I just include "start.bat" in the startup programs, it will not run automatically on windows 10.

"SRBMiner-CN.exe' is not recognized as an internal or external command,
operable program or batch file.

Waiting for  2 seconds, press CTRL+C to quit ..."

Thoughts on that?

Second, cards still need to be disabled/enabled to hash proberly. I know there is "JJs_Reset_n_Run_Tool" script. Is there a way to integrate that into SRBMiner or are you working on a way to automate this yourself?

Thanks for everything!
g