Oh, no - please don't mention a different miner in this thread! Kano will post a 10 paragraph reply accusing you of being a shill who is just advertising for that crapminer you mentioned.
A miner that adds features that CGMiner does not have is not a bad thing. A miner that copies CGMiner and then claims that CGMiner is inferior in every imaginable way is something that Kano does not seem to take lightly. See the difference?
I don't care about the difference. When a user posts a bug report and happens to mention that the problem does not occur with some other mining software, that user does not deserve to be attacked, and the report ignored just because Kano has personal issues with another developer.
No.
As I stated in the reply before, the logic you presented was complete fail.
Something didn't work for you with program A whatever you did wrong.
So you ran program Bleargh on another operating system with a different configuration.
Even a inept fool should be able to see the logic fail there.
Kano, you need to chill out dude. You're a tremendous douche-bag at times. No need for that unless you are applying for a job at Butterfly Labs.
Maybe I missed where the OP of the complaint stated that he tried compiling on windows, or compiled CGminer on Linux. Re-reading it a few times I noted the OP had only stated trying the binary release on windows. Not compiling, not an older version, not switching to Linux.
What the OP did was shortly after posting a problem that could be A) windows related, B) cgminer software related or C) hardware related the OP posted that switching the OS to Linux, the software to another software that the problem disappeared. As far as I know the OP of the complaint switched hardware too as I am not seeing where the OP had gone to the trouble of reformatting to run Linux. So sure by changing everything but the block erupters I can assure you the problem was not directly the block erupters. But as far as a bug in cgminer I think maybe a little more stringent diagnostic procedure is required to have a guess at that.
To be honest I can assure you using less shortcuts on the same testing strategy months before I had issues with CGminer on windows. All timeout related. Even increasing the timeout (Kano did it to try to fix the problem) there was nothing fixing that version. I could have stratum on eclipse or far lower errors on cgminer rolling back to an older version. I did build on windows from kano's git. I did try other things. I finally ordered a Raspberry pi compiled the newest cgminer (at the time) and suddenly the errors went away. Same version I wanted to run on windows just on Linux. Now unfortunately the problem could be A) the computer I used to use, or B) the operating system. Since I could run the previous version without issues without the hardware errors the problem wasn't directly with my hardware. There was a compatibility issue with the timer in windows not being accurate enough. Since I could keep the CGminer version the same on both I could prove that cgminer itself wasn't the issue. If the timeouts had been caused by cgminers lower latency on that version it would apply to the much slower raspberry pi with even lower latency on linux.
Now given that level or more of testing I would say maybe the OP had a bug. Given the information posted either the OP didn't test anything or forgot to mention any tests the ran to try to track down the error. Maybe there is a bug. But is the bug with windows, cgminer or the OP's hardware? I can't answer that. No one can off of the information provided.
I am sure they are looking for the bug right now. Given a little more information maybe they will know where to look for the bug. To me it seems better to ask what would help them find the bug that was so bothersome. Maybe hold other variables still while changing only one at a time so as to narrow down the possibilities.
I have reported bugs here. I have been met with no real hostility by anyone. I just ask how to fix whatever error I was having. I let them know what versions the error hadn't shown up on until. By doing that at least the places to look for the bug is limited to the changes between the last known good version and the current version
All this might be applicable, if my goal was to troubleshoot CGMiner. It was not. My goal was to get my mining hardware mining reliably. I tried one configuration, which happened to be a very generic install of the release distribution of CGMiner, and I had problems with that configuration. I then tried a different configuration that worked 100%. I'm done, my problem is solved.
I posted the problem that I had experienced here to alert the developers that there might be an issue, because I thought that was the right thing to do. I would think that the information that a generic install of CGMiner appeared to have problems with Block Erupters might be worth knowing to the developers, and the fact that the same Block Erupters worked perfectly in another configuration was just included to demonstrate that there was no hardware problem involved.
Now, you can fairly say that that is not a very detailed bug report, and therefore of limited value to the developer. I did not invest any time at all in trying to fix CGMiner, because my goal was just to get my hardware reliably making money ASAP, and I accomplished that.
That being said, I could understand if my post was answered with "Well, that's not really enough information for me to determine the problem you were having, and I cannot reproduce this failure, so I can't act on this report."
Instead, I was attacked as a SHILL, who was somehow ADVERTISING for a 'competitor'! Does that not seems just a little over the top to you?
Maybe it wasn't the best bug report ever written, but I did not deserve the response I got.
