>Ну вот я, например, предпочитаю LinuxDC++. Вполне сознавая, что eiskalt более технически продвинут.

Почему?

Ведь в LinuxDC++ даже основные функции: поиск и скачивание нереализованны полноценно - в поиске нет группировки совпадающих результатов, нет фильтра по результатам поиска, в скачивании качает только с одного источника, до того момента как выполнится поиск альтернатив, который на некоторых хабах вообще ограничен по частоте использования несколькими часами.

Ещё один момент это поддержка UPnP - сейчас почти у всех дома используются роутеры, т.к. компьютеров обычно несколько, а в LinuxDC++ нет поддержки UPnP. Хотя можно и вручную конечно в настройках роутера для каждого компьютера порты открыть, но это не самая лёгкая задача для простого пользователя, а с UPnP только галочку в настройках клиента поставить и всё работает.

Кстати, помнится в предыдущих релизах была проблема с «ручным» поиском из-за этого автоматического поиска альтернатив:

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5801583

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5801677

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5803922

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5803952

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5803999

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5804005

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5804022

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5804026

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5804031

Гм. Тогда надо попробовать.

>А что, в EiskaltDC++ альтернативные источники не через TTH ищутся, что ли?

Речь не об этом, а о том что после выполнения поиска в LinuxDC++ результаты не сгруппированны по TTH и если ставишь на закачку какой-либо результат поиска то скачивание начинается только с одного источника, и только спустя несколько минут выполнится поиск по TTH и добавятся остальные источники, а если на хабе ограничение на частоту поиска через TTH раз в два часа то LinuxDC++ так и будет качать с одного источника.

А в EiskaltDC++ после выполнения поиска результаты сгруппированы по TTH и если поставить на закачку такую группу то загрузка начинается сразу со всех источников из этой группы, а через некоторое время как и в LinuxDC++ выполняется поиск по TTH который добавит новые источники если они появились за прошедшее время.

>Ведь в LinuxDC++ даже основные функции: поиск и скачивание нереализованны полноценно - в поиске нет группировки совпадающих результатов

По-моему, ты ошибаешься: все есть. Но проверить смогу вечером только, если тебе по-прежнему будет интересно, то отпишусь.

нет фильтра по результатам поиска

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

в скачивании качает только с одного источника, до того момента как выполнится поиск альтернатив, который на некоторых хабах вообще ограничен по частоте использования несколькими часами.

Поиск альтернатив, как я понимаю, в LinuxDC++ ведется при любом последующем ручном поиске. С одной стороны, это менее удобно (хотя, обычно в локалке скорость скачки и так высокая), с другой — нет проблем с обломом ручного поиска, как в моих ссылках выше. А на хабах с ограничением по частоте использования TTH-поиска, как я понимаю, Eiskalt тоже обломать должно.

Ещё один момент это поддержка UPnP - сейчас почти у всех дома используются роутеры, т.к. компьютеров обычно несколько

Ну у меня роутера точно нет (за ненадобностью). Честно говоря, я сомневаюсь, что это они действительно почти у всех дома есть, видимо, это особенность твоей выборки.

имеющий некоторый tth, ни у кого в локалке нету, а в инете через dht нашлось, качаем с инета.

а что значит с нета? с какого типа сети? не с торрента же.

Настройки - шара - использовать быстрый кэш.

[внезапно] это по умолчанию и стояло. valknut быстро хэшировал и не тормозил, а это даже с приниженной скоростью тормозит адски.

Всё перечисленное можно найти, надо подключится к нескольким крупным хабам, например, вот список русских хабов http://dchublist.ru/hubs/ и искать. Только обычно для поиска и скачивания надо иметь свою собственную шару размера большего чем минимально разрешённый, который варьируется для различных хабов. Как правило, большинство хабов настроенны так, что чем больше ты расшарил тем больше получаеш бонусов, например, чаще можно пользоваться поиском, в том числе и автоматическим, а это приводит к увеличению источников, ну и у некотрых стоит ограничение на размер шары для качающих, так что если шара слишком маленькая то ничего скачать будет нельзя.

http://www.linux.org.ru/jump-message.jsp?msgid=5799703&cid=5804026

Зато обычный (ручной) поиск это иногда и правда «обламывает», было бы и правда неплохо сделать такую фишку с таймером и ожиданием истечения интервала времени для начала поиска.

Если нужны какие-либо расширения или исправления ошибок то надо заводить issue здесь http://code.google.com/p/eiskaltdc/issues/list

Нет issue на багтрекере - нет проблемы, т.е. все голословные высказывания без оформления на багтрекере скорее всего будут проигнорированы.

>>Ведь в LinuxDC++ даже основные функции: поиск и скачивание нереализованны полноценно - в поиске нет группировки совпадающих результатов

По-моему, ты ошибаешься: все есть.

В LinuxDC++ 1.1.0 есть, и при добавлении группы в очередь скачивает со всех источников.

>Поиск альтернатив, как я понимаю, в LinuxDC++ ведется при любом последующем ручном поиске. С одной стороны, это менее удобно (хотя, обычно в локалке скорость скачки и так высокая), с другой — нет проблем с обломом ручного поиска

Не при любом, а при поиске по такой поисковой фразе, что файлы находящиеся в очереди по ней бы нашлись, например если в очереди есть фильмы со строкой «2011» в имени, то при поиске строки 2011 для них найдутся источники, кстати такой же эффект будет в любом клиенте на ядре DC++, в том числе и на Windows клиентах.

нет проблем с обломом ручного поиска

Это почему же? - Проблема никуда не денется: если перед моментом ручного поиска LinuxDC++ выполнит автоматический поиск альтернатив, то естественно что ручной поиск ничего не даст, и никаких сообщений о причинах отсутствия результатов не выведет. Также никаких сообщений о причинах отсутствия результатов поиска не будет если делать ручные поиски слишком часто. И разве хоть один Windows клиент выводит сообщение о причине?

С того же типа сети, DHT может найти по нодам нужный файл у какого-либо клиента DC++ с поддержкой DHT(а это все клиенты основанные на StrongDC++) причём поиск по нодам не ограничивается пользователями с текущего хаба, т.е. найденые источники возможно окажутся не с текущего хаба и соответственно скачивание будет идти не с локалки, а с интернета. Поэтому по умолчанию DHT поиск будет отключён чтобы не навредить пользователям на лимитных интернет тарифах.

ишь чего придумали :) а может оно вообще и без подключения к какому то хабу может работать? просто magnet/хэши с форумов брать (есть такие дополнения для движков). типа и торрент не нужен.

Минорщина?

сабж

>а может оно вообще и без подключения к какому то хабу может работать?

возможно и сможет если переделать кое-что в ядре, по крайней мере подключение к хабу не требуется, для функционирования клиента в качесве узла в DHT сети, т.е. файл с нодами заполняется новыми нодами без хаба.

>>а может оно вообще и без подключения к какому то хабу может работать?

возможно и сможет если переделать кое-что в ядре, по крайней мере подключение к хабу не требуется, для функционирования клиента в качесве узла в DHT сети, т.е. файл с нодами заполняется новыми нодами без хаба.

Не возможно, а точно сможет.
Надо было сразу правильную ссылку давать:
http://www.adcportal.com/wiki/StrongDC++_DHT

Ссылку давал не я.

К тому же вопрос заключался в том можно ли будет просто кликнув по magnet-ссылке в браузере запустить EiskaltDC++ и чтобы он начал поиск через DHT, а затем и скачивание найденного файла, при условии что в автозгрузке нет ни одного хаба, и не подключаясь ни к одному хабу.

Поддерживаю. Кэширование в этом клиенте - головная боль, из-за этого у себя расшарил всего 5 гигов, что бы для поиска хватало. Да и эти 5 чуть ли не весь день кэшировало.

>Поддерживаю. Кэширование в этом клиенте - головная боль, из-за этого у себя расшарил всего 5 гигов, что бы для поиска хватало. Да и эти 5 чуть ли не весь день кэшировало.

То что система подтормаживает при хешировании на старых компьютерах это действительно так, можно убрать этот эффект уменьшив размер буфера или уменьшив максимальную скорость в настройках хеширования.

Да и эти 5 чуть ли не весь день кэшировало.

Это с какой же скоростью выполнялось хеширование? Даже если ограничить скорость хеширования до 10 мегабайт в секунду, то 5 гигабайт прохешируются меньше чем за 10 минут.

Минутка политпросвещения

>Кэширование

Не надо путать хэширование и кэширование.

Кэш — промежуточный буфер с быстрым доступом, содержащий информацию, которая может быть запрошена с наибольшей вероятностью

Хэширование — преобразование входного массива данных произвольной длины в выходную битовую строку фиксированной длины. Такие преобразования также называются хеш-функциями или функциями свёртки, а их результаты называют хешем, хеш-кодом или дайджестом сообщения

Да и эти 5 чуть ли не весь день кэшировало

Как обладатель шары более терабайта, позволю себе усомниться в ваших словах.

Поддерживаю. Кэширование в этом клиенте - головная боль, из-за этого у себя расшарил всего 5 гигов, что бы для поиска хватало. Да и эти 5 чуть ли не весь день кэшировало.

вот прямо сейчас такая фигня. скорость хэширования 1.6 МиБ/с , 3% 303:55:XX осталось. ему гарантированно ничего не мешает.

То что система подтормаживает при хешировании на старых компьютерах это действительно так, можно убрать этот эффект уменьшив размер буфера или уменьшив максимальную скорость в настройках хеширования.

не надо выдумывать. valknut и другие p2p хэшируют (причём быстро) и ничего не тормозит. а именно этот клиент тормозит всю систему.

> не надо выдумывать. valknut и другие p2p хэшируют (причём быстро) и ничего не тормозит. а именно этот клиент тормозит всю систему.

Телепатов тут нет. Конкретизируй особенности своей системы.
С какого раздела происходит хэширование? Какой стоит приоритет у процесса?
Изменялись ли дефолтные настройки хэширования? Если да, то как?

Может быть ты с нфс или самбы файлы хэшируешь с другого компа.
В этом случае есть некоторые особенности.

Проблема у тебя какая-то локальная и с ней нужно разбираться.
У других пользоватей заметных «тормозов» не наблюдается, насколько мне известно...

Конкретизируй особенности своей системы.

никаких особенностей нет. просто всё остальное, в том числе многочисленные p2p, в том числе работающие в Wine, не тормозят.

Изменялись ли дефолтные настройки хэширования? Если да, то как?

и не менялись. потом менялись. я писал ведь - снижал до 20 МиБс - всё тоже самое - тормозит систему.

Может быть ты с нфс или самбы файлы хэшируешь с другого компа.

нет, нет и нет. ничего такого нет.

Проблема у тебя какая-то локальная и с ней нужно разбираться.

у меня нет локальной проблемы и вообще никакой.

вот прямо сейчас такая фигня. скорость хэширования 1.6 МиБ/с , 3% 303:55:XX осталось. ему гарантированно ничего не мешает.

остановил. вышел из программы. вошел. продолжил - хешируют под 20 МиБс (как поставил в ограничениях), система адски тормозит - при написании этого текста система замирала несколько раз (GUI не отвечал)

12309 :)

С другой стороны, дискетами некоторые тоже пользуются... =)

система адски тормозит

Это тебе кара небесная за излишнюю любовь к CUE.

> вот прямо сейчас такая фигня. скорость хэширования 1.6 МиБ/с , 3% 303:55:XX осталось. ему гарантированно ничего не мешает.

подозреваю что ему мешает 12309 :)

Плагиатор)

> Добавлены новые команды чата: /ip (правила IPFilter), /ratio, /version

а у меня /version и в 2.2.2 есть.

а у меня /version и в 2.2.2 есть.

В личном чате не было.

>это gcc-4.6

tnx, it works! Еще бы разобраться как брандмауэр настроить правильно...