Главная » 2010 » Май » 3 » Некоторые особенности эксплуатации transmission
10:18
Некоторые особенности эксплуатации transmission
Материала много, но статью писать не буду, ограничусь новостью... И так, тестирование данного клиента выявило следующие достаточно важные моменты: 1. Клиент получился достаточно стабильным (за 2 недели постоянной работы ни разу не завис сам, и не повесил плеер) 2. Ложка дёгтя При работе с разделом NTFS при закачке файлов размером больше 4-х ГБ были случаи повреждения этих файлов. Выражалось это так: после останова закачки и старта ее через некоторый промежуток времени клиент стартовал закачку и почти сразу начинал перехешировать торрент, доходил до какого-то значения и не мог сдвинуться дальше, хотя откликался на команды, и нормально работал с другими торрентами. Разбор "полётов" дал следующие результаты: мультипотоковая запись на HTFS в ядре плеера реализована с ошибкой, о чем я уже неоднократно писал. "Спасибо" говорим автору NTFS, зажавшему протоколы и Realtek'у, решившему использовать эту систему. Решение на данный момент только аналогичное rtorrent: использовать для закачки EXT3 раздел и переносить завершенные закачки на NTFS. В конфиге клиента эта задача решается так:
Необходимо помнить, что операция переноса достаточно длительная и ресурсоёмкая. Во время неё могут наблюдаться сильные тормоза интерфейса плеера и отказы сетевых служб. Но тем не менее клиент остается работоспособным. Поэтому - рекомендую использовать для закачки и хранения EXT3 раздел без переноса. 3. Необходимо ограничить максимальное кол-во пиров. И это опять ограничение ядра... По моим наблюдениям - оптимальными являются параметры:
4. Клиент стабилен при отвалах сети на плеере. Но сам перезапустить подключение он не может. Поэтому это приходиться делать вручную из меню плеера 5. Очень радует способность клиента правильно обрабатывать команду kill. Перехеширования активных торрентов после такого отключения не производится. Соответственно, есть повод попробовать подменить скрипт для запуска btpd, что позволит останавливать клиент с помощью пульта. Так же есть в планах задумка увидеть информацию от этого клиента в штатном меню плеера для управления торрентом Параллельно идет работа над меню клиента через RSS-ленту 6. Почему то статистика скорости закачки/отдачи в вэб-интерфейсе отображается скачками. Но, по данным трекера - канал используется на 90%, что действительно соответствует истине. 7. Несмотря на "экономичность" вэб-интерфейса, нет смысла перегружать его лишней работой. Для постоянного мониторинга имеет смысл выставить параметр Refresh Rate 60 секунд. Этого вполне достаточно. 8. Использование "черепашего" режима работы позволяет параллельно смотреть тяжелые ремуксы с того же харда без каких-либо тормозов.
Ну и в итоге: клиент получился очень перспективным, имеет смысл адаптировать его к оболочке плеера, чем я и займусь в ближайшее время
При работе с разделом NTFS при закачке файлов размером больше 4-х ГБ были случаи повреждения этих файлов. Выражалось это так: после останова закачки и старта ее через некоторый промежуток времени клиент стартовал закачку и почти сразу начинал перехешировать торрент, доходил до какого-то значения и не мог сдвинуться дальше, хотя откликался на команды, и нормально работал с другими торрентами. Разбор "полётов" дал следующие результаты: мультипотоковая запись на HTFS в ядре плеера реализована с ошибкой, о чем я уже неоднократно писал. "Спасибо" говорим автору NTFS, зажавшему протоколы и Realtek'у, решившему использовать эту систему. 
Параллельно идет работа над меню клиента через RSS-ленту 
