Печать

[slva2000]

Прошу разработчиков указать, почему инфохэш  серверного списка всех каналов, получаемого https://search.acestream.net/all  часто отличается от конкретного запроса, получаемого https://search.acestream.net/?method=search

Причём, самое печальное, что полный лист трансляций иногда содержит валидные трансляции,  а иногда они валидные при конркетноми запросе. Т.е. не ясно, где данные свежие, а где устаревшие.

[Benny]

почему инфохэш серверного списка всех каналов, получаемого https://search.acestream.net/all  часто отличается от конкретного запроса, получаемого https://search.acestream.net/?method=search

Насколько часто подобное возникает и насколько эта ситуация вопроизводима? Т.е есть пример конкретного infohash для обоих запросов?

[slva2000]

почему инфохэш серверного списка всех каналов, получаемого https://search.acestream.net/all  часто отличается от конкретного запроса, получаемого https://search.acestream.net/?method=search

Насколько часто подобное возникает и насколько эта ситуация вопроизводима? Т.е есть пример конкретного infohash для обоих запросов?

У меня две мысли, по поводу того, насколько часто это возникает:
1. Это возникает редко, но с многочисленными трансляциями
2. Это возникает часто, но с редкими трансляциями.

И первый и второй вариант, не позволяет в любой момент оценить (выявить) баг.

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

Я ранее уже писал об этом, сейчас наткнулся вновь...

[slva2000]

Наблюдаю следующее:

Локальный движок под Windows отдаёт один ContentID по запросу для infohash: 7de20af98b1d1e01be8b395ba2bb5fbb666bd88a
Локальный, но под Linux - другой.
Windows contentID: 20957525c50b009bd78bb20721663fc284a7f178
Linux contentID: 653e951b2ff5138ad88bee82b304e5e6a819959b

Сегодня различные трансляции как с частного запроса (?method=search&api_version=1.0&api_key=test_api_key&query=), так и с общего (all?api_version=1.0&api_key=test_api_key) имеют одно и то же значение availability_updated_at
Имеется ввиду, в рамках одного запроса, вариантов трансляций несколько с разными infohash но одинаковой датой.

При этом дата одинаковая, какая из трансляций рабочая? Или вероятность работы какой трансляции выше?
Какой метод использовать для обновления данных трансляции и как часто это делать?

[Benny]

Локальный движок под Windows отдаёт один ContentID, под Linux - другой.

Версия движка одинакова в обоих случаях?

По остальным вопросам комментарий от разработчика будет чуть позже.

[slva2000]

Windows: v 3.1.8
Linux: v3.1.16 (rev 3258)

[Benny]

Обещанный комментарий:
_______________________________________________________
Разный content id для одного infohash - это в принципе нормально. От ОС не должно зависеть. Движок кэширует транспортные файлы локально, поэтому возможна такая ситуация:
- сделали запрос на content id по infohash на одном движке, движок получил content id и сохранил его в кэш;
- на другом движке сделали такой же запрос, но позже;
- между двумя запросами был сгенерирован новый content id для этого же infohash;
- второй движок получит и запишет в кэш новый content id (так как использует самый последний по времени);
- теперь движки будут отдавать разный content id на один infohash.

Как правило, разные content id для одного infohash генерируются в том случае, когда бродкастер перезапускает трансляцию с измененным списком трекеров, но при этом не меняет другие параметры (остается тот же infohash).
В таком случае более ранние content id будут ссылаться на старый транспортный файл со старым списком трекеров. Однако на запуск трансляции это не должно кардинально повлиять, так как помимо трекеров используется DHT.

По второму вопросу:
Если стоит задача содержать у себя базу данных каналов - то нужно использовать общий запрос (all). Частный запрос предназначен в первый очередь для поиска по названию. Обновлять нужно не чаще, чем 1 раз в час.

Если у нескольких вариантов трансляций одного канала (одно и то же название, но разные infohash) одинаковые значения полей availability и availability_updated_at, то у них одинаковые шансы быть рабочими.

Если одинаковый availability_updated_at, но разный availability - нужно выбирать трансляцию с бОльшим availability.

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

[resentmail@rambler.ru]

Извините, возможно не туда пишу. Перестал работать скрипт "P2P Search"  . Пробовал на разных машинах, с браузерами: Мазила (версию не помню), Google Chrome Версия 70.0.3538.102 (Официальная сборка), (64 бит). Система виндовс. Скрипты установлены, обновлены.  Это у меня одного так? Как теперь контент искать? (

[Benny]

Перестал работать скрипт "P2P Search"

Мы в курсе об этом (проблема в нововведениях у некоторых из политик Гугла), в ближайшее время выйдет обновление для расширения и/или скрипта Р2Р поиска.
Так же проблемы могут быть у пользователей свежей версии Файрфокса с включенным "на максимум" режимом "запрет отслеживания" - в этом случае браузер блокирует "все подряд" - трекеры, счетчики (плюс то, что считает таковым), и все куки.

Пользуйтесь аналогичной функциональностью в Яндексе - там в гуглохроме (пока) работает.

[resentmail@rambler.ru]

в ближайшее время выйдет обновление для расширения и/или скрипта Р2Р поиска.

Заработало, спасибо.