I continue to investigate and I see that the failure I am communicating only occurs with cryptodredge. It has nothing to do with what other users have told me.
If I use CryptoDredge as in the videos of yesterday, you will see that it changes currency without resetting the miner, that disconcerted me. Today I have done the test again and it does, I have changed to Klaust, and when it changes currency, the miner restarts and all the correct data, as it should be.
So some smart people who give advice quickly and without wanting to go into detail, are WRONG, apart from arrogant.
The fault is in the api of cryptodredge, that to change currency within phi-phi-pool does not restart, and with klaust if it does.
I hope that with all this information, you Patrike will be able to reproduce the problem and fix it.
One more error that will be fixed for the community, thanks to the insistence of a user who also looks "persecuted" by some iluminati. That's why I'm only interested in talking to the programmer, and not with self-proclaimed experts, who do not see beyond their pride.
AT THE END IT WAS A FAULT !!!!!!!
I also just tried it with the rare fork of hsrminer that has api, and also works correctly, resetting the miner and showing correct numbers.
I apologize and admit that I definitely jump to conclusion overly hasty, without going through your videos in detail. However, after going through these videos several times (no, they don't really provide much helpful info as they are shot through limited perspective, they show symptoms, but no background info on user setups). My humble conclusion is that it likely is still due to over-complicated user setup, or corrupt/conflicted AM settings.
Of course, it could be that the API implementation of CD causing the stat display confusion. Did you check the exact command parsed to the miner at the time it was doing the abrupt coin switch through task manager?
Also, in your video #1 @ 2:20, it shows you have way complicated pool setups, it show some pool coins @ BSOD.pw and AngryPool defined as BTC (icon), these pools are not Auto Exchange Pools and doesn't pay in BTC, these confusing configuration might have caused AM to read the incorrect profit data and hence, erratic switching behaviours. The complication has nothing to do with number of pools in a pool group, but how they are setup. my pool groups have almost 100 pools, and never did I notice such behaviour. Trust me, I stay in front of computer no less than you and TBH, I reckon that's some mental obsession that should be corrected, time should be better spent elsewhere.
You spent so much effort going into (unnecessary fussy) detail on how to get the most profit out of your rigs, to every single cent (or satoshi?) from profit switching, but got the fundamentals completely wrong (The way I understands it).
Don't mine specific coins on a Yiimp shared port. Here's the reason why:AM is setup to prioritize based on profitability on coins specified in the below pool settings and it's been mining GBX all the time tested.
As one can see, mining on shared port even with c=XXX specified doesn't do anything, it still forces you to mine all blockchains from the pool that uses that shared port. Now if one has logical thinking, then you are definitely not mining the most profitable coin even when your software is setup and thought it was. This
switch coins without restarting mining software is exactly what you didn't want yet you are able to reproduce it on user end in your AM. Where I was able to reproduce it on pool side whenever I want it and knows to avoid since I (think I) understood the basic mechanics.
And no, with 3 hours mining on phi-phi-pool's Neoscrypt port and using CryptoDredge, I don't even see it blink to a different coin at all. Not even during DevFee session, some miners do that during DevFee, such as coolminer goes to angrypool and CryptoGen mines LUX (which really stuffs up AM's profitability sometimes since it displays LUX's profitability and hashrate yet AM internally is monitoring the performance based on the profit profile and can cause profit / hashrate rules to trigger unwantedly), I do not deny that from the video, you are experiencing the symptom which is very real and you are bothered by it, but you didn't quite seem to provide enough useful information on your relevant setups, which so far we knew it was overly complicated and fundamentally unconventional. Such as gauging profitability per coin per algo based on poolside hashrate (5min avg, Yiimp default) and introducing far more factors that are totally out of your control.
You introduced the following factors out of your control just to name a few:
- Specific coins to mine
- Latency to pool stratums
- varying hashrate accepted by pool where your input under statistical perfect condition, should be near consistent for same algo (manipulating chances of a roulette game while keeping your round input the same)
- Potentially overlapping/conflicting settings by setting up complicated coin/pool/exchange combos.
***
Correction to my previous comment:
Problem you are seeing here is easy, you are mining specific coins on Yiimp shared port, the Yiimp profitability figures overrides the one provided by coin profitability providers such as WTM, CC etc.
This is only the case if you have online services entry (predefined or custom) overlapping custom defined pool with the same algo from same Yiimp pool. Problem can exist even if you disabled the online service for profit switching later, only way to get rid off it surely is to remove the online service entry. or this is what could happen: