Обновить
-7
Олег@Master255read⁠-⁠only

Программист

9
Подписчики
Отправить сообщение
1) Там по моему ясно написано: «1) Based on standart player. Easy to use with different other player, but! Not recommended;»
http запросы от любого плеера парсятся и ответ приходит в таком же (http) формате. Это очень унифицированно и подойдёт для любого http плеера. Наверное вы не правильно поняли. Там есть класс стандартного плеера, но он, как опция.

2) На гитхабе большая часть библиотек без тестов и что теперь? Не использовать их?))

3) Для меня этот код, как детский стих. Ничего там нет сложного, если понимать, что происходит. Я думаю написать можно только так. И если код ещё выносить в сторонние процедуры, то будет только сложнее. Я пишу наиболее сжато, максимально компактно и с использованием минимума быстрейших операторов. Да и чего вам надо? Статью написал, картинки сделал, код опубликовал. Вопросы есть? — задавайте! На русском языке даже отвечу)) О чём ещё можно мечтать???

4) Где пустые catch блоки — значит так надо. Там некоторые ошибки будут специально происходить. Им catch не нужен, но без него нельзя. Что бы говорить об огрехах нужно разобраться сначала. А вы лезете со своим уставом в чужой монастырь. Не надо так.

5) Всё просто. Сначала меняешь класс плеера в моём проекте. Запускаешь, проверяешь. Если всё работает, то меняешь настройки под себя, которые задаются в setPaths. Проверяешь. Если всё работает, то можно переносить код в свою программу.
В моём классе плеера есть пара лишних строчек для демо. О чём там ярко написано в комментариях и эти строчки легко можно найти и удалить. А класс плеера, я очень долго отлаживал. В нём собрано всё лучшее от Exoplayer, Vitamio и других… и пока похожего я не видел ни у кого.
Теоретически с помощью прокси можно даже формат видео преобразовывать налету в телефоне))). Так что простор для творчества такой большой, что вам и не снилось.
что не так с решениями в коде?
Модуль постоянно обновляется т.к. используется в программе.
Почему раньше никто не додумался до этого???
а у меня тоже что-то не срослось с ней и я сделал свой проект на протоколе nmdc (dc++). Вот: github.com/master255/ImmortalPlayer
по какому принципу? Подсоединяется и ищет или сразу подсоединяется ко всем и ищет? Или как?
почему редкие файлы долго ищет? Дальше лежат?)). По какому принципу долго ищет?
вы не правы.
Одно дело я отправил поиск хабу, а он пересылает другим и другим и ждёт ответы…
Не знаю как там это реализовано, но сами подумайте — загруженный хаб пересылает другому хабу — тот пользователям и другим хабам… Какая будет скорость первого ответа???
Или я подключён к 3 хабам в которых много петабайт данных. Задаю запрос… и сразу получаю от всех трёх ответы. Ясно и понятно.
А в вашей взаимосвязанной сети нет децентрализации. Рухнет связующий хаб и не будет связи между сегментами сети. И быть подключенным к 100 хабам — это всего лишь держать открыто 100 портов. Парсить поступающие данные не обязательно! Только приветствие и всё. А это быстро и одновременно можно делать.
К тому же я пишу программу не для вашей страны, а на весь мир. А это значит должен быть выбор у пользователя.
И программа будет не только получать данные, но и отдавать. Это значит нужно что бы все сидели примерно в одном хабе, а не в сети хабов. DHT — это уже следующий шаг. Я ещё не дошёл.
Результаты поиска будут скорей всего состоять из пользователей программы. Так что точно не интересует ваша гнутелла.
в какое время прилетает первый ответ на поиск?
Думаю не сложно будет оптимизировать мою программу и под этот протокол
ну есть наверное такие. Но в моей программе хабы можно будет выбирать и я пропишу туда нормальные хабы наверное… а не с регистрацией.
Клиент моей программы — это чат бот. И там никаких фич не зарублено. Он просто и быстро качает файлы без помех!
Да что говорить. У меня есть программа, которая делает то о чём я говорю.
Вот github.com/master255/ImmortalPlayer
30 секунд ожидание — это для того что бы собрать как можно больше ответов. Что бы ответы не накладывались друг на друга. А не для того что бы ждать пока там ответят. Первые ответы прилетают сразу.

Моя программа авторизуется и воспроизводит видео прямо от пользователей из поиска. Причём, сразу… без задержек. Если имя занято, то к имени прибавляется номер. И так несколько раз. Я разобрался в протоколе NMDC, а вы разобрались, что бы что-то утверждать?
Рубль теряет стоимость. Берите один, но большой диск. Ещё можно взять Crucial CT960M500SSD1
M500, для ноутбука, 2.5", SATA 6Gb/s, SSD (твердотельный), 960 Гб за 19 000 рублей. Поверьте, через месяц он будет стоить дороже.
Я себе ещё летом успел взять за 15 000 750гб от samsung. И очень рад, что купил его. За пол года торрентов и обычного ежедневного пользования 4ТБ записано всего. Ресурс больше 1000 кажется. Т.е. хватит точно до следующего апгрейда. Или выхода новой технологии.
в чём тогда разница с DC++? Зачем нам нужен второй такой же протокол? Но менее распространённый.
отличная фича. Думаю текстовый поиск прикрутят в скором времени. Поиск по tth — тоже хорошая штука.
вот я говорю про конкретно то что у меня получилось сделать. У меня получилось подключиться к любому крупнейшему хабу и отправив поисковой запрос без регистрации получить ответы… и даже имея глубоко серый ip адрес открыть соединение и скачать нужный файл с пользователей, без каких-либо ограничений и с максимальной скоростью.
А если меж хабами была какая-то связь, то предполагаю забаненый человек на одном хабе становился забаненным на всех. Что мешает это сделать? Собственно и сейчас ничего не мешает доработать ПО хабов, для авторизации на других хабах и получения информации… но видимо разработчики думают о свободе распространения информации больше, чем о выдаче в поиске. И они правильно делают! Мне как разработчику крайне неудобно ждать по 30 секунд ответа других хабов. В текущем хабе результаты выдаются практически сразу. 300мс — 1,5с. задержка. И это комфортно. А к каким хабам подключиться — это моё дело.
Кстати автоматизировать регистрацию на хабах тоже проще простого. Но и без этого всё работает!
Всё я это к тому что DC++ (nmdc) можно использовать, как CDN! причём, если правильно написать реализацию, то получится даже круче по пропускной способности.
Ничего мутного в протоколе нет, если найти нормальную вики. Я разобрался за пару дней и теперь могу качать файлы хоть через telnet)))
посмотрел Gnutella2. Недостатки:
низкая распространённость
Что бы поискать файл нужно установить несколько соединений. Т.е. сначала получить список хабов. Потом соединиться с парой… и уже после этого начать поиск… Причём поиск будет длиться неизвестно сколько! Так как происходит опрос по какой-то сложной логике…
В DC++ я соединяюсь один раз с хабом. Поиск происходит максимально быстро т.к. я получаю ответы от самих клиентов в общем чате. Никаких списков при этом мне не нужно знать… тупо подключился… кинул поиск… отпарсил ответы… подключаюсь напрямую и качаю… что может быть лучше???

Ну и разные прибамбасы лишние Gnutella2 — это кадры, комменты…
Недостатки я копнул поверхностно… но мне их уже хватает что бы не работать с этим протоколом.

А в dc++ я бы общий чат хаба перевёл на xml. Так парсинг и поиск ускорился бы вдвое… если не в 10 раз))
Вот и всё.
в том то и дело — смущает! Я делаю программу для всего мира. А эти ребята не известно откуда доступны и где вообще заблокированы. А завтра они перестанут работать и что? Мне сказать пользователям — всё — теперь ещё месяц разработки для допиливания поддержки другого сайта?
Нет. Так не пойдёт.
открыл новости финансов и увидел, что из-за падения цен на нефть закрывается много добывающих вышек. Т.е. в будущем, возможно, сложится ситуация что нефти резко будет не хватать. А потом опять стоимость понизится и часть закроется. Такая ситуация отбойным молотком поднимет любую компанию, которая производит элетро-кары.

И, например, я — поездив даже на тоётовском Приусе уже никогда не сяду за руль чисто бензинового автомобиля. Это надо попробовать, что бы понять. Автомобили Тесла для меня — это фантастическая мечта о которой я пока даже не мечтаю…
Я пишу программу, которая иногда получает файлы из p2p сети. Так вот когда выбирал из какой сети она будет брать файлы понял, что в торрентах совсем нет поиска, встроенного в протокол. Т.е. там есть поиск по хэшу торрент файла (самого .torrent файла) или по хэшу частей содержимого, но не самого искомого файла. Парсить веб страницы для меня выглядит очень уродливо. Даже получение результатов поиска через api какого-либо сервиса — выглядит убогостью по сравнению с тем что есть в DC++.

В DC++ это всё в текстовом виде. Поиск встроен в протокол. TTH — одна из лучших реализаций хэша. Подключиться к хабу и качать файлы можно даже через telnet! Как разработчик я доволен. И для меня это жирный минус торрентам в перспективе.
с использованием нано-роботов можно уничтожать любые вирусы, бактерии и прочее…
И обходить любую резистентность тупо механическим путём — палкой по голове бактерии))
Но к сожалению почему-то исследования в этой отрасли практически никто не ведёт. Наверное бояться открыть лечение от всех болезней. И поверьте всё именно так, как я говорю. Это не сказка! Это вполне реальные вещи.
А мне больше всего нравятся эргономичные решения. Например microsoft ergonomic sculpt mouse — под правую руку и razer deathadder left hand edition под левую у меня. Microsoft купил две мышки. Одну домой, другую на работу. Батарейки уже пол года работают, как бесконечные. Недостатков нет!

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность