Два неприятных бага в последних версиях:

1) При автоперезапуске форкфикса он зачем-то убивает все процессы майнеров, которые находит в системе, в том числе и те, которые запускал не он. Ему не для того админские права дадены, чтобы он делал что хочет; кстати, надеюсь, практика тихого изменения настроек системы уже в прошлом? Я хотел бы явного подтверждения.

2) Я о том, что так скорее всего будет, уже писал, вы тогда реплику проигнорировали: независимо от включенности галочки "использовать OpenHardwareMonitor" оно грузит драйвер WinRing0 и некорректно выгружает его при выходе, разрушая цепочку пользователей драйвера, если форкфикс оказался в её начале или особенно в середине. Простое упражнение: а) запускаем OpenHardwareMonitor или LibreHardwareMonitor, б) запускаем форкфикс, в) запускаем xmrig; г) перезапускаем форкфикс и затем д) пытаемся перезапустить xmrig – тот уже не может ничего сделать с драйвером и, как следствие, не может установить/снять флаги управления кэшированием. Теперь, чтобы xmrig вновь заработал полноценно, нужно закрыть одновременно все процессы, использующие драйвер WinRing0.

NiceHash Miner Legacy Fork Fix 29
RUS:
1. Добавлен алгоритм BeamV3
2. Обновлен майнер NBminer до версии 31.1
3. Обновлен майнер GMiner до версии 2.11
4. Обновлен майнер miniZ до версии 1.6v2
5. Обновлен майнер lolMiner до версии 1.01

Антон, на нбмайнере кукуату32 - майнер вылетает (ошибка out of memory кажется), на гмайнере все норм. Это нбмайнер глючит?

Здравствуйте!
BeamV3 только на ЛолМайнере.
Хотелось бы сравнить с GMiner, он ведь тоже поддерживает V3.

Это ещё как посмотреть. У меня gminer показывает хэшрейт для cuckatoo32 на 15-20% больше, чем найсхэш, при том что битых шар ничтожно мало или совсем нет. Пробовал даже на сутки жёстко включать и сравнивать усреднённое – всё то же самое, кто-то из них врёт.

На всех ригах одна версия винды (7-ка). Версия винды 6.1.7601.23403 sp1. Update от 2018 года на сколько я понял

Все фермы в одной сети. Перезагрузка рига никак не влияет

angelbbs, при переходе с 27 на 28 версию появилась ошибка при майнинге GrinCuckatoo32 с текстом: "All devfee mining pools are unavailable". Ошибка выскакивает не всегда, до тех пор пока не подключится, но пока не помайнит на разработчиков, то будет происходить постоянное пропадание майнинга. За сутки может выскочить около сотни раз пропадание. Ошибка проявляется только на этом алгоритме и только на одной ферме, на других фермах на этом же алгоритме все норм. Пробовал откатиться на более раннюю версию gminer-a - то же самое. Переустанавливал 28 версию – то же самое. Самое интересное, что при откате на 27 версию форк фикса ошибки нет. Логи и скрины прилагаю.
логи - https://yadi.sk/d/V7XlsxmakbvcSQ
скрины - https://yadi.sk/d/ffeAsZhtGTtI4w
ps. на 3-ем скрине, там где идут "пилы" - это все невозможность коннекта

to angelbbs
есть мысли что поправить?

можно ли добавить опционально в настройках перезагрузку ПК раз в столько то часов?

---------------------------------------------------


хотелось бы ещё раз уточнить про бенчмарк - тестирует до первой шары и записывает скорость?

на github сборка от 9 июня
при установке находится обновление после 9 июня через автоматическое обновление

как скачать самую последнюю сборку?


как посмотреть что изменилось в сборке?

Антон, привет! Есть проблема в том, что при смене алгоритма оболочка пишет старый алгоритм, например копает кавпов на гмайнере а пишет что дагер хашимото на клее. В общем лаг какой то. Как в таком случае будет происходить смена алгоритмов (будет ли она работать хз) руками постоянно перезапускаю.. 

Антон спасибо за твою работу. В силу обстоятельств вынужден был неделю сидеть на официальной версии найса. По личным наблюдениям твоя версия более гибко настраиваемая, стабильнее работает и показывает несколько больший доход в сравнении с официальной.
На официальную версию вынужден был перейти в связи с тем, что после обновления на 28 версию риги вновь пропали из кабинета найса. Косяк устранил заменив в файле General.json параметры:  "MachineGuid", "hwid" на данные параметра  hwid из этого же файла но в официальной версии. Если не сложно объясни:
 1) Я так понимаю "CpuID" это ID процессора материнской платы, если так то почему он на всех ригах одинаков?
 2) "MachineGuid" это ID рига и он генерируется из id нескольких устройств рига?
 3) "hwid" это id по которому риг привязывается в личном кабинете и генерируется он из двух предыдущих ригов?
Кстати после чистой установки твоей версии hwid и CpuID оказываются одинаковыми, это так и должно быть?
У меня кабинет заработал после того как я прописал параметр "MachineGuid" в параметр "hwid". При этом, параметр "MachineGuid" в твоей версии почему то одинаков с параметром "hwid" и эти два параметра одинаковы по всем ригам (у меня несколько ригов полностью эдентичных), а вот "MachineGuid" везде генерируется свой, но кабинет найса похоже привязывается к параметру "hwid" поэтому у меня были глюки.
Возможно это только у меня. А может кому еще пригодится.

Она там трёхдневной давности, так и должно быть?

Ну допустим вот: http://www.mediafire.com/file/fut9ehz2guy717x/Wrong_Claymore_Uptime.zip/file (кошелёк в конфиге вытерт). В тестовом риге стоит две 1070, одна из них зажата до 70% TDP.
Заодно взгляните, что это оно на выходе за несуществующий PID 6000 вместе с клеймором пытается прибить.

Да, и если интересно, то аптайм клеймора по-прежнему сбрасывается у меня только остановкой майнинга (кнопкой "Стоп"). А кнопка перезапуска майнера вообще не сбрасывает аптайм ни на каком алгоритме.

Антон привет,такой вопрос,активно пользуюсь вкладкой "настройки гпу",есть ли возможность как то применить к определенному алгоритму профиль автобернера именно с даунвольтом?Еще пожелание:активные выбранные алгоритмы чтобы оказывались в верхней части списка(иногда надо прокручивать-не удобно,подлагивает)

Здравствуйте  Антон , можете сказать это нормально  в последней версии фикс  и даное происходит на 4 ригах из 5  могу только сказать переключение алгоритма и перезапуск программы без перезагрузки  в GPU_Lost записей нет  вылетов нет  в настройка перезапуск виндовс при потереCUDA GPU

[2020-06-09 18:54:24] [INFO] [Monitor] Start monitoring process ID: 3556
...