I would be really happy if someone could help me solve this error: Undefined index: MHS 5s
http://i.imgur.com/Kc8cw8b.jpg
Topic: ANUBIS - a CGMINER Web Frontend - page 4. (Read 83181 times)
Is the email used for something ?
With the new version of cgminer 3.8.3 I get only zeroes:
You need 3.8.4 since I'd guess that anubis uses json (no idea why) and there was a bug in 3.8.3 that killed accepting json in the APICode:
0/0 0 0.00
()
0 %
0 %
Plain text works fine.
I never use json in the API - I only added it in the original API when I wrote it as an after thought - only one of the people who donated for the API wanted json - and even he only asked for it at the very end after the code was done.
That was it.
Thanks for the fast reply
With the new version of cgminer 3.8.3 I get only zeroes:
You need 3.8.4 since I'd guess that anubis uses json (no idea why) and there was a bug in 3.8.3 that killed accepting json in the APICode:
0/0 0 0.00
()
0 %
0 %
Plain text works fine.
I never use json in the API - I only added it in the original API when I wrote it as an after thought - only one of the people who donated for the API wanted json - and even he only asked for it at the very end after the code was done.
With the new version of cgminer 3.8.3 I get only zeroes:
Code:
0/0 0 0.00
()
0 %
0 %
Thanks for your help P_Shep much appreciated.
I hope to see Anubis running on my network soon!
much appreciated. I hope to see Anubis running on my network soon!
You don't need to create the DB manually, but yeah, you can use MySQL if it works better.
Hi, i'm trying to get Anubis running on a BeagleBoneBlack using Debian os, my ultimate goal is to get it working on my KnC miner. I've used sqlite for the db edited the config.ini.php appropriately and made a db called Anubis_db in sqlite
I'm stuck here
FATAL: Cannot use Anubis_db ! SQLSTATE[HY000] [14] unable to open database file
should i just give up and switch to mysql?
I'm stuck here
FATAL: Cannot use Anubis_db ! SQLSTATE[HY000] [14] unable to open database file
should i just give up and switch to mysql?
Sorry, fixed it.
Same problem here, extra comma at the end of line 23 of configtbl.sql.php
Love the interface.
However, I spent the better part of an hour trying to get it up and running. Turns out that there was an extra comma in the table creation code causing it to block. Fixed it, hopefully no one else will run into that problem.
However, I spent the better part of an hour trying to get it up and running. Turns out that there was an extra comma in the table creation code causing it to block. Fixed it, hopefully no one else will run into that problem.
What changes have been made for ASICs? Changelog wasn't updated?
Support for "ASC" device type returned from cgminer API. I added it a couple months ago, pshep might have had to clean it up a bit.
Oh, I didn't even see the pull requests! I did it myself... could have saved my time!
And they're almost identical!
Whoops, should have sent you a message, sorry. Had to see my jally!
What changes have been made for ASICs? Changelog wasn't updated?
Support for "ASC" device type returned from cgminer API. I added it a couple months ago, pshep might have had to clean it up a bit.
Oh, I didn't even see the pull requests! I did it myself... could have saved my time!
And they're almost identical!
What changes have been made for ASICs? Changelog wasn't updated?
Support for "ASC" device type returned from cgminer API. I added it a couple months ago, pshep might have had to clean it up a bit.
What changes have been made for ASICs? Changelog wasn't updated?
Looks interesting. I will give it a try in the evening :-)
I wonder though if this is still maintained since the last commits are a couple of months old.
I wonder though if this is still maintained since the last commits are a couple of months old.
Any thoughts on why Anubis is reporting "'An existing connection was forcibly closed by the remote host" for one of my connections? I have all my systems running in a private network, no firewalls on 192.168.137.x with default 4028 API port. They have a gateway out but not relevant for this part of the setup as everything talks internally. Have the following in my cgminer.conf:
"api-listen" : true,
"api-allow" : "W:192.168.137.0/24,127.0.0.1",
"api-port" : "4028"
Anubis is running on a computer within the 192.168.137 network as 192.168.137.1
And note since I read it here. I am mining scrypt currencies and wouldnt think that makes a difference if cgminer works on the API port but who knows. I know cgwatcher is working local.
Thoughts?
"api-listen" : true,
"api-allow" : "W:192.168.137.0/24,127.0.0.1",
"api-port" : "4028"
Anubis is running on a computer within the 192.168.137 network as 192.168.137.1
And note since I read it here. I am mining scrypt currencies and wouldnt think that makes a difference if cgminer works on the API port but who knows. I know cgwatcher is working local.
Thoughts?
This might be a CGWatcher bug. It causes the api-allow to be overwritten and is fixed in the next update (available tomorrow/today... August
. More info from CGWatcher newbie thread from someone reporting a similar problem... https://bitcointalksearch.org/topic/m.3073090It's not that CGWatcher takes "priority", as normally there is no problem using other API-monitoring applications while CGWatcher is running. But there was a problem with recent versions of CGWatcher not enabling the API correctly. This is fixed in 1.3.1, which will be available shortly (today or tomorrow).
Until then, there is a workaround that should prevent this. You just have to make sure that you enable the API in arguments, and include 127.0.0.1 in the full privilege group (W:).
So in the profile arguments, make sure there is a setting: --api-allow W:127.0.0.1
Because of the bug, this has to be done in arguments because the arguments api-allow option will override the config file api-allow option (if one is used). Once CGWatcher sees that 127.0.0.1 is already included in the W: group, it should leave the setting untouched.
In 1.3.1, this is corrected and the code for checking if the API is enabled and enabling it is now a little smarter.
Until then, there is a workaround that should prevent this. You just have to make sure that you enable the API in arguments, and include 127.0.0.1 in the full privilege group (W:).
So in the profile arguments, make sure there is a setting: --api-allow W:127.0.0.1
Because of the bug, this has to be done in arguments because the arguments api-allow option will override the config file api-allow option (if one is used). Once CGWatcher sees that 127.0.0.1 is already included in the W: group, it should leave the setting untouched.
In 1.3.1, this is corrected and the code for checking if the API is enabled and enabling it is now a little smarter.
Any thoughts on why Anubis is reporting "'An existing connection was forcibly closed by the remote host" for one of my connections? I have all my systems running in a private network, no firewalls on 192.168.137.x with default 4028 API port. They have a gateway out but not relevant for this part of the setup as everything talks internally. Have the following in my cgminer.conf:
"api-listen" : true,
"api-allow" : "W:192.168.137.0/24,127.0.0.1",
"api-port" : "4028"
Anubis is running on a computer within the 192.168.137 network as 192.168.137.1
And note since I read it here. I am mining scrypt currencies and wouldnt think that makes a difference if cgminer works on the API port but who knows. I know cgwatcher is working local.
Thoughts?
"api-listen" : true,
"api-allow" : "W:192.168.137.0/24,127.0.0.1",
"api-port" : "4028"
Anubis is running on a computer within the 192.168.137 network as 192.168.137.1
And note since I read it here. I am mining scrypt currencies and wouldnt think that makes a difference if cgminer works on the API port but who knows. I know cgwatcher is working local.
Thoughts?
Jump to: