Перейти к публикации

mariman

Главные администраторы
  • Публикации

    118
  • Зарегистрирован

  • Посещение

Все публикации пользователя mariman

  1. mariman

    Error when calling login REST API POST method

    You should set parameter sotfid=dev-test-000 and cli_serial with serial number of device. Perhaps, you set undefined values as default.
  2. mariman

    Перемотка в архиве

    архив - не файл. В отличии от ВОД. Это поток. У него нет длины. Вам на каждую позицию придется по-новой запрашивать get_url и рассчитывать параметр gmt.
  3. по всей вероятности, установлен стандарт вещания DASH. Просьба скинуть номер або в личку.
  4. Нету. Что мешает сохранять результат channel_list и его использовать?
  5. Спасибо за сообщение. будем разбираться. Метод считается устаревший, но из соображений совместимости работать он должен. Насчет device=apple В рамках введения API v2 правильно было бы использовать параметр stream_standard для включения режима apple устанавливается так: /settings_set?var=stream_standard&val=hls_h264 Но его использование обусловлено полученным softid (задается при логине). Если softid устройства не поддерживает hls вещание, то переключиться не удастся. Также желательно передавать серийный номер устройства (параметр cli_serial при логине), тогда установленные параметры будут установлены только для этого устройства. Кстати, возможно вы не указали softid для при логине и система берет дефолтный softid в котором запрещен hls.
  6. Чтобы получать DASH ссылки вещания, необходимо: 1. сделать логин (/login?login=...&pass=...) с параметрами серийного номера &cli_serial=... *(см. ниже) и &softid=..., указывающим на устройство, поддерживающее стандарт DASH ** (см. ниже). Список поддерживаемых стандартов вы получите в блоке stream_standard ответа, там же доступные сигнатуры. Для DASH соответствует dash_hevc. 2. сделать переключение методом /settings_set&var=stream_standard&val=dash_hevc Далее работа с каналами и линками через методы /channel_list и /get_url в обычном режиме. Обязательно убедитесь, что в спецификации Вашего устройства имеется поддержка HEVC (H.265) * Серийный номер необходим для того, чтобы запомнить настройки або (конкретно stream_standard) именно для этого бокса. Если логин сделать БЕЗ указания серийного номера, все настройки будут сохранены как "глобальные" и будут отдаваться в том же виде для ВСЕХ устройств, не имеющих серийного номера этого або, что может привести к неоднозначным ситуациям. ** Параметр softid является идентификатором врсии ПО устройства, который присваивается нами по соответствующему запросу на емейл. К этому параметру привязываются многие возможности и настройки, настройка стандарта вещания в частности. Для разработчиков предусмотрен тестовый softid = dev-test-000 . Для этого softid включены все возможные стандарты вещания. При продакшн выпуске своего ПО, необходимо пройти тестирование (мониторинг запросов на стороне сервиса) и получить реальный softid. Как видите, - не сложно. Удачи! Ждем интересных релизов приложений.
  7. Оффтоп. Я дал ответ по теме. Затронутая Вами тема обсуждается в другой ветке компетентными в этом вопросе людьми.
  8. Опишу проблему. Относительно недавно (чуть больше года назад), мировым сообществом было принято решение отказаться от SSL на базе SHA1. пруф: https://googleonlinesecurity.blogspot.de/2014/09/gradually-sunsetting-sha-1.html https://www.emaro-ssl.ru/blog/sha1/ Подобное требование выдвинули все ключевые IT компании (Google, Microsoft, Apple, IBM, Intel ...) Новые версии браузеров (и библиотек реализующих функции браузера) перестают считать соединение шифрованное SHA1 безопасным и, в некоторых случаях, прекращают работу с таким сайтом. Чтобы обеспечить бесперебойную работу всех клиентов, возникла необходимость перейти на новый сертификат SSL (SHA-256) Новая прошивка дюны для Картина.ТВ содержит обновленный SSL бандл. Вам необходимо либо дождаться обновленния стоковой прошивки Дюн, либо использовать картиновскую прошивку с уже встроенной поддержкой новых сертификатов.
  9. На данный момент вопрос еще обсуждается. О результатах в ближайшее время сообщим.
  10. Думаю, следует немного пояснить насчет UDT. Это немного видоизмененный UDP, который не шлет в ответ запросы на коррекцию ошибок а, берет недостающие данные с избыточного потока. Грубо говоря, это для тех у кого интернет достаточно широкий но пинг дает ощутимые задержки. Если географически вы в другом конце земли и канал у вас шире чем положено (ширина стандартного вещания + % равный %% ошибок), вы все-таки сможете видеть достаточно стабильную картинку. В остальных случаях смысла переходить на UDT особо нет.
  11. Молодой человек, домыслами занимаются на других форумах, формат которых позволяет фривольные высказывания. Вам дали четкий развернутый ответ.
  12. Если честно рисковать не хочется, просто много было написано и не было выполнено,жалко потом будет выкинуть приставку. Вы лучше доработали плагин со всеми новинками сервиса. Мы дорабатываем только наши плагины (на наших прошивках) Мы можем только рекомендовать производителям Дюн поскорее внести изменения в стоковый вариант прошивки.
  13. Да, для владельцев с оригинальной прошивкой картины это обновление коснется в первую очередь. Что касается оригинальной дюнЫ, думаю, этот вопрос не в нашей компетенции. В свою очередь, мы заинтересованы в нормальном распространении нашего сервиса и будем всячески способствовать.
  14. В рамках API v2 реализован механизм переключения стрим-стандартами. Выглядит как еще один параметр для /settings?var=stream_standard Кроме того, бокс обязан при логине посылать параметр softid и уже от этого параметра зависит список доступных стримстандартов. В зависимости от стримстандарта, get_url будет возвращать нужные ссылки вещания. Этот механизм позволит в дальнейшем оперативно добавлять различные стандарты. Активно идет подготовка к эксплуатации стантарда DASH c H.265. Чище картинка, меньше трафика, адаптивный битрейт. Но клиентское оборудование должно быть с аппаратной поддержкой этого кодека и пройти соответствующие тесты. С нашей стороны мы присваиваем соответствующий softid и прописываем ему возможные стримстандарты.
  15. управление каналами описано в API и некоторые производители успешно эту функцию реализовали. DuneHD например. Мы постоянно контактируем с производителями приставок и рано или поздно эта функция должна быть реализована на распространенных боксах.
  16. с вебплеера зайти. настройки. управление каналами.
  17. Как вариант, на выход роутера провайдера установить еще один роутер, - свой. И уже к нему подключать все необходимые устройства для просмотра.
  18. Да. Спасибо. Мы работаем над этой проблемой.
  19. Просьба АБО в личку
  20. mariman

    Описание Rest Api

    Пока официально не анонсировано и много чего еще не протестировано как следует. не стоит торопиться. Всё будет. З.Ы. Могу точно сказать, что без softid работать фича не будет. Попробуйте /channel_list?icon=1 или icon=2
  21. mariman

    А почему http response не gzip-уется?

    Ну..., как ни странно это звучит, но не все боксы понимают gzip
  22. mariman

    Crossdomain JS access

    "меня терзают смутные сомнения..." Есть вероятность, что HTML5 не сможет проигрывать поток по причине не поддержки транспорта http/ts. Точнее сказать, сам стандарт его не поддерживает. Во всяком случае, топовые браузеры кроме mozilla не умеют воспроизводить поток http/ts/H.264/aac Вообще, наверное воспроизведение через html5 плеер правильнее, но на смартах обычно реализовывается свой объект плеера с гораздо шире функциями... и подозреваю, что там эту проблему уже решили.
  23. mariman

    Описание Rest Api

    Ну, во первых, там далеко не одна таблица. И даже не одна БД. Во вторых, с индексами там все еще сложнее. В третьих, важно понимать, что если какой-либо бокс или приложение вызывает критичную нагрузку, мы делаем всё для того, чтобы изолировать это приложение и чтобы остальные могли пользоваться сервисом нормально. Ни Вы ни мы в этом не заинтересованы. Итак, как я вижу ситуацию: Вы хотите получить у себя на приставке или программе (одним словом - клиенте) получить данные по любимым фильмам. Кешировать локально и не дергать лишний раз сервер. Отлично! Мы только "за"!. Хочу сказать всего лишь, что у Вас все для этого уже есть. Как я предлагаю Вам это реализовать: 1. получаете первый раз (когда пустой кэш) список любимых фильмов. Одним запросом. На страницы три-четыре вперед. Т.е. не все. Вы, вместе с данными фильмов, получаете данные об общем количестве. Кэшируете всё. 2. каждый раз при входе в раздел видеотеки, Вы еще раз делаете запрос любимых фильмов, но только первую страницу. В этот момент вы еще раз получаете и информацию об общем количестве фильмов и, если есть новые, вы получаете сразу данные новых фильмов на первой же странице. Всего один запрос и у вас все нужные данные есть. 3. если абонент добрался до края кэша, подгружается следующая порция страниц. Интересна реализация асинхронной подгрузки с предупреждением (автоматически на предпоследней странице) - абонент тогда не замечает подгрузки вобще. Чем Вам не нравится такой подход? Все методы для этого уже реализованы.
  24. mariman

    Описание Rest Api

    Согласен, что с введением мультирума вопрос об кэшировании встал ребром, как говорится. Как не жаль, но в этом случае действительно не стоит полагаться на кэш. Думаю, Вам нужно будет каждый раз обращаться к /vod_favlist (параметры идентичны /vod_list кроме type, только список любимых фильмов)
×
×
  • Создать...