Статическая сборка библиотеки python-libtorrent

[DiMartino]

Сообщение от Roman_V_M

Здесь: https://cloud.mail.ru/public/500daa2...libtorrent.zip
Согласно моим опытам 1.0.3 качает быстрее.

Можно небольшой совет? Никогда не используйте инструкцию except без указания конкретных исключений, которые вы ловите. Иначе потенциально возможны проблемы при отладке.

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

Один раз у slng ломался плагин из-за ловли эксепшенов, потому что он ловил отсутствие модуля, а приходила ошибка версии питона, в итоге плагин он уже тогда забросил и никто не чинил. Можно так:

PHP код:

            except Exception, e:
                print 'Error importing python_libtorrent.'+system+'. Exception: ' + str(e)
                pass 


[HAL9000]

Сообщение от Roman_V_M

Разрядность скомпилированного модуля должна совпадать с разрядностью Питона, а поскольку официальной 64-битной версии Коди под Винду не существует, то и 64-битный либторрент не нужен, т. к. его некуда применить.

Согласен. Все верно.

Сообщение от Roman_V_M

Компиляцию лучше проводить на чистой винде ХР/7 под виртуалкой.
Выполняете инструкцию отсюда до п. 5 включительно. В качестве компилятора устанавливаете VC++ 2008 Express (можно скачать с сайта Майкрософта).
После установки всех компонентов и компиляции Буста у вас должны быть следующие папки:
c:\OpenSSL-Win32\
C:\boost
C:\libtorrent-rasterbar
Далее выполняете следующий батник:

@echo off

copy "c:\OpenSSL-Win32\lib\VC\static\libeay32MT.lib" "C:\Program Files\Microsoft Visual Studio 9.0\VC\lib\libeay32.lib" /y
copy "c:\OpenSSL-Win32\lib\VC\static\ssleay32MT.lib" "C:\Program Files\Microsoft Visual Studio 9.0\VC\lib\ssleay32.lib" /y
copy "C:\OpenSSL-Win32\include\openssl" "C:\Program Files\Microsoft Visual Studio 9.0\VC\include" /y

call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86

set BOOST_ROOT=C:\boost
set BOOST_BUILD_PATH=%BOOST_ROOT%
set PATH=%BOOST_ROOT%;%PATH%

c:
cd C:\libtorrent-rasterbar\bindings\python

b2 boost=source link=static geoip=static boost-link=static runtime-link=static release optimization=space encryption=openssl

Если всё сделано правильно, в папке C:\libtorrent-rasterbar\bindings\python должен быть скомпилированный модуль.

Прикреплю этот текст в шапке этой ветки.

[HAL9000]

У меня пока таже ошибка (все еще вожусь с linux64): Просит ключик -fPIC
Но, проблема в чем-то другом, так как этот ключ нужен для скрещивания статических либ с динамическими. А нам это не нужно.

И еще: без питоновской обвязки все нормально компилиться. Сейчас выложу в шапку последнюю свою версию (основана на libtorrent-go). Если убрать из буста ключик --with-python и из libtorrent ключик --enable-python-binding, то все компилиться без единого чиха. А вот с ними начинается беда...

[Roman_V_M]

Сообщение от DiMartino

Класс Torrent стримит так: создает сессию, подключает dht, добавляет торрент, обнуляет приоритет всех кусков, высчитывает первый и последний кусок файла, выставляет приоритет первый+сколько скажут в МБ и два последних, set_sequential_download, полностью скачивает буфер, МЕГАКОСТЫЛЬ, начинает играть и ставит все остальные куски в скачку.

Почитал тут на досуге некоторые теоретические статьи, посвященные стримингу торрентов. В них утверждается, к примеру, что set_sequential_download() скорее вредно, чем полезно (как ни странно). Т. е. лучше всего играться приоритетами кусков.
На основании этих статей также попробовал реализовать алгоритм "скользящего окна" (правда, в упрощенном виде) - вроде как получилось. В общем, как оказалось, в реализации стриминга торрентов нет ничего сложного.

Кстати, так до сих пор и не понял, зачем нужен мегакостыль.

[DiMartino]

Сообщение от Roman_V_M

Почитал тут на досуге некоторые теоретические статьи, посвященные стримингу торрентов. В них утверждается, к примеру, что set_sequential_download() скорее вредно, чем полезно (как ни странно). Т. е. лучше всего играться приоритетами кусков.
На основании этих статей также попробовал реализовать алгоритм "скользящего окна" (правда, в упрощенном виде) - вроде как получилось. В общем, как оказалось, в реализации стриминга торрентов нет ничего сложного.

Кстати, так до сих пор и не понял, зачем нужен мегакостыль.

Без мегакостыля одно и тоже видео то запускалось, а то нет. Прям вот запускаешь стриминг, скачался буфер, запустилось. Удалил буфер, опять повторил все, уже не запустилось. Причем это проблема была сугубо у xbmc.Play() и подобных команд, тот же кусок прекрасно каждый раз открывался с помощью VLC, а XBMC с помощью xbmc.Play() рандомно его не мог проиграть, но при заходе в папку с помощью "Файлы", xbmc.Play() тоже начинал его проигрывать, даже если зайдя в папку просто на него грозно посмотреть.

[HAL9000]

Сообщение от Roman_V_M

Почитал тут на досуге некоторые теоретические статьи, посвященные стримингу торрентов. В них утверждается, к примеру, что set_sequential_download() скорее вредно, чем полезно (как ни странно). Т. е. лучше всего играться приоритетами кусков.
На основании этих статей также попробовал реализовать алгоритм "скользящего окна" (правда, в упрощенном виде) - вроде как получилось. В общем, как оказалось, в реализации стриминга торрентов нет ничего сложного.

Кстати, так до сих пор и не понял, зачем нужен мегакостыль.

Все так и есть.

set_sequential_download() сама по себе работает плохо. Хотя для проформы включать ее можно. После того, как начинаешь "играться" с приоритетами кусков, она вряд-ли будет на что-то влиять. В общем, включить ее можно из соображений "кашу маслом не испортишь".

По поводу приоритетов кусков - это единственный способ организовать стриминг видео-торрентов. Теперь, когда вы Roman_V_M разобрались как это работает, то наверника понимаете почему "сбоят" все плагины с торрент-плеерами. Какой-то кусочек не нашелся в p2p-рое и все - сбой воспроизведения.

Единственная возможность приблизиться к "потоковому качеству" - это четко расчитывать сколько кусочков нужно прямо сейчас xbmc-плееру. Чтобы в нужный момент поставить воспроизведение на паузу и дождаться когда недостающий кусочек придет из роя.

И вот тут включается "математика", которой задолбаешься заниматься. Нужно разбираться во всех видео-форматах, чтобы понимать сколько кусков нужно прямо сейчас.
Исходя из этих форматов как-то надо расчитывать прогноз когда доступных кусков станет уже мало для xbmc-плеера (чтобы вовремя поставить на паузу - плеер xbmc не отличается моментальной отзывчивостью к своему API). Прогнозируя это, нужно брать во внимание текущую личерскую скорость скачки. Размер файла. И т.д.

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

В общем, создание торрент-плеера - вещь интересная, но сложная. Достойна отдельного проекта.

Что у меня есть из наработок?

Есть DelugeStream. Заброшенный мной. Мечтаю найти время вернуться к нему. Вернее не к самому проекту, а только к части, которая занимается контролем libtorrent. Если скомпилим libtorrent - точно вернусь Если не скомпилим до конца зимы, все равно наверное постараюсь вернуться к проекту - буду писать питоновскую часть плеера с надеждой на появление на форуме какого-нибудь Джеймс Бонда, который скажет "Скомпилить libtorrent? Да я это перед сном каждый день делаю!".

Если интересно, то работа с приоритетами кусков запрограммирована там в функции update и, следующей за ней, prioritize_up. Там, конечно, еще надо допиливать, но сделано очень много. Включая поддержку просмотра отдельных серий в сериальной раздаче, поддержку сразу одновременной закачки нескольких раздач (для одновременного просмотра с разных устройств разного контента) и многое другое. Если будут вопросы по коду или неясности в стиле "зачем там что-нибудь сделано", пишите - я отвечу.

P.S.:
Оффтоп:
Торренты не предназначены для потока. И НИКОГДА не будут для этого предназначены. Повышенный интерес к этой технологии существует исключительно из-за мегатонны контента, который доступен на трекерах. Как только в таком же объеме будут представленны обычные пиратские сайты, смысл в торрент-плеерах пропадет.

[DiMartino]

Сообщение от HAL9000

Если интересно, то работа с приоритетами кусков запрограммирована там в функции update и, следующей за ней, prioritize_up. Там, конечно, еще надо допиливать, но сделано очень много. Включая поддержку просмотра отдельных серий в сериальной раздаче, поддержку сразу одновременной закачки нескольких раздач (для одновременного просмотра с разных устройств разного контента) и многое другое. Если будут вопросы по коду или неясности в стиле "зачем там что-нибудь сделано", пишите - я отвечу.

По сути вопроса мне нечего сказать, просто хочу донести мнение некого arvid.no...@gmail.com, что для стриминга лучше использовать set_piece_deadline(). Большой разницы с постоянной сменой приоритетов нет, но раз уже задумали так.

[HAL9000]

Сообщение от DiMartino

По сути вопроса мне нечего сказать, просто хочу донести мнение некого arvid.no...@gmail.com, что для стриминга лучше использовать set_piece_deadline(). Большой разницы с постоянной сменой приоритетов нет, но раз уже задумали так.

Не обращал раньше внимание на эту функцию. Хотя на первый взгляд из документации не понятно, чем она лучше piece_priority().
Но раз чувак из команды libtorrent рекомендует использовать именно ее, то надо разбираться с ней.

[DiMartino]

Сообщение от HAL9000

Не обращал раньше внимание на эту функцию. Хотя на первый взгляд из документации не понятно, чем она лучше piece_priority().
Но раз чувак из команды libtorrent рекомендует использовать именно ее, то надо разбираться с ней.

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

[HAL9000]

Сообщение от DiMartino

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

А я ушел от этих алертов. Они есть в Torrenter и в RuTracker (я писал там плеер, подсматривая в Torrenter). Но DelugeStream уже писал без них. Схему подсмотрел у какого-то популярного плагина для Deluge. В цикле постоянно идет опрос статуса раздачи (вся инфа по всем кускам) и с каждой итерацией цикла заново рассчитываются дальнейшие действия.

Что лучше? Не знаю. Ни у первого, ни у второго способа не вижу никаких особенных плюсов или минусов.