Those restarts are not necessary, but you can find out more / confirm that with output from cgminer-api. Basically, in your last example aka the Case B restart, cgminer has been restarted because no valid work was sent by cgminer for a certain duration, and in this case it is because the LVW is the same as that on the previous check. This may, in instaces, be due to cgminer not running (thus the need to restart it), but more likely be due to not finding any work at the minimum diff set by the pool you are mining on. I therefore think that is a buggy script in that sense, and since you are testing, I'd go as far as saying to you to completely disable that script, or at the very least remove the starts & stops in the script and just keep the logging and see what results you get.

PS. I am no expert at this, just my 2 cents...

PM me your BTC address - escrow (in PM) EDIT PayPal?

Assembled price each + shipping to UK?

try Dirty PCBs - they are dirt cheap!
@pinhead666 - are those the ones you used?

You did miss that .... I use the eu one but it kept failing over to the main url which I use as backup. Usually the software will keep checking the first pool for when it comes back online and reverts, in this case though, randomly, most of my rigs keep mining on the backup url (and it does not seem to be registering at the pool!). After 3+ hrs of this, I decided to point elsewhere until we can get some definitive info from slush.

This is getting ridiculous .... most of my rigs have fallen over to the main non-regional url i.e stratum+tcp://stratum.bitcoin.cz:3333 BUT they are not registering any significant hash on the site dashboard though they are running OK locally.
Also, the dashboard has gone bonkers .... block duration is forever in negative time, block do not register on the graph etc.. I better head of to facebook and see whether there is any news from the horse's mouth.

Seems like ... though just popped a block too!

EDIT: Seems like the regional nodes went down and (in my case) the main node accepted nothing at all (all stales). But yeah, most of my rigs too are showing a reduced hashrate because of the (continuing?) outage ....

Nope. 127.0.0.1 is the loopback IP for the rPi (and the rPi is also on the network). Leave it alone, just change the network IP to reflect your local network if you want to be able to access the bfgminer API from any computer connected locally to your network, ie in the network IP range. NOTE: the network IP has 3 places followed by /24 as opposed to the usual four.

And the last block 373469 is showing as orphaned on blockchain too ...

Nope, those are the IP's of the machines that can access the API; the first (127.0.0.1) is for the machine that bfgminer is running on, i.e if an rPi, then you can query the bfgminer API in an SSH window on the rPi and the second (i.e  the 192.168.1/24) is for, e.g your computer, more pertinently the network, where you'd want to access the bfgminer API from.

I thnk that will be hidapi

Yes they do have a chip between them .... and the latter miners with beaglebones' are not openwrt either .... but I suppose that'd make a start (and you'll get feedback) for a sturdier bfgminer driver in the long run.

Now that you got the BM1384 covered, any chance for other antminer support in openwrt?

Ridiculous! Not that BIP101/XT had any chance (in the current convoluted debate) over the swift sand that is BIP100, but that was not enough for the pig-headed majority.
This just brings to the fore the real need for a code fork. I am aware the core "team" may not all agree with the majority that are the DDoS instigators (and that won't be the first time they don't agree with the majority in the bitcoin community), but this has taken it too far.

Strange this ... had one of my miners with very old firmware kicked off port 3301 about an hour ago and it failed to get onto the backup port 3333 but its been hashing away nicely to .... I don't know where as there are no other pools but it's been showing a reduced hashrate for that time!

So yeah, seems the DDoS attack is still alive and kicking. Damn, we were on some good luck streak prior to these shenanigans.

Looks like its settled down now .... but yeah, would be nice to hear what (if any) the issue was. Really strange that as slush has always been a steady pool connection-wise.

Either slush fidgeting with the pool, AWS is having issues or pool is under attack.
Connections are very intermitent on port 3301 resulting in lots of stales when connection resumes .... I had port 3333 of the main stratum url as first backup but that on most of my rigs is now being reported as Dead ..... ! Nothing on FB yet either from slush ...

Was that a server outage? Seems like all my rigs were knocked off port 3301 and could not fail over to the standard port 3333.
And the pool hashrate also dropped to < 20PH from > 30PH. Does not make sense with the fabulous luck we've had last few days ....

Smack on the head there! 2 boards (even with fewer chips) in the same form-factor would be lower priced (though premiumed as per S7) and there would be a fair bit of demand for such, not just in the US, but in most temperate regions (even tropical!) from home miners.

Don't spam the thread, you nincompoop.
Find something to say about the S7, anything, even if you can not afford it. "It must be too loud" is a good excuse.