[ANN] Miner Control 1.6.1 - Auto profit switching miner controller

[rafaeldelrey]

Would it be possible to let MinerControl start the most profitable GPU miner/pool AND the most profitable CPU miner/pool, both in the same MC instance?
There is no a lot of CPU miners out there.  I am starting xmr-stak-cpu manually, while MC runs.  I would like to have MC register its statistics, at least.

I have started in this altcoin mining stuff a couple of weeks ago.  I have been using NiceHashMiner and AwesomeMiner, but I felt they need some flexibility.  I am programmer and was thinking about starting such a project when I found this . I have some questions, which I could not find in the dozens of pages of this thread I have tried to search:
- Does MinerControl support dual miner, such as Claymore ETH+DCR/Pascal/Lbry?  If so, does it calculates if it is worth to run in dual mode?
- Is it possible to use cpu miners concurrently to gpu miners?  I am using xmr-stak-cpu.
- Should I fill the hashrate tables manually, or the program updates it as it runs algos?  I have 2x GTX 1070.  Should I input combined hashrates in those fields?
- Why there are partial conf files in the config directory? 

AFAIK:

1. Yes and no.  You could try using a special algo reference just for the dual hashrate,
2. Yes, you can run multiple copies each with its own configuration file.
3. The hashrate is fixed and manual; no dynamic updating or dynamic referencing.
4. They are just sample file templates.

[rafaeldelrey]

Could you add Brazilian Nicehash server (br.nicehash.com) on NiceHashService.cs (line 299)?

[fRegNone]

Looks good!  I like the separate wallet feature.  Some issues I've noticed with 1.7.0.5+:

Restart and switch no longer work after a certain period of time; stop also requires at least two stops to properly activate.  They may be related to tpruvot's 2.0 final ccminer.

The column sort for Net_$ doesn't work on double digits; to verify, sort by that column then sort again by Average.

Need a high price fix for the cyclical bug in pool software not taking into account difficulty decreases/increases on inactive/low hash rate coins.  It's most evident on Hashrefinery's X13 right now.

I'm also seeing identical values across the board for multi-coin, same algo mining at the same pool which doesn't seem right, e.g. Hush and Komodo at YIIMP and CXT, WYV and ECA at CoinMiners.

Me running against 1.7.0. Just to start with software, betas is not easy to jump in )

Confirm problem above with bold selection. I was even thinking its not bug, but some kind of profit making, *wink* to hashref folks, posted here short time ago.
Hashref Quark is now affected too.

Few things to look at:
Bin is outdated some in release package, i've got lots of googling to update it, still need to check few miners.
Dual is little bit pain to use, not clear how to include profit calculations from dual, pools api allow it?
Confirm "stop button works bad" with some miners.
Pools algos list is not full in basic conf, just note to newbies.
NiceHash is 4%, at least for most one rig folks, 0.1 btc needed in fixed period to get 3, right? Sure it's just matter of typing in conf.
Crypto XMR slows down my rig terrible, hard to use UI, nothing to be done, but maybe some1 can say why?
Pr/ExR column, Exr always N/A, do i miss something in conf?
Console, uff, it's so 80's unix style. All that jumps of cursor up and down, no way to scroll up w/o reset to current output.
I noticed u dont normalize strings before comparison in code. I think so, coz algo X11 is not same as x11.
If we gettin error before UI start, nothing in error.log, that hurts on attempts to understand whats wrong with conf parsing. Err dialogs helping little, stack trace much better.
Auto refreshing main price window works ....strange, after renew of table, selection can be on different row, comparing to what actually selected, playing with column sorting i do get it back. I feel that auto-resorting can be done upon current selected column sort, with column highlight, not always by average. Combination of row selection, column sorting and auto-refresh not native for human-being atm.

Summary: nothing critical, but few improvements can be done.

P.S. one small question more, priceid tags attached to nicehash in default conf, is it correct? ex. "pascal", "priceid": "25", but actual url is https://whattomine.com/coins/172.json or i miss something?

Cyдя пo кoмeнтaм кoммитoв мoжнo былo и пo pyccки )

[maxuscz]

Hi all. I use 1.7.0.5 and it worked cool. God bless you, Giraudy 

My question is about AcSpWrk

++++++++++++++++++++++++++++
Hashrate        |   AcSpWrk      | TopAvgSp
--------------------------------------------------
244,700.00    | 120,213.30      | 67,436.73
--------------------------------------------------
3,120.000.00 | 201,863.50    | 197,568.53
---------------------------------------------------
382,000.00    | 85,392.30      | 288,199.00
++++++++++++++++++++++++++++
   
If it low - it's mean stay away from this pool? For me yiimp pools showed only 25% AcSpWrk. Don know why 

[jkminkov]

how to setup etherium hashrate on clones, it has a different speed, cweight? with hashrate 18 cweight 0,9 do I get 16,20 or 20?

[Giraudy]

how to setup etherium hashrate on clones, it has a different speed, cweight? with hashrate 18 cweight 0,9 do I get 16,20 or 20?

Cweight affects the price only, it is soft modifier to prioritize coin on different pools (because with WTM prices and equal pool fees, the price will be the same) or convert hashes/megahashes to kilohashes, if pool suddenly decided to change the scale.

[Giraudy]

Beta 1.7.0.11 (cumulative update)

Link1:
https://drive.google.com/open?id=0Bz8-ln3QUcV4U3kzVXFzMUI0VUE

Link2:
https://mega.nz/#F!rhAFCbIa!F4XoHfIYoPYgJ-V1TUyP2A


beta 1.7.0.11

- added key "startdelay" in seconds allowing to update all prices properly, if auto-start enabled,
- balance calculation fixed,
- auto-switching failure in some cases fixed,
- application of manual "prices" and "exrate" fixed
- nicehash India and Brasil locations


beta 1.7.0.10

- added keys for enabling parsers for YIIMP-like pools
        "yiimpparser":false,
        "coinminersparser":false,
- added key for connection check by launch
        "checkconnection":false,

beta 1.7.0.9

-manual input with keys "price" and "exrate" at any pool,
-API from main Exchanges with rates
- column "workers" for viewing running workers from others rigs
- column "updated" for checking price update periods


eta 1.7.0.8

-compatability for two config types (old and with separated wallets)

beta 1.7.0.7

- separated wallets in config. Set coin tag name for wallets in pools section to substitute it from common list (samples in config).



Also there a last miners package there in a separate folder. Simply copy to "MinerControl.exe" folder.

[rafaeldelrey]

Have you ever compared the performance in long term of Miner Control vs NiceHash vs Awesome Miner?  All three tries to switch miners according to profitability.  My results for this week seems to show MC is way more profitable than the others, but I would like to make sure this isnt simply a lucky week.

Could you summarize the way MinerControl works.  As fair as I can suppose:

- Enumerate all pools and get/calculate current profitability for its algo/coins;
- Get exchange rate of all coins;
- With the inputed hashrate for each algos at conf file, calculate the pool+coin which will produce the most USD/day;
- Runs the miner most suitable for the previous step;

Does it consider, in any way, the real hashrate reported by the pool?  I have been using MC for a week, and it looks some reported hashrate (AcSpWrk or TopAvgSpd) are quite different than the one we calculate locally.  I have been adjusting the hashrates on minercontrol.conf according to these values.  Is this correct?

[Jaerin]

Have you ever compared the performance in long term of Miner Control vs NiceHash vs Awesome Miner?  All three tries to switch miners according to profitability.  My results for this week seems to show MC is way more profitable than the others, but I would like to make sure this isnt simply a lucky week.

Could you summarize the way MinerControl works.  As fair as I can suppose:

- Enumerate all pools and get/calculate current profitability for its algo/coins;
- Get exchange rate of all coins;
- With the inputed hashrate for each algos at conf file, calculate the pool+coin which will produce the most USD/day;
- Runs the miner most suitable for the previous step;

Does it consider, in any way, the real hashrate reported by the pool?  I have been using MC for a week, and it looks some reported hashrate (AcSpWrk or TopAvgSpd) are quite different than the one we calculate locally.  I have been adjusting the hashrates on minercontrol.conf according to these values.  Is this correct?

Those AcSpWrk as far as I know is coming directly from the worker output on the pools.  That is likely a more accurate result for that one pool, but it can fluctuate fairly dramatically based on your luck.  The hash rate you see locally is simply the number of hashes your card is checking, but not the actual amount of work that is accepted by the pools.  Over long term I would say the TopAvgSpd would eventually give a good best guess of the hashrates you can expect over time.  Luck will make some pretty big swings at times though.

Part of the issue with multi-ago/pool setups is going to be dependent on when the coin sales or exchanges really happen vs the value when you are mining the coin.  A coin may look very profitable when you mine it, but if the price tanks or you don't get it to the exchange and actually sell it the real returns may be very much different.  Overall though that is true of all coins you mine regardless of method.  I would say that miner control has the most potential for high returns because it checks many multiple pools and some pools may be operating better than others, but you still have to rely on those pools to pay out properly.  I would say that to get a good gauge of how it is doing you would need to look at averages over several weeks and see what is paying out the best and what is not.  It's not just as simple as pointing it to the most profitable coin on the most profitable pool this minute/hour/day because so many factors can change and you still have a lot of luck.

[maxuscz]

Have you ever compared the performance in long term of Miner Control vs NiceHash vs Awesome Miner?  All three tries to switch miners according to profitability.  My results for this week seems to show MC is way more profitable than the others, but I would like to make sure this isnt simply a lucky week.

Could you summarize the way MinerControl works.  As fair as I can suppose:

- Enumerate all pools and get/calculate current profitability for its algo/coins;
- Get exchange rate of all coins;
- With the inputed hashrate for each algos at conf file, calculate the pool+coin which will produce the most USD/day;
- Runs the miner most suitable for the previous step;

Does it consider, in any way, the real hashrate reported by the pool?  I have been using MC for a week, and it looks some reported hashrate (AcSpWrk or TopAvgSpd) are quite different than the one we calculate locally.  I have been adjusting the hashrates on minercontrol.conf according to these values.  Is this correct?

If MC show you miracle 10 usd from card - it is possible... Now you start to mine and see 50% accepted shares..so it is still 10 usd?
If you see 5 usd from card and you see 100% shares accepted but pool find less blocks today - how you can get this 5 usd from pool?

[rafaeldelrey]

Is there any updated list of the meaning of each parameter in the config file?  The first page is kind of outdated, isnt it?

[bohnhardt]

I'm trying to add a new pool for FeatherCoin (FTC) mining to my config file, but it seems to have problems to fetch the current exchange rate of FTC from the WTM json file. Price ID of FTC in the json is #8. The output however looks like this:

Code:

"exchange_rate":3.145e-05

It seems that MC has problems with that number format as i only get a price for FTC of 0,0000000 BTC...

[Jaerin]

The latest 1.7.0.12 version doesn't seem to be replacing the _ACCOUNT_ tag properly.

[Miner2525]

1.7.0.10+

[AL23]

Dose any one know where to get a ccminer for Bitcore (Timetravel)?

Thank you

[Fromage]

Dose any one know where to get a ccminer for Bitcore (Timetravel)?

Thank you

https://github.com/tpruvot/ccminer/releases

yw

[iamthecage]

Is there any simple fix for the pricing issues on the new Beta releases?

[MultiAlgoMiner]

I have a problem with IdleMining and minimize to tray:

IdleMining works fine if the windows is normal or minimized to taskbar (conf: traymode = 0).
But it doesn't work if the window is minimized to tray (traymode = 1 or traymode = 2): The miner is never started.

(Tested with Beta 1.7.0.13)

[Chapster]

Hello,

The calculation numbers have been screwed up ever since v1.7.0.13

I just downloaded v1.7.0.15 hoping for a fix and the numbers are still all messed up.

For instance, look at the Net_$ column on the following screenshot. This is with the same MinerControl.conf file that comes with the 7zip file you uploaded (meaning, no modifications at all).

With V1.7.0.13 I spent several hours trying to fix the numbers by lowering the hashrate dividing them by 1,000,000 and even so it had discrepancies between different pools.

[Jaerin]

I'm going to guess and say that it is a problem getting the nethash rate for those coins algorithms.  Which mean it isn't really able to estimate how much you are going to be able to earn through mining.  That's just a guess though.  The exchange rates seem to be correct, but there is no indication of how much you would be expected to mine in a 24 hour period listed.