На рутрекере брал одну из сборок SimpleTV. Уникальная прога на базе VLC, куча всяких полезностей. В плейлисте 1000+ каналов, есть HD. Можно воспроизводить видео с обычных торрент трекеров. Рекламы не заметил, вроде бы она отключается в настройках Ace Stream.
» BitTorrent/BitComet/Azureus/BitTornado и др. / сеть и клиент
(решил продублировать с другой ветки)
Подбираю клиент с DLNA и с вариантом режима "последовательной закачки"
(для просмотра фильмов с момента начала закачки ... и сразу же на телике)
(+ не плохо бы с режимом поиска по важнейши трекерам rutracker, NNM-Club, rutor и т.д.).
По всем признакам "вместе" что-то не нашлось сбалансированного медиа-торрент-комбайна,
но некоторые кандидаты образовались:
- qBittorrent (нету свего DLNA, но его закачки с самого начало легко подхватываюся тем же Plex-ом),
- Vuze (монстро-образный, не смог его приготовить в употребительное состояние, нужные функции - платные),
- MediaGet (нету DLNA, да и встроенный поисковик частенько пролетал мимо высоко-битрейных новинок),
- Zona (но слышал отзывы, что слишком агрессивно держит приоритет в пользу скачивания),
- Фильмоскоп - давненько пробовал - был совсем детский - есть ещё много куда развиваться.
С раздачей у многих из них не ахти - поэтому хотелось
что бы за два часа просмотра фильма можно успеть и 2-3 подобных раздать.
uTorrent - наблюдал частую неравномерность закачки в "последовательном" режиме
(на блиц-подхвате как-то не кошерно работал - для одновременного медиа-употребления
крайне важна стабильность и равномерность торрент-потоков, что бы сразу была видна
необходимая достаточность скорости для поддержания текущего просмотра).
Подбираю клиент с DLNA и с вариантом режима "последовательной закачки"
(для просмотра фильмов с момента начала закачки ... и сразу же на телике)
(+ не плохо бы с режимом поиска по важнейши трекерам rutracker, NNM-Club, rutor и т.д.).
По всем признакам "вместе" что-то не нашлось сбалансированного медиа-торрент-комбайна,
но некоторые кандидаты образовались:
- qBittorrent (нету свего DLNA, но его закачки с самого начало легко подхватываюся тем же Plex-ом),
- Vuze (монстро-образный, не смог его приготовить в употребительное состояние, нужные функции - платные),
- MediaGet (нету DLNA, да и встроенный поисковик частенько пролетал мимо высоко-битрейных новинок),
- Zona (но слышал отзывы, что слишком агрессивно держит приоритет в пользу скачивания),
- Фильмоскоп - давненько пробовал - был совсем детский - есть ещё много куда развиваться.
С раздачей у многих из них не ахти - поэтому хотелось
что бы за два часа просмотра фильма можно успеть и 2-3 подобных раздать.
uTorrent - наблюдал частую неравномерность закачки в "последовательном" режиме
(на блиц-подхвате как-то не кошерно работал - для одновременного медиа-употребления
крайне важна стабильность и равномерность торрент-потоков, что бы сразу была видна
необходимая достаточность скорости для поддержания текущего просмотра).
2norma А чем вас ace stream не устраивает?
Добавлено:
сам в поиске клиента, который делает приоретизацию своего трафика в зависимости от загруженности канала. Другими словами, если паралельно идет закачка другими прогами, скорость торрент-качалки должна уменьшаться.
Добавлено:
сам в поиске клиента, который делает приоретизацию своего трафика в зависимости от загруженности канала. Другими словами, если паралельно идет закачка другими прогами, скорость торрент-качалки должна уменьшаться.
cutetorrent https://cutetorrent.info/
PicoTorrent
PicoTorrent - крошечный и лёгкий в использовании клиент BitTorrent с низким потреблением памяти.
Есть русский, для кого это критично.
We made PicoTorrent to go back to the basics of what is needed from a BitTorrent client. No ads, carefully selected features, and a native user interface integrating seamlessly with your desktop.
http://www.picotorrent.org/
PicoTorrent - крошечный и лёгкий в использовании клиент BitTorrent с низким потреблением памяти.
Есть русский, для кого это критично.
We made PicoTorrent to go back to the basics of what is needed from a BitTorrent client. No ads, carefully selected features, and a native user interface integrating seamlessly with your desktop.
http://www.picotorrent.org/
Возможно кто-то уже решал такую задачу и даже решил...
1. Есть обновляемые раздачи сериалов, т.е. весь сезон в одном торренте;
2. Они мониторятся на трекерах (torrentmonitor) и перезакачиваются по факту обновления;
3. Дальше передаются в качалку (uTorrent сейчас)...
Дальше начинаются проблемы:
4. Приходится смотреть в список в клиенте,
5. Лапами выбирать категорию (но это можно автоматизировать - просто лень);
6. Вручную выбирать папку, куда это все безобразие было закачено ранее (очень лень!);
7. Запускать Re-Check (и Re-Check в uTorrent'е долгий).
Вот от пунктов 4-7 мне хотелось бы как-то избавиться, но даже не знаю с какой стороны подступиться... Торрент-клиент и ось неважны.
1. Есть обновляемые раздачи сериалов, т.е. весь сезон в одном торренте;
2. Они мониторятся на трекерах (torrentmonitor) и перезакачиваются по факту обновления;
3. Дальше передаются в качалку (uTorrent сейчас)...
Дальше начинаются проблемы:
4. Приходится смотреть в список в клиенте,
5. Лапами выбирать категорию (но это можно автоматизировать - просто лень);
6. Вручную выбирать папку, куда это все безобразие было закачено ранее (очень лень!);
7. Запускать Re-Check (и Re-Check в uTorrent'е долгий).
Вот от пунктов 4-7 мне хотелось бы как-то избавиться, но даже не знаю с какой стороны подступиться... Торрент-клиент и ось неважны.
emx
По части каталогов просто - в настройках выбрать базовый и большинство клиентов работают относительно него. Так что тут задача решается просто. Так же просто решается задача IF EXIST - клиент сам проверяет хэш файла и если он есть и хэш совпадает пропускает его скачивая только то, чего нет. С ручным выбором так же проблема решается настройкой или ключами комстроки (обычно для консольных клиентов) - можно сказать чтобы клиент валил всё в один каталог, а после например скриптом разбирать всё. Только тогда потребуется вызов парсера торрент-файла который в идеале должен выдать нам листинг файлов по которому скрипт построит выходную подборку.
Что касается хэширования, то его время сильно зависит от скорости получения данных с удалённой системы которая в этом случае выступает в качестве эталона для проверки целостности данных, но и клиент вносит свой вклад. Сама хэш-функция построена на SHA-1 файлов и заголовка торрент файла, но можно встретить её далеко не самые оптимальные по времени счёта реализации.
Из GUI-клиентов лично мне последнее время больше нравится qBittorrent построенный на libtoorrent и QT в качестве QUI фраймеворка. Единственное что (в вин сборке) приходится там выкидывать это здоровенную .PDB-ку которая может втрое превосходит по размеру бинарник, а нужна ему как собаке пятая нога - я к примеру за годы что с ним знаком ни разу не видел чтобы он упал и пришлось ей воспользоваться для его отладки. И потому обычно сразу её удаляю как балласт. Достать из NSIS-а всегда можно - 7-Zip вечно под рукой.
По части каталогов просто - в настройках выбрать базовый и большинство клиентов работают относительно него. Так что тут задача решается просто. Так же просто решается задача IF EXIST - клиент сам проверяет хэш файла и если он есть и хэш совпадает пропускает его скачивая только то, чего нет. С ручным выбором так же проблема решается настройкой или ключами комстроки (обычно для консольных клиентов) - можно сказать чтобы клиент валил всё в один каталог, а после например скриптом разбирать всё. Только тогда потребуется вызов парсера торрент-файла который в идеале должен выдать нам листинг файлов по которому скрипт построит выходную подборку.
Что касается хэширования, то его время сильно зависит от скорости получения данных с удалённой системы которая в этом случае выступает в качестве эталона для проверки целостности данных, но и клиент вносит свой вклад. Сама хэш-функция построена на SHA-1 файлов и заголовка торрент файла, но можно встретить её далеко не самые оптимальные по времени счёта реализации.
Из GUI-клиентов лично мне последнее время больше нравится qBittorrent построенный на libtoorrent и QT в качестве QUI фраймеворка. Единственное что (в вин сборке) приходится там выкидывать это здоровенную .PDB-ку которая может втрое превосходит по размеру бинарник, а нужна ему как собаке пятая нога - я к примеру за годы что с ним знаком ни разу не видел чтобы он упал и пришлось ей воспользоваться для его отладки. И потому обычно сразу её удаляю как балласт. Достать из NSIS-а всегда можно - 7-Zip вечно под рукой.
Victor_VG
Цитата:
Я это понимаю, но вручную приходится (п. 6-7).
По какому признаку качалка определяет, что торрент-файл Х является апдейтом другой раздачи? Чисто по наличию файликов в базовой папке, с названиями из этого нового торрента?
И сам рехеш запустит и сам стартанет потом закачку?
А если папок много? Просто у меня каталогизация в uT настроена таким образом, чтобы все разбрасывалось по разным папочкам после загрузки, а в процессе загрузки все валится в общую. В результате у меня такого признака нет. uT считает, что это новый торрент (т.к. во временной папке загрузок ничего нет) и ничего сам больше не делает.
Можно, конечно, отказаться от распихивания, но бардак феерический будет. Но я примерно понял, что можно попробовать. А именно категоризировать правилами на входе, возможно тогда в качестве папки примет и ту, куда все в итоге переносится.
Вообще, в идеале мне нужен какой-то API, чтобы я получил торренты от мониторилки и скриптами сказал клиенту, что вот эта хрень относится к такому-то циклу, рехешим и стартуем, базой является то-то... По-моему, я слишком дофига хочу...
Цитата:
Не, хеши кусков хранятся в самом файле .torrent. Просто я обратил внимание, что некоторые клиенты быстрее перехешируют, другие - медленее. Плюс, в qBit'е я помню можно встать на раздачу даже не перехешируя, если уверен, что там все цело (для обновлений не катит). В uT такого нет или я не нашел...
Цитата:
Пробовал, валится у меня буквально почти сразу. На раздаче обычно 1000+ торрентов и не переварить ему это... Я на него даже переехать не успел, начал валиться после нескольких сотен...
Правда, тестил на винде, может под линем он приятнее.
Цитата:
Так же просто решается задача IF EXIST - клиент сам проверяет хэш файла и если он есть и хэш совпадает пропускает его скачивая только то, чего нет.
Я это понимаю, но вручную приходится (п. 6-7).
По какому признаку качалка определяет, что торрент-файл Х является апдейтом другой раздачи? Чисто по наличию файликов в базовой папке, с названиями из этого нового торрента?
И сам рехеш запустит и сам стартанет потом закачку?
А если папок много? Просто у меня каталогизация в uT настроена таким образом, чтобы все разбрасывалось по разным папочкам после загрузки, а в процессе загрузки все валится в общую. В результате у меня такого признака нет. uT считает, что это новый торрент (т.к. во временной папке загрузок ничего нет) и ничего сам больше не делает.
Можно, конечно, отказаться от распихивания, но бардак феерический будет. Но я примерно понял, что можно попробовать. А именно категоризировать правилами на входе, возможно тогда в качестве папки примет и ту, куда все в итоге переносится.
Вообще, в идеале мне нужен какой-то API, чтобы я получил торренты от мониторилки и скриптами сказал клиенту, что вот эта хрень относится к такому-то циклу, рехешим и стартуем, базой является то-то... По-моему, я слишком дофига хочу...
Цитата:
Что касается хэширования, то его время сильно зависит от скорости получения данных с удалённой системы которая в этом случае выступает в качестве эталона для проверки целостности данных, но и клиент вносит свой вклад.
Не, хеши кусков хранятся в самом файле .torrent. Просто я обратил внимание, что некоторые клиенты быстрее перехешируют, другие - медленее. Плюс, в qBit'е я помню можно встать на раздачу даже не перехешируя, если уверен, что там все цело (для обновлений не катит). В uT такого нет или я не нашел...
Цитата:
Из GUI-клиентов лично мне последнее время больше нравится qBittorrent построенный на libtoorrent и QT в качестве QUI фраймеворка.
Пробовал, валится у меня буквально почти сразу. На раздаче обычно 1000+ торрентов и не переварить ему это... Я на него даже переехать не успел, начал валиться после нескольких сотен...
Правда, тестил на винде, может под линем он приятнее.emx
С большими количествами раздач я не вожусь, но вроде после 3.3 qBit перестал сбоить. По крайней мере не стал прерывать сидирование если сидим за NAT-ом в несколько слоёв как у меня - NAT с SOCK у провайдера плюс выход через роутер.
Правда можно предположить что если раздач много, то просто клиенту памяти на буфера не хватает и он потому валится. Или утечка памяти, но последняя легко ловится в Process Hacker (это версия 3.0 и её минимум семёрка, а для XP SP2/Vista нужна 2.39) - ПКМ на имени процесса, Perfomance и сразу видна утечка памяти например именно там мы её с Мартином в HWiNFO64 v5.22.2800 зафиксировали:
благо такое явление сразу видно - процессорное время ноль, трафик I/O ноль, а расход памяти увеличивается во времени. Но и тут если утечка памяти есть думаю она проявится именно увеличением пула Private Bytes (собственно код + буфера) во времени что сразу покажет график. Для хендлов жаль график не строится
и тут только запись счётчика и сравнение отсчётов, но и тут утечки ловятся, хотя с чуть большей вознёй.
В qBit и прочих построенных на либах такой АПИ есть, а у мюторрента как помню он не выведен наружу, а потому там только ключи его комстроки могут помочь.
С большими количествами раздач я не вожусь, но вроде после 3.3 qBit перестал сбоить. По крайней мере не стал прерывать сидирование если сидим за NAT-ом в несколько слоёв как у меня - NAT с SOCK у провайдера плюс выход через роутер.
Правда можно предположить что если раздач много, то просто клиенту памяти на буфера не хватает и он потому валится. Или утечка памяти, но последняя легко ловится в Process Hacker (это версия 3.0 и её минимум семёрка, а для XP SP2/Vista нужна 2.39) - ПКМ на имени процесса, Perfomance и сразу видна утечка памяти например именно там мы её с Мартином в HWiNFO64 v5.22.2800 зафиксировали: 
благо такое явление сразу видно - процессорное время ноль, трафик I/O ноль, а расход памяти увеличивается во времени. Но и тут если утечка памяти есть думаю она проявится именно увеличением пула Private Bytes (собственно код + буфера) во времени что сразу покажет график. Для хендлов жаль график не строится
и тут только запись счётчика и сравнение отсчётов, но и тут утечки ловятся, хотя с чуть большей вознёй. В qBit и прочих построенных на либах такой АПИ есть, а у мюторрента как помню он не выведен наружу, а потому там только ключи его комстроки могут помочь.
Victor_VG
Фух, наконец вернулся к этому вопросу...
Цитата:
Я тут потестил, вышеописанные задачи почти идеально выполняет Deluge + плагины. Попробую на него переехать. Смущает только 32-битность.
Цитата:
Легко могу выделить 10-20 гигов. uT 64-битный память отлично поджирает, когда свободная есть.
Цитата:
Да не, я его доводил до состояния, что он падал практически сразу(!)... Дело не в утечках. Он и памяти-то сожрать не успевал.
Фух, наконец вернулся к этому вопросу...
Цитата:
но вроде после 3.3 qBit перестал сбоить
Я тут потестил, вышеописанные задачи почти идеально выполняет Deluge + плагины. Попробую на него переехать. Смущает только 32-битность.
Цитата:
Правда можно предположить что если раздач много, то просто клиенту памяти на буфера не хватает и он потому валится.
Легко могу выделить 10-20 гигов. uT 64-битный память отлично поджирает, когда свободная есть.
Цитата:
Но и тут если утечка памяти есть думаю она проявится именно увеличением пула Private Bytes (собственно код + буфера) во времени что сразу покажет график.
Да не, я его доводил до состояния, что он падал практически сразу(!)... Дело не в утечках. Он и памяти-то сожрать не успевал.
emx
Делюдже - ну, можно конечно и его использовать, но у него была ошибка в отсылке статистики о выполнении что приводило к неоднократному появлению юзера в списке скачавших. Не знаю исправили или нет?
Что до разрядности, то тут по идее она влиять не должна т.к. если что всегда можно запустить несколько копий задачи.
А вот с причиной падения стоит посмотреть что там на деле? Может как у меня было - превысил число ранков памяти и машина видела все 8 Гб на Р45, но на границе 4 - 5 Гб возникал сбой контроллера ОЗУ и в итоге что-то, чаще всего Х-ы сыпалось. Еле отыскал причину.
Делюдже - ну, можно конечно и его использовать, но у него была ошибка в отсылке статистики о выполнении что приводило к неоднократному появлению юзера в списке скачавших. Не знаю исправили или нет?
Что до разрядности, то тут по идее она влиять не должна т.к. если что всегда можно запустить несколько копий задачи.
А вот с причиной падения стоит посмотреть что там на деле? Может как у меня было - превысил число ранков памяти и машина видела все 8 Гб на Р45, но на границе 4 - 5 Гб возникал сбой контроллера ОЗУ и в итоге что-то, чаще всего Х-ы сыпалось. Еле отыскал причину.
Victor_VG
Цитата:
Не уверен, но какие-то его версии были забанены на куче трекеров. Смотрел what.cd/waffles.fm - давно разрешен, так что пофиксили скорее всего.
Цитата:
Это чтобы больше рамы выделять на процесс. Для кэша %)
Цитата:
Да лень мне... В qBit'е все равно не нашел функцию автоматического присвоения меток при импорте из заданных папок.
Цитата:
Делюдже - ну, можно конечно и его использовать, но у него была ошибка в отсылке статистики о выполнении что приводило к неоднократному появлению юзера в списке скачавших. Не знаю исправили или нет?
Не уверен, но какие-то его версии были забанены на куче трекеров. Смотрел what.cd/waffles.fm - давно разрешен, так что пофиксили скорее всего.
Цитата:
Что до разрядности, то тут по идее она влиять не должна т.к. если что всегда можно запустить несколько копий задачи.
Это чтобы больше рамы выделять на процесс. Для кэша %)
Цитата:
А вот с причиной падения стоит посмотреть что там на деле?
Да лень мне... В qBit'е все равно не нашел функцию автоматического присвоения меток при импорте из заданных папок.
emx
Если помнишь у нас вылезало это явление и мы не могли понять с чего один и тот же человек по нескольку раз в скачавших числится - ведь это явная бессмыслица. Тогда ULer рассказал про эту ошибку и мы все договорились делюгой не пользоваться пока не исправят. Я с тех пор про неё и забыл, но про наличие и механизм возникновения ошибки помнил. Он там прост до смеха - при отсылке статистики клиент каждый раз посылал трекеру метку "выполнено", а тот как любой робот отрабатывал её буквально и добавлял бедолагу в список скачавших. Иные пока мы не разобрались где ошибка по нескольку раз просили удалить их из списка скачавших из-за подозрений на неумышленное читерство.
Что до выделения кэша тут на деле в большом объёме и смысла нет - его размер зависит от скорости обработки очереди команд накопителя и размера блока передаваемого за одну транзакцию шины. Фактически тут линейная зависимость - скорость (V) * количество блоков (N)* число параллельных потоков накопителя (P). Так что слишком ёмкий буфер не имеет смысла, максимум что имеет смысл это 4*V*N*P, и то в случае если ОС и ПО умеют работать с двойной буферизацией и с полным/полу дуплексом, а коли нет тут и половины хватит, а коли работает режим одностороннего обмена по принципу "выполнил, отчитался, переключили направления канала" то и одиночного буфера хватит. А всё остальное просто трата ресурсов. Не зря же к примеру у Adaptec SCSI RAID 2120S/2130SLP стоит кэш в 64/128 Мб на 15 Ultra320 SCSI дисков и его хватает даже если на плети висит полтора десятка 15К гепардов. А этих ребят медлительными назвать сложно. Тут скорее господам авторам программ надо провести массаж бестолковки прикладом, правда осторожно дабы остатки извилины не распрямить, чтобы они не дёргали под буфера памяти больше чем реально надо с учётом как трафика внешнего канала, так и пропускной способности подсистемы хранения. А то они привыкли мыслить однозадачно и ломятся как носорог в открытую дверь.
Если помнишь у нас вылезало это явление и мы не могли понять с чего один и тот же человек по нескольку раз в скачавших числится - ведь это явная бессмыслица. Тогда ULer рассказал про эту ошибку и мы все договорились делюгой не пользоваться пока не исправят. Я с тех пор про неё и забыл, но про наличие и механизм возникновения ошибки помнил. Он там прост до смеха - при отсылке статистики клиент каждый раз посылал трекеру метку "выполнено", а тот как любой робот отрабатывал её буквально и добавлял бедолагу в список скачавших. Иные пока мы не разобрались где ошибка по нескольку раз просили удалить их из списка скачавших из-за подозрений на неумышленное читерство.
Что до выделения кэша тут на деле в большом объёме и смысла нет - его размер зависит от скорости обработки очереди команд накопителя и размера блока передаваемого за одну транзакцию шины. Фактически тут линейная зависимость - скорость (V) * количество блоков (N)* число параллельных потоков накопителя (P). Так что слишком ёмкий буфер не имеет смысла, максимум что имеет смысл это 4*V*N*P, и то в случае если ОС и ПО умеют работать с двойной буферизацией и с полным/полу дуплексом, а коли нет тут и половины хватит, а коли работает режим одностороннего обмена по принципу "выполнил, отчитался, переключили направления канала" то и одиночного буфера хватит. А всё остальное просто трата ресурсов. Не зря же к примеру у Adaptec SCSI RAID 2120S/2130SLP стоит кэш в 64/128 Мб на 15 Ultra320 SCSI дисков и его хватает даже если на плети висит полтора десятка 15К гепардов. А этих ребят медлительными назвать сложно.
Тут скорее господам авторам программ надо провести массаж бестолковки прикладом, правда осторожно дабы остатки извилины не распрямить, чтобы они не дёргали под буфера памяти больше чем реально надо с учётом как трафика внешнего канала, так и пропускной способности подсистемы хранения. А то они привыкли мыслить однозадачно и ломятся как носорог в открытую дверь. Victor_VG
Цитата:
Смысл в том, что меньше дергаем винты и буферизируем популярный контент. С большим буфером (5-8 Гб кэша и больше) скорость раздачи поднималась и стабилизировалась на 15-20 Мбайт/сек. Без этого, с большим кол-вом раздач, - обычно единицы Мбайт/сек, т.к. иопсы сжираем дерганьем разных участков (раздач много), а буфер мелкий (не влезает толком ничего), в результате все тормозит и не раздается
Цитата:
Ну ты вспомнил же... Сегодня модно выделять SSD под кэш, ибо иопсов винтов катастрофически мало, а так можно буферизировать. Уже даже на бытовой уровень пришло - FreeNAS давно умеет (ZFS+ZIL/L2ARC на SSD+рама под кэш).
Ну вот и переехал на Deluge...
1) Длинные списки (600+ раздач) скроллит в режиме слайд-шоу
2) Иногда добавляются, но не отображаются в списках новые загрузки %) Клацаем по .torrent, закачка вроде началась - файл аллоцируется, а в списке нет. Появляется после перезапуска клиента.
3) Грузит проц неплохо: http://i79.fastpic.ru/big/2016/0407/e8/d0f64766bc5863f7b8a920f6b3377ee8.png
4) Не нашел журнала у клиента, так что не видно что там по п. 2 происходит.
Цитата:
Что до выделения кэша тут на деле в большом объёме и смысла нет
Смысл в том, что меньше дергаем винты и буферизируем популярный контент. С большим буфером (5-8 Гб кэша и больше) скорость раздачи поднималась и стабилизировалась на 15-20 Мбайт/сек. Без этого, с большим кол-вом раздач, - обычно единицы Мбайт/сек, т.к. иопсы сжираем дерганьем разных участков (раздач много), а буфер мелкий (не влезает толком ничего), в результате все тормозит и не раздается
Цитата:
Adaptec SCSI RAID 2120S/2130SLP
Ну ты вспомнил же...
Сегодня модно выделять SSD под кэш, ибо иопсов винтов катастрофически мало, а так можно буферизировать. Уже даже на бытовой уровень пришло - FreeNAS давно умеет (ZFS+ZIL/L2ARC на SSD+рама под кэш). Ну вот и переехал на Deluge...
1) Длинные списки (600+ раздач) скроллит в режиме слайд-шоу
2) Иногда добавляются, но не отображаются в списках новые загрузки %) Клацаем по .torrent, закачка вроде началась - файл аллоцируется, а в списке нет. Появляется после перезапуска клиента.
3) Грузит проц неплохо: http://i79.fastpic.ru/big/2016/0407/e8/d0f64766bc5863f7b8a920f6b3377ee8.png
4) Не нашел журнала у клиента, так что не видно что там по п. 2 происходит.
emx
по п. 3 - н-н-да... за такие художества в коллегии кардинала Мазарини награждали Бастилией, а Пётр I отправлял на "беседу" к Ромадановскому.
Что до SSD - вспомни июнь 15-го - считай sf.net три недели по их милости лежал и половина проектов до сих пор толком не работает - а там именно SSD легли. Так что я лучше по старинке, зато надёжнее. У SSD есть только одно преимущество перед механикой - меньшая чувствительность к ударным нагрузкам, но что касается надёжности отдельной ячейки тут и спорить смысла нет SSD (EEPROM) <= 10E5 или HDD >= 10E17. Разница в дюжину порядков плюс разница минимум на порядок во времени хранения состояния ячейки в пользу HDD. Правда т.к. это механика, то время оборота и подвода голов достаточно велико, а у EEPROM время задержки адресных дешифраторов достаточно мало и много меньше времени оборота HDD, но у неё есть технологическая альтернатива которую искусственно сдерживают - накопители на Цилиндрических Магнитных Доменах (ЦМД). Тут мы найдём сочетание малого времени доступа как у SSD, надёжности магнитного слоя, а заодно и сложность изготовления многослойной структуры и управления - я в 84-м видел ЦМД матрицы на 128 Мб - схема управления использовала 36-и фазную синхронизацию на 100 КГц, зато был один плюс - габариты микросборки 2х3х1 см. Эти устройства были бы намного луemx
по п. 3 - н-н-да... за такие художества в коллегии кардинала Мазарини награждали Бастилией, а Пётр I отправлял на "беседу" к Ромадановскому.
Что до SSD - вспомни июнь 15-го - считай sf.net три недели по их милости лежал и половина проектов до сих пор толком не работает - а там именно SSD легли. Так что я лучше по старинке, зато надёжнее. У SSD есть только одно преимущество перед механикой - меньшая чувствительность к ударным нагрузкам, но что касается надёжности отдельной ячейки тут и спорить смысла нет SSD (EEPROM) <= 10E5 или HDD >= 10E17. Разница в дюжину порядков плюс разница минимум на порядок во времени хранения состояния ячейки в пользу HDD. Правда т.к. это механика, то время оборота и подвода голов достаточно велико, а у EEPROM время задержки адресных дешифраторов достаточно мало и много меньше времени оборота HDD, но у неё есть технологическая альтернатива которую искусственно сдерживают - накопители на Цилиндрических Магнитных Доменах (ЦМД). Тут мы найдём сочетание малого времени доступа как у SSD, надёжности магнитного слоя, а заодно и сложность изготовления многослойной структуры и управления - я в 84-м видел ЦМД матрицы на 128 Мб - схема управления использовала 36-и фазную синхронизацию на 100 КГц, зато был один плюс - габариты микросборки 2х3х1 см. Эти устройства были бы намного луemx
Windows 10 Insider. Столкнулся с проблемой, что при работе uTorrent или qBittorrent начинает дико лагать система. Начинает хрипеть звук, всё зависать, а мышь двигаться как в слоу мо. "System" в диспетчере задач загружается на 20-30% и проводник просто падает в процессе.
Причём такого нет при загрузке любых файлов через обозреватель или мастер закачек (не торрент).
Из-за чего может быть такой конфликт при работает с торрентами?
Причём такого нет при загрузке любых файлов через обозреватель или мастер закачек (не торрент).
Из-за чего может быть такой конфликт при работает с торрентами?
emx
Цитата:
Пользовался им раньше исключительно из-за поддержки torrent-файлов огромных по тем временам размеров, а также разбитых на нестандартные/большие части (более 8 мегабайт).
Цитата:
Ну вот и переехал на Deluge...
Пользовался им раньше исключительно из-за поддержки torrent-файлов огромных по тем временам размеров, а также разбитых на нестандартные/большие части (более 8 мегабайт).
Неактуально уже
Страницы: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859
Предыдущая тема: Comodo Firewall Pro / Comodo Internet Security (3)
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.