The official MacMiner thread [BTC/LTC-CPU/GPU/FPGA/ASIC]

[XFox]

MacMiner 1.4.16 is now out

The web page download link still points to 1.4.15.

[Anonymailer]

MacMiner 1.4.16 is now out

The web page download link still points to 1.4.15.

Whoops, thanks for pointing that out, I've changed it now!

[inevertell]

So, does MacMiner run without a hitch on Mavericks? I don't want to upgrade until I know forsure. Its my only essential app:)

[Anonymailer]

So, does MacMiner run without a hitch on Mavericks? I don't want to upgrade until I know forsure. Its my only essential app:)

Hehe that's nice to hear! I upgraded a MBP and MacMiner 1.4.16 is running fine

However, there's a problem witih 1.4.16 (or more specifically bfgminer 3.3.0) which prevents GPU mining - this is on any OS release and cgminer still works for the GPU, so I'll be asking luke-jr about this and hopefully it'll be sorted out soon - anyone who wants it can get 1.4.15 here:

http://fabulouspanda.co.uk/macminer/downloads/MacMiner.app-1.4.15.zip

1.4.16 is still recommended for FPGA/ASIC mining

[jedimstr]

So, does MacMiner run without a hitch on Mavericks? I don't want to upgrade until I know forsure. Its my only essential app:)

Hehe that's nice to hear! I upgraded a MBP and MacMiner 1.4.16 is running fine

However, there's a problem witih 1.4.16 (or more specifically bfgminer 3.3.0) which prevents GPU mining - this is on any OS release and cgminer still works for the GPU, so I'll be asking luke-jr about this and hopefully it'll be sorted out soon - anyone who wants it can get 1.4.15 here:

http://fabulouspanda.co.uk/macminer/downloads/MacMiner.app-1.4.15.zip

1.4.16 is still recommended for FPGA/ASIC mining

Not a bug, a feature

Latest BFGMiner has GPU disabled by default now when you have ASICs or FPGAs detected.   To enable you have to set -S opencl:auto

Luke-Jr has this listed in the change log for 3.3.0 here: https://bitcointalk.org/?topic=168174.msg3322357#msg3322357

[inevertell]

So, does MacMiner run without a hitch on Mavericks? I don't want to upgrade until I know forsure. Its my only essential app:)

Hehe that's nice to hear! I upgraded a MBP and MacMiner 1.4.16 is running fine

However, there's a problem witih 1.4.16 (or more specifically bfgminer 3.3.0) which prevents GPU mining - this is on any OS release and cgminer still works for the GPU, so I'll be asking luke-jr about this and hopefully it'll be sorted out soon - anyone who wants it can get 1.4.15 here:

http://fabulouspanda.co.uk/macminer/downloads/MacMiner.app-1.4.15.zip

1.4.16 is still recommended for FPGA/ASIC mining

ASIC here so all fine. I'll upgrade tomorrow .. Seems no major bugs are reported for my hardware ...
I'm on a Mac Pro so I'll let you know if there's any problems !

[Anonymailer]

Ah, I of all people should have guessed to check there, thanks jedimstr!

I've tested BFL hardware with the FTDI drivers that say OS .4-.7 support with bfgminer/MacMiner on 10.9 and it all works as expected I'm pleased to say

[alex0909]

Good evening,
Trying to mine with my block erupter without using my gpu, even if i did check the "disable gpu" it does not disable it.

Only way for it to work is with cgminer, but i get "AMU0: TIMEOUT GetResults took 2000ms but was 100ms"  all the time, and only a few shares get accepted (i am not mining bitcoin).

If you have any idea please let me know.

[BrandonMcPherson]

I posted this in the Newbie thread, but now that I have posting privileges here...

I'm running MacMiner 4.16 (build 1416) in Mavericks (10.9). After 20-30 minutes of use using the FPGA/ASIC window to  run USB Block Erupters, MacMiner starts spawning "apiaccess" processes one after the other ever few seconds. Those processes build up until I run into the default process limitation on my machine (currently 709). That means I have roughly 500 of these apiaccess processes running.

They're persistent until I quit MacMiner.

I have rebooted several times, and I also trashed my MacMiner .plist and the MacMiner folder in User>Library>Application Support. After doing so, I rebooted and then reinstalled MacMiner. The behavior resumed, the same as before.

I noticed this in the first place because my system was refusing to spawn new processes after running MacMiner for the above-mentioned 20-30 minutes. As of yesterday, while MacMiner is still spawning hundreds of these processes until it hits the max, it's not leaving my system unresponsive.

[Anonymailer]

Good evening,
Trying to mine with my block erupter without using my gpu, even if i did check the "disable gpu" it does not disable it.

Only way for it to work is with cgminer, but i get "AMU0: TIMEOUT GetResults took 2000ms but was 100ms"  all the time, and only a few shares get accepted (i am not mining bitcoin).

If you have any idea please let me know.

If it works with cgminer but not bfgminer it must mean you don't have the usb drivers installed:

http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx

I posted this in the Newbie thread, but now that I have posting privileges here...

I'm running MacMiner 4.16 (build 1416) in Mavericks (10.9). After 20-30 minutes of use using the FPGA/ASIC window to  run USB Block Erupters, MacMiner starts spawning "apiaccess" processes one after the other ever few seconds. Those processes build up until I run into the default process limitation on my machine (currently 709). That means I have roughly 500 of these apiaccess processes running.

They're persistent until I quit MacMiner.

I have rebooted several times, and I also trashed my MacMiner .plist and the MacMiner folder in User>Library>Application Support. After doing so, I rebooted and then reinstalled MacMiner. The behavior resumed, the same as before.

I noticed this in the first place because my system was refusing to spawn new processes after running MacMiner for the above-mentioned 20-30 minutes. As of yesterday, while MacMiner is still spawning hundreds of these processes until it hits the max, it's not leaving my system unresponsive.

Thank you for the report, I'll look in to this right away. I don't see the issue on 10.8 but I'll check 10.9 now. Can I ask whether another process, perhaps another instance of bfg or cgminer might be using port 4028?

[BrandonMcPherson]

Let me figure out how to figure that out.

[alex0909]

Yes, did not know i had to install the drivers. It was working without it

I installed them and it now works perfectly, thanks!

[BrandonMcPherson]

A followup: I am not experiencing this process spawning on another Mac running Mavericks. I think the problem I reported above is a problem with my system—I had some other wonkiness happening, too.  I'm doing a reinstall now, but wanted to drop a note since you are looking into it.

I should have checked my other Mac before posting!

In any event, I'll report back when my reinstall is complete.

*****************

I followed up too soon: after a system reinstall, I am still seeing this processes spawn uncontrollably.

[BrandonMcPherson]

According to:

sudo lsof -i :4028

only bfgminer and many instances of apiaccess (both process types owned by MacMiner) are using port 4028.

Here's a sample:

bfgminer  3482 [name]   12u  IPv4 0xc93b259907385621      0t0  TCP *:dtserver-port (LISTEN)
apiaccess 4837 [name]    3u  IPv4 0xc93b2599086aee09      0t0  TCP localhost:53403->localhost:dtserver-port (CLOSE_WAIT)

[Anonymailer]

Thanks for the report back, what are the differences between the setup that doesn't have this problem and the one that does? I didn't see the problem yet but I'm assuming something is going wrong while it's trying to access the api data and the process is hanging so I'll look that over and write in a failover to prevent this from happening in the future. Sorry for the trouble in the meantime!

[BrandonMcPherson]

No worries on the trouble! Kind of the opposite—I'm sorry for the trouble and appreciate you looking into it.

Differences: the machine where it happens is a Mac Pro (early 2008). I'm running 30 BEs on four hubs. Tons of other apps open, but I have plenty of RAM.

The other unit is a MacBook Air (mid 2011). I only run a subset of the BEs when I tested it—14 of them on two hubs. It has a lot less RAM, and therefor I have few apps running.

The biggest difference is the specific hardware of the units and the number of BEs I was running. I'd test all of them on the Air, but it won't recognize more than about 18.

[BrandonMcPherson]

Hey BitBacco, is there any other data or information I can pass on for this issue? I'd be happy to play guinea pig, too.

[Anonymailer]

Hey BitBacco, is there any other data or information I can pass on for this issue? I'd be happy to play guinea pig, too.

Thanks for your help, sorry I just haven't had time to do the update yet, it would be helpful to know however, if you could keep the api output window open - does the information freeze or change at the point that the apiaccess processes become a problem and if so how?

[BrandonMcPherson]

None of the MacMiner interfaces freeze. I'm using the FPGA/ASIC Miner window for these BEs, and it continues to spit out new output even when I can't launch new processes elsewhere (open a window, reload a webpage, launch an app, etc.)

As soon as i  stop the miner and quit MacMiner, all those bonus apiaccess threads disappear and I can launch new processes (and any that i tried to launch while it was maxed out launch, too). I can then relaunch MacMiner and start the cycle all over.

If console logs or other output will assist, let me know.

And thanks again for looking into this. It's very much appreciated.

[Anonymailer]

None of the MacMiner interfaces freeze. I'm using the FPGA/ASIC Miner window for these BEs, and it continues to spit out new output even when I can't launch new processes elsewhere (open a window, reload a webpage, launch an app, etc.)

As soon as i  stop the miner and quit MacMiner, all those bonus apiaccess threads disappear and I can launch new processes (and any that i tried to launch while it was maxed out launch, too). I can then relaunch MacMiner and start the cycle all over.

If console logs or other output will assist, let me know.

And thanks again for looking into this. It's very much appreciated.

I'm surprised the API Output window continues to update data, the apiaccess process should only be run swiftly for a single data retrieval operation then stopping, so it launches a new one every few seconds…

1.4.17 has just been released and should fix this issue, please let me know!