MultiMiner: Any Miner, Any Where, on Any Device (Free, Open Source, Cross Platform)

[atomicchaos]

Having an issue on a rig I'm just loading 1.16 on... (this one is the first 7950 rig I've tried it on)

Can't set he intensity to 20 or 19. Works fine if I set it to 13, but my 7950s need 19 or 20. Not sure if this was introduced when eliminating the spaces.

It states invalid value passed to set Intensity.

It shouldn't be anything on my side, as it does work if I use 13 in the argument.

[1713565732]

1713565732

[1713565732]

1713565732

[1713565732]

1713565732

[snowweb]

MultiMiner installed and ran, but during the startup wizard, I was informed that neither bfgminer or cgminer could be automatically downloaded for ubuntu and that I should obtain them from the providers website.

The problem is the bfgminer seems to have no downloadable package available that I can unzip into the specified folder. They only provide a ppa.

I installed the ppa and bfgminer using apt, but I don't think MultiMiner can see it (how will I know if it can?), since it's not in the specified directory, it's in /usr/bin/bfgminer.

What should I do? Maybe symbolically link '.../MultiMiner-1.1.16/Miners/bfgminer/' to '/usr/bin/bfgminer'?

Thanks and sorry if I'm the only one with these issues!

[nwoolls]

The problem is the bfgminer seems to have no downloadable package available that I can unzip into the specified folder. They only provide a ppa.

I installed the ppa and bfgminer using apt, but I don't think MultiMiner can see it (how will I know if it can?), since it's not in the specified directory, it's in /usr/bin/bfgminer.

That's fine. MultiMiner will see it in /usr/bin/bfgminer. Install bfgminer via apt get and then start MultiMiner under Mono. Go into Settings and select bfgminer as your engine and click OK. If it doesn't warn you that bfgminer isn't installed you should be good to go.

[nwoolls]

Can't set he intensity to 20 or 19. Works fine if I set it to 13, but my 7950s need 19 or 20. Not sure if this was introduced when eliminating the spaces.

It states invalid value passed to set Intensity.

It shouldn't be anything on my side, as it does work if I use 13 in the argument.

Can you please paste the executable and arguments in here, found either in the error dialog or the Process Log screen? I am running on -I 20 just fine. The only thing I eliminated spaces in was the Host parameter.

Unfortunately I need additional details - either screenshots or error texts etc. Additionally, once you have the executable and arguments you could try running that directly. It should have the same result.

[snowweb]

The problem is the bfgminer seems to have no downloadable package available that I can unzip into the specified folder. They only provide a ppa.

I installed the ppa and bfgminer using apt, but I don't think MultiMiner can see it (how will I know if it can?), since it's not in the specified directory, it's in /usr/bin/bfgminer.

That's fine. MultiMiner will see it in /usr/bin/bfgminer. Install bfgminer via apt get and then start MultiMiner under Mono. Go into Settings and select bfgminer as your engine and click OK. If it doesn't warn you that bfgminer isn't installed you should be good to go.

Got it now! You're the dude! Thanks.

[atomicchaos]

Can't set he intensity to 20 or 19. Works fine if I set it to 13, but my 7950s need 19 or 20. Not sure if this was introduced when eliminating the spaces.

It states invalid value passed to set Intensity.

It shouldn't be anything on my side, as it does work if I use 13 in the argument.

Can you please paste the executable and arguments in here, found either in the error dialog or the Process Log screen? I am running on -I 20 just fine. The only thing I eliminated spaces in was the Host parameter.

Unfortunately I need additional details - either screenshots or error texts etc. Additionally, once you have the executable and arguments you could try running that directly. It should have the same result.

Sorry for not supplying them initially...

Scrypt commands: -s 1 --expiry 10 --queue 0 --gpu-powertune 20 -g 1 --worksize 256 --lookup-gap 2 --thread-concurrency 16384 --vectors 1 --intensity 20 --failover-only



Again, if I change the 20 to a 13, it works, just half the hash rate.


Edit: it's not your app, as it happens at command line, no idea why cgminer that gets downloaded by the installer does it, but I will replace it with my own install.

Edit #2: I just looked and it most likely is the new version of CGMiner... Here's a note from the release:

- Limit intensity range according to whether scrypt is in use or not.

Maybe it's the order of the passing of commands, and if the Scrypt statement was first, it would work, will test.

[atomicchaos]

UPDATE: Fixed issue with intensity.. It's not really CGminer, although it has to do with a new update in the latest version released two days ago....

If the --Scrypt statement appears AFTER the --intensity, it will not allow above 13.

So, the temp fix now, is to put --Scrypt in my custom settings, which allowed it to work, and I think you'll just need to add that before the custom string in your app since CK changed it up a bit.

Thanks again for all your hard work!

[nwoolls]

UPDATE: Fixed issue with intensity.. It's not really CGminer, although it has to do with a new update in the latest version released two days ago....

If the --Scrypt statement appears AFTER the --intensity, it will not allow above 13.

So, the temp fix now, is to put --Scrypt in my custom settings, which allowed it to work, and I think you'll just need to add that before the custom string in your app since CK changed it up a bit.

Thanks again for all your hard work!

So just to make sure I have this correct I would/should pass --scrypt as the first argument to work around this issue?

[atomicchaos]

UPDATE: Fixed issue with intensity.. It's not really CGminer, although it has to do with a new update in the latest version released two days ago....

If the --Scrypt statement appears AFTER the --intensity, it will not allow above 13.

So, the temp fix now, is to put --Scrypt in my custom settings, which allowed it to work, and I think you'll just need to add that before the custom string in your app since CK changed it up a bit.

Thanks again for all your hard work!

So just to make sure I have this correct I would/should pass --scrypt as the first argument to work around this issue?

Yes, CK made a number of changes in this recent update, the first being that the --intensity statement checks to see if you are using --scrypt, and if the --Scrypt statement isn't passed before --Intensity, it will tell you that you have an invalid intensity above 13. I believe he is going to change that in the next version, as a few people have already complained, but until then, we would just need to add the --Scrypt statement to our Scrypt command string, unless you changed the order. Either way works for me.

They also changed the accepted blocks and rejected to be counted by the difficulty rate. So it is counting by 256 (instead of 1) for me, it goes by pool difficulty. I'm not sure if any other of these changes impact your tool, but I did notice that two of my machines that I loaded 1.16 on appeared to be hashing with no error, but when I checked my worker threads on my pool, they were at 0 kh/s. Still looking into why this happened, but am testing by just using 3.3.2 alone to see if it has the same issue.

[nwoolls]

Yes, CK made a number of changes in this recent update, the first being that the --intensity statement checks to see if you are using --scrypt, and if the --Scrypt statement isn't passed before --Intensity, it will tell you that you have an invalid intensity above 13. I believe he is going to change that in the next version, as a few people have already complained, but until then, we would just need to add the --Scrypt statement to our Scrypt command string, unless you changed the order. Either way works for me.

Thanks for confirming. I've got the change in there for future versions just to be safe. The --scrypt argument will always be passed first.

They also changed the accepted blocks and rejected to be counted by the difficulty rate. So it is counting by 256 (instead of 1) for me, it goes by pool difficulty. I'm not sure if any other of these changes impact your tool, but I did notice that two of my machines that I loaded 1.16 on appeared to be hashing with no error, but when I checked my worker threads on my pool, they were at 0 kh/s. Still looking into why this happened, but am testing by just using 3.3.2 alone to see if it has the same issue.

Please let me know what you find here. MultiMiner itself is pretty basic and just passing arguments to the miner executable, and then using the "devs" RPC API occasionally to get stats. If something changed I would assume it's either another command line argument change or a change to the way the "devs" RPC API reports things.

[atomicchaos]

Cgiminer had no issues running standalone, so I just switched back to using Multi-miner to see if it happens again.

Also, I just sent a small donation for all of your hard work!

[atomicchaos]

Please let me know what you find here. MultiMiner itself is pretty basic and just passing arguments to the miner executable, and then using the "devs" RPC API occasionally to get stats. If something changed I would assume it's either another command line argument change or a change to the way the "devs" RPC API reports things.

I can duplicate the issue every time on multiple machines. It appears to still be hashing without error, but my worker thread on my pool goes to zero. I guess something in the new version of CGMiner broke something?

I can't provide any errors, since there are none, the only troubleshooting step that I can think of is to replace the version of Cgminer in the multiminer folder and see if the same thing happens.

[nwoolls]

I can duplicate the issue every time on multiple machines. It appears to still be hashing without error, but my worker thread on my pool goes to zero. I guess something in the new version of CGMiner broke something?

I can't provide any errors, since there are none, the only troubleshooting step that I can think of is to replace the version of Cgminer in the multiminer folder and see if the same thing happens.

If you run the cgminer executable found in the Miners folder using the same arguments found on the Process Log tab, does that exhibit the same issues?

[atomicchaos]

I can duplicate the issue every time on multiple machines. It appears to still be hashing without error, but my worker thread on my pool goes to zero. I guess something in the new version of CGMiner broke something?

I can't provide any errors, since there are none, the only troubleshooting step that I can think of is to replace the version of Cgminer in the multiminer folder and see if the same thing happens.

If you run the cgminer executable found in the Miners folder using the same arguments found on the Process Log tab, does that exhibit the same issues?

I created a batch file with the same parameters, and it mined fine using the cgminer executable in the miners folder. I'm stumped. I see changes with the Utility parameter when the miner stops mining, and it just keeps decreasing based on the fact that it's not getting any more accepted. No error, no lockup, and I have no idea how to troubleshoot.

I haven't tried reverting to 3.2.1 yet in the Miner folder.

[nwoolls]

I created a batch file with the same parameters, and it mined fine using the cgminer executable in the miners folder. I'm stumped. I see changes with the Utility parameter when the miner stops mining, and it just keeps decreasing based on the fact that it's not getting any more accepted. No error, no lockup, and I have no idea how to troubleshoot.

I haven't tried reverting to 3.2.1 yet in the Miner folder.

Too, too weird. This is caused by my redirecting standard error from the process I launch. I did this in the latest version (or 2) in order to show better errors when the miner can't be launched. But by simple settings RedirectStandardError to true, after a while the mining process stops getting accepted shares. Very, very weird.

I'll get a fix in place soon. Thanks for your hard work in identifying this!

[atomicchaos]

I created a batch file with the same parameters, and it mined fine using the cgminer executable in the miners folder. I'm stumped. I see changes with the Utility parameter when the miner stops mining, and it just keeps decreasing based on the fact that it's not getting any more accepted. No error, no lockup, and I have no idea how to troubleshoot.

I haven't tried reverting to 3.2.1 yet in the Miner folder.

Too, too weird. This is caused by my redirecting standard error from the process I launch. I did this in the latest version (or 2) in order to show better errors when the miner can't be launched. But by simple settings RedirectStandardError to true, after a while the mining process stops getting accepted shares. Very, very weird.

I'll get a fix in place soon. Thanks for your hard work in identifying this!

That's great news that you were able to duplicate it, I found it odd that it impacted me alone on the only two rigs I updated to the latest version. Thank you!

Also, they have another update to Cgminer, and they have already fixed the --scrypt "intensity" issue, so regardless of whether or not you update, it should be a non-issue.

[nwoolls]

That's great news that you were able to duplicate it, I found it odd that it impacted me alone on the only two rigs I updated to the latest version. Thank you!

Absolutely my pleasure. I should have a new version up soon. A quick fix is just to not redirect output, but that also means not showing nice errors to users who have entered the wrong pool info. Trying to come up with a fix that addresses both.

Also, they have another update to Cgminer, and they have already fixed the --scrypt "intensity" issue, so regardless of whether or not you update, it should be a non-issue.

Nooooo I just updated my Homebrew and SH scripts to 3.3.2 today.  I guess it's time for 3.3.3.

[atomicchaos]

Nooooo I just updated my Homebrew and SH scripts to 3.3.2 today.  I guess it's time for 3.3.3.

I hear ya.. I have 22 rigs to update.

[nwoolls]

I hear ya.. I have 22 rigs to update.

That's a lot! FWIW I do plan on adding auto-updating of both MultiMiner and mining engines in the future. Need to finish off these MobileMiner apps first though.

[nwoolls]

Thanks again for the feedback and help in finding this issue atomicchaos. Version 1.1.17 is available now which resolves this, as well as a few other items:

• Fixed an error with the new History window when a coin goes missing from CoinChoose.com
• Pass in the --scrypt argument to miners first (in case cgminer breaks that again)
• Parse standard error output asynchronously to fix unresponsive miners
• In the Getting Started wizard, skip the downloading page / warning if the selected miner is already installed