Topic: MultiMiner: Any Miner, Any Where, on Any Device (Free, Open Source, Cross Platform) - page 43. (Read 827303 times)

Here is something that probably happens to a lot of people and not just me:

Example: Coinwarz put somes coins on problem status for x reason for some days or some weeks, or remove a coin temporarily and put it back some weeks or months later. So you react and put those coins "disable" in your list. You told yourself "I will put them back on enabled status later when all is fine". 2 or 3 days later, some other coins get problems too. You disable them too. Now fast forward another week (or month): You remember you disabled some coins some time ago that should be fine now but you don't remember all of them and you end up clicking one by one all your coins in your list to see which one is disabled or not.

It happened to me more times than i can count and my list has grown over the course of time to be close to 150 coins. That takes a long time to click each of them just to verify if it is "disabled".

So here is my suggestion: Would it be possible to put some kind of mark in the list that instantly show which one is "disabled" or not. Something like those disabled become marked in red, or get a red asterisk added or anything that would instantly jump on your eyes in the list to tell you which one is "disabled". I think that would really help to do the management of the coins list.

The x64 build of BFGMiner for Windows doesn't include Stratum Proxy support, so I have to use the x86 version for that.

You don't need to restart the program but do need to restart mining. It's just the process priority assigned by the OS. It really shouldn't matter much, but I have a couple users who get better performance if they set it above normal.

I was talking about all the other miners as well. Perhaps when you're mining the coin itself. There is a lot of overlap for what miners you can use to mine coins and it's entirely possible to mine coins on different machines without noticing you're using the wrong miner.

3.1.0 work's fine Thank you Nate!! But why BFGMINER is x32, or it's doesn't matter?

Does anyone know what the best setting is under settings, miner, priority (assuming I want to optimize my miners)?

Is Real-time better then High for example? The list shows 'normal' at the top of the list, real-time in the middle somewhere, and 'above-normal at the bottom just below 'below-normal'  

Also, does the program need to be restarted for this setting change to take effect?

thanks

And now with more infos 



https://www.dropbox.com/s/nmy0vlhhpje5iw0/MultiMiner-3.1.0.zip

Thanks Nate
I will give these a try and get the info out the device manager and see what I can do.   

I only have a couple of IceFuries (NF1) and a NanoFury2 stick. Both of these use the standard Windows HID driver and required no driver installation.

I'm not sure on the OneString miner. If it uses the Windows CDC driver, you may need to create a custom INF for it. You can check out these existing ones for a reference:

https://www.dropbox.com/s/w06b7nj1f07lv29/Windows_ASIC_CDC_Drivers.zip

The only real differences in the INF files are the PIDs and VIDs which you can get out of the Device Manager in Windows, along with the Strings section at the bottom (which doesn't matter - just name the device).

any idea which drivers to use for the onestring miners and yellow jacket?
I am having issues with the yellow jacket as it is a nano fury.  One sting I just want to load the correct set then use the arguments you had posted for them to work well.

Click the About button in the upper-right: it shows both.

Yeah..maybe just add the Version # next to MultiMiner in the title bar??

Please add a display option for what miner and version MM is using.

It's planned  Some day!

You can specify pre-releases using semantic versioning and Github Releases can be flagged as pre-releases, so at some point I can start posting these as tagged releases on there and introduce "channels" in the UI.

You should run MM with two release channels.  Add two options:
□ Notify on release versions
□ Notify on beta versions

Another preview of 3.1 is available for testing:

https://www.dropbox.com/s/nmy0vlhhpje5iw0/MultiMiner-3.1.0.zip

This includes better support for recognizing multiple algorithms throughout the UI. In 3.0, "unknown" algorithms are grouped under Scrypt or SHA, for instance in the hashrate totals. With this preview those hashrates are called out specifically:

I had updated on one of the 2 2.8 systems and I did not think and ok'd the push to the other systems and it updated the 3.0 one as well.  Sorry I was not a bit more clear.  I was surprised but at the same time was not used to having the 3rd system yet. LOL

Interesting - 3.0 should not prompt to upgrade to 2.8. I haven't seen that or heard that reported, but I will sure test it.

The rest is to be expected, unfortunately. The sordid details:

Both version 2.8.9 and 3.0 were released with code that will prevent them from notifying of "major" updates, e.g. v2 to v3. I released 2.8.10 afterward so that those on 2.8 would get major updates. Unfortunately though, folks on 2.8 (even 2.8.10) will not be prompted to update to 3.0 - for now. That is because 2.8.10 is technically the "latest" build.

Once I release 3.0.2, that will be the "latest" release and folks who are on 2.8.10 will be prompted to update. However, at that point folks on 2.8.9 won't see 2.8.10 as a viable upgrade anymore, so I don't want to pull the trigger on the update too soon. I'm watching installed version numbers and will do it when it makes sense.

It's a bit of a mess, I know, but it only affects the auto-update notification. Folks can still manually update.

And I tested the original scenario while typing this - I can't seem to see an instance of 3.0 prompting to upgrade to 2.8.

Quick note.
My rigs updated to the 2.8 update and none of them are updating to 3.0.
The rig that was on 3.0 updated to 2.8 and I lost my coin configs in it.  Just odd.  I was not expecting that one to update when it was already on 3.0.
I hope it helps with anything going.

In a nutshell, MultiMiner is launching the executable found on the Process Log screen (available from right-click) with the arguments found there too. There's nothing beyond that MultiMiner is doing. That needs to be the starting point for diagnosing the differences you are seeing.

FWIW I see this problem too if I use DarkcoinSGMiner but SPHSGMiner seems to work better.

I've also seen the "all pools appear to be down" if the right algorithm arguments aren't being passed to the backend miner.


This is a bug that is fixed for 3.0.2, which will be going out pretty soon. Happens when you use Quick Switch.

Edit: it's fixed in the 3.1 preview I linked previously too.


Same response as up above - please start with the Process Log screen in MultiMiner. MultiMiner is "simply" launching the executable you see there with the arguments you see there. If you stop mining in MultiMiner, you can right-click in the Process Log and click Launch to start the miner directly.

Please use this to compare performance and see what it is specifically causing the difference you are seeing.

If you are seeing different performance simply by clicking the Launch button in MultiMiner specifically, please let me know the executable and arguments.

Thanks very much for the feedback - keep it coming!