[Minera v0.9.1] Your next mining dashboard - Antminer/CPUminer/CGminer/BFGminer

[tritiated]

I don't know if this is relevant since the 1.10a upgrade (I haven't upgraded yet), but I have a problem with 1.0.9. As outlined in a post above, I am using a method to address the devices by serial number - the /dev/serial/by-id/usb-STM...if00 method.

i.e. I added this manual option and removed autodetect:

--gc3355=/dev/serial/by-id/usb-STM...if00

If I use autotune with those settings, everything works beautifully. The tuning finishes after half a day-ish. However, when I save the frequencies they get saved in this format:

--gc3355-freq=/dev/usb-STM...if00:1195:4

You can notice the bug there. The path to the device should be /dev/serial/by-id/usb-STM...if00:1195:4, not /dev/usb-STM...if00:1195:4. To make it even more clear, the /dev needs to replaced by /dev/serial/by-id in the saved frequency output. I assume this is just a parsing/string splitting bug in Minera?

If I try to use the exact output from Minera in order to set frequencies the miner will start but won't crunch hashes. If I make the above replacment (find&replace) then things works well.

[kaltar]

When i do a save & restart on the setting page i get this erroe

A PHP Error was encountered

Severity: Warning

Message: file_put_contents(/var/www/minera/conf/miner_conf.json): failed to open stream: Permission denied

Filename: controllers/app.php

Line Number: 17

[michelem]

When i do a save & restart on the setting page i get this erroe

A PHP Error was encountered

Severity: Warning

Message: file_put_contents(/var/www/minera/conf/miner_conf.json): failed to open stream: Permission denied

Filename: controllers/app.php

Line Number: 17

Please run the upgrade script:

Code:

cd /var/www/minera
sudo ./upgrade_minera.sh

[Flep182]

Same problem here, use the newest version and the fix didn't help. When saving and restarting the miners it gives the same error as above.

[quakefiend420]

Same problem here, use the newest version and the fix didn't help. When saving and restarting the miners it gives the same error as above.

Same for me.

[michelem]

Same problem here, use the newest version and the fix didn't help. When saving and restarting the miners it gives the same error as above.

Same for me.

Code:

cd /var/www/minera
sudo chmod -R 777 conf

[michelem]

Same problem here, use the newest version and the fix didn't help. When saving and restarting the miners it gives the same error as above.

Same for me.

Code:

cd /var/www/minera
sudo chmod -R 777 conf

Sorry guy, just pushed a fix:

Code:

cd /var/www/minera
sudo git pull
sudo ./upgrade_minera.sh

This should fix save&restart issue

[Flep182]

Same problem here, use the newest version and the fix didn't help. When saving and restarting the miners it gives the same error as above.

Same for me.

Code:

cd /var/www/minera
sudo chmod -R 777 conf

Sorry guy, just pushed a fix:

Code:

cd /var/www/minera
sudo git pull
sudo ./upgrade_minera.sh

This should fix save&restart issue

Dude, you're good!

[LiteCoinRich]

Minera is great! Thank you

How long should I let auto tune run?

[quakefiend420]

Everything seems to be working great after the latest updates!

I am still losing a random blade about every hour or so, it just stops submitting shares.  Restarting the Minerd process brings it back until another one goes.    Any chance of being able to create a feature that will attempt a restart when a unit stops submitting shares after a certain amount of time?  I think you'd need to track the number of restarts so that if it doesn't bring the unit back you don't end up in a loop.  Other than that it "seems" fairly straightforward, but I'm no developer, just a hobbyist!

[SilentH]

Minera is great! Thank you

How long should I let auto tune run?

until it stops changing freq...  could take 2 hours could take 5 hours..

[kaltar]

after the last update autotuning doesn't seem to work, it doesn't change frequencies anymore, just stays at the starting on, even tough it says:
"gc3355-autotune": true,

in the json config file

[almond]

I´m sorry.

New Dashboard Error on v0.1.9

DataTables warning: table id=miner-table-details - Cannot reinitialise DataTable. For more information about this error, please see http://datatables.net/tn/3

I just got the same error on version 0.1.10a
I had installed minera for the first time on my five gs garden & it worked beautifuly for about a half hour. I stopped the miner & removed one of my gs ( ...to experiment with removing the fan; my gs's  have the 47k mod and have worked well with sandor's miners for two weeks...)
Upon repowering I got the DataTables error. The miner would start, but not hash. I stopped the miner, closed firefox ( ubuntu 64 system ) & started the miner manually, where things are working smoothly.

I'll work on this some more after lunch.....
wondering if, when I return that one gs to the system all will be well with minera ......?

LexMine: I would like to know the results of your experiment with disconnecting fans at 1200mhz as I am trying the same thing. I have read of others on this forum doing so with great success.  pm me please, since it'll take us off topic.

[toxic0n]

Loving Minera. Everything is working great now except one little thing:
My pool shows up as Alive even though the miner failed over to the backup pool. I can see what pool it's connected to via SSH though so it's not a huge deal 

[n00bminer]

Minera is great! Thank you

How long should I let auto tune run?

Until it stops.  Takes about 6 hours.  Make sure to enable debug so you can see if it has stopped "stepping" in the logs

[kaltar]

i just wanted to say OMFG you rock, i tried every rasberry image and Minera is THE BEST.

one quick question, on your rasberry image, ( i know i'm a newb when it comes to linux ) how do i change the
time zone to show the correct time on my minera web page.

thanks

You'll have to SSH into the device, and run "sudo raspi-config". That'll give you some options that you can change. Under Internationalisation Options should be where the time zone option is.

i did that and the rasberry keeps the proper time zone (i'm in the EST but Minera still shows GMT zone, any clue. ?

[quakefiend420]

Anyone trying to mine at BetaRigs with this distro?  Keep getting this error:

stratum_recv_line failed

when trying either of these two pools:

stratum+tcp://r3026.g63.rigs.eu.betarigs.com:6192
http://eu.betarigs.com:3333

No shares attempted at all...

These work just fine in my cgminer instances, but this is the first time I've used cpuminer.

EDIT: I enabled debug mode, but it didn't give me much more info...

https://i.imgur.com/qOENVdR.png

[SuperSeedlingMiner]

Hi,

new to using minera, which is pretty cool as ive tried scripta and hashra.

Just a question about the "alive" pools, I have one pool on betarigs (which is NOT active; yet shows as active) and one on wafflepool.

The miner only mines whatever is the first pool and shows both as active even if betarigs is offline.

Example

pool 1: betarigs > shown as active (reality is offline) >>> keeps sending shares and doesnt switch to secondary pool.
pool 2: waffle > shown as active (reality is active) >>> only works if i move this up into pool 1 position.

any advice on this?


Thank you.

also currently using version 0.1.10a
https://www.dropbox.com/s/m0fn0qgrq307s9x/minerd.jpg

[Jess85]

http://pastebin.com/dUZ1CXB9

real    0m0.326s
user    0m0.010s
sys     0m0.040s

Please can you pastebin me also the /var/log/minera/log-2014-05-18.php file?

http://pastebin.com/kUdZmeUn

Something else of note, I just had to bounce cpuminer, it stopped sending shares entirely.

Well, if you cannot see the dashboard stats within this config I think the problem could be related on how much time needs Minera to get the whole stats output. Probably it timeouts before getting everything and so you see {"error": true}.

I can say this because trying to inject directly your stats output into Minera works very fine, so the problem should be on getting it from minerd when there are so large output.

But now debugging this it's quite hard for me, you could do this:

* find the file: application/model/util_model.php
* at the beginning of the file you find the "callMinerd" function
* change it with this:

Code:

	// Call minerd to get the stats and retry before give up
	public function callMinerd($i = 0)
	{
		if(!($fp = @fsockopen("127.0.0.1", 4028, $errno, $errstr, 3)))
		{
			return array("error" => true, "msg" => $errstr);
		}
	
		stream_set_blocking($fp, false);
		
		$out = json_encode(array("get" => "stats"))."\n";
		
		fwrite($fp, $out);
		
		usleep(250000);
		
		$out = false;
		
		while(!feof($fp))
		{
		    if(!($str = fread($fp, 4096))) break;
		    $out .= $str;
		}

		fclose($fp);
			
		return json_decode($out);
	}

* save the file and retry the dashboard/stats page

Since version 0.1.10a this function is in application/model/cpuminer_model.php

Version 0.1.10a is out:

* bug fixes
* latest cpuminer
* added extra rc.local commands option
* added JSON conf

So for those of us running multiple G-Blades should we add that code or is it already included in the 0.1.10a update?
What should we do next to at least get the Minera stats working?

[quakefiend420]

Hi,

new to using minera, which is pretty cool as ive tried scripta and hashra.

Just a question about the "alive" pools, I have one pool on betarigs (which is NOT active; yet shows as active) and one on wafflepool.

The miner only mines whatever is the first pool and shows both as active even if betarigs is offline.

Example

pool 1: betarigs > shown as active (reality is offline) >>> keeps sending shares and doesnt switch to secondary pool.
pool 2: waffle > shown as active (reality is active) >>> only works if i move this up into pool 1 position.

any advice on this?


Thank you.

also currently using version 0.1.10a
https://www.dropbox.com/s/m0fn0qgrq307s9x/minerd.jpg

Can you turn on debug (Settings) and then look at the output from minerd?  I'm curious to see if you're getting the same thing I am on the betarigs pool...

SSH into the machine, log in with the minera account then run "screen -ls"  get the number of the session and then run "screen -r <number of the screen session>" with no <> and see if you get the same stratum_recv_line failed err that I'm getting.

When you're done you can hit Ctrl A then Ctrl D to exit the screen session and leave minerd running.