Hadevs Опубликовано: 2 сентября 2016 Жалоба Рассказать Опубликовано: 2 сентября 2016 При запросе: http://iptv.kartina.tv/api/json/get_url?cid=371&gmt=1470183300 Выдает ошибку: { code = 8; message = "Error generate URL. Bad parameters"; } В чем может быть проблема? Ссылка на комментарий Поделиться на других сайтах More sharing options...
jedinike Опубликовано: 2 сентября 2016 Жалоба Рассказать Опубликовано: 2 сентября 2016 Передал. Ссылка на комментарий Поделиться на других сайтах More sharing options...
Гость empty Опубликовано: 2 сентября 2016 Жалоба Рассказать Опубликовано: 2 сентября 2016 При запросе: http://iptv.kartina.tv/api/json/get_url?cid=371&gmt=1470183300 Выдает ошибку: { code = 8; message = "Error generate URL. Bad parameters"; } В чем может быть проблема? application.WARNING: cannot find catchup: hls_h264, GMT: 1470183300 [] [] Необходимо проверить, есть ли архив в данном стандарте вещания Ссылка на комментарий Поделиться на других сайтах More sharing options...
Hadevs Опубликовано: 2 сентября 2016 Автор Жалоба Рассказать Опубликовано: 2 сентября 2016 При запросе: http://iptv.kartina.tv/api/json/get_url?cid=371&gmt=1470183300 Выдает ошибку: { code = 8; message = "Error generate URL. Bad parameters"; } В чем может быть проблема? application.WARNING: cannot find catchup: hls_h264, GMT: 1470183300 [] [] Необходимо проверить, есть ли архив в данном стандарте вещания Из channel_list вообще не выводит этот параметр. Может с датой что-то сделать? Ссылка на комментарий Поделиться на других сайтах More sharing options...
Гость empty Опубликовано: 2 сентября 2016 Жалоба Рассказать Опубликовано: 2 сентября 2016 Я вижу мой ответ совсем не понятен. В нашем сервисе мы используем разные стандарты вещания, которые можно получить вызвав метод https://iptv.kartina.tv/api/json/settings?var=stream_standard Вот пример ответа: "settings": { "value": "http_h264", "list": [ { "value": "dash_hevc", "title": "DASH / H.265 (HEVC)", "description": "Адаптивный протокол вещания, лучшее качество изображения от Картина ТВ. Выбор битрейта вещания и время буферизации устанавливается автоматически. Каналы переключаются быстро. Предлагается с 2015 года.", "catchup": { "delay": 6, "length": 1209480 } }, { "value": "http_h264", "title": "HTTP / H.264", "description": "Качество изображения зависит от выбранного битрейта вещания. Установленное время буферизации влияет на скорость переключения каналов и на стабильность вещания. Предлагается с 2008 года.", "default": true, "catchup": { "delay": 1800, "length": 1209480 } }, { "value": "udt_h264", "title": "UDT / H.264", "description": "Использование протокола UDT улучшает качество вещания при нестабильном Интернете, позволит Вам выбрать для просмотра более удалённый сервер вещания, но увеличивает время переключения каналов и время буферизации. Предлагается с 2015 года.", "catchup": { "delay": 1800, "length": 1209480 } }, { "value": "hls_h264", "title": "HLS / H.264", "description": "Адаптивный протокол вещания. Ограниченное количество каналов. Нет архива! Предлагается с 2009 года.", "catchup": false } ], "scope": "personal", "name": "stream_standard" }, Нужно обратить внимание на секцию catchup у каждого стандарта в списке. В момент запроса get_url из примера выше используется формат hls, а у него, как видно выше нет никакого архива(catchup = false). Значит нельзя запрашивать архив. Это момент нужно предусмотреть в интерфейсе приставки. Еще я хочу объяснить что значат эти поля: "catchup": { "delay": 1800, "length": 1209480 } delay - означает, что минимальное время с которого пишется архив и которое можно запрашивать length - означает максимальное время в прошлом, где архив доступен, т.е. параметр gmt в get_url должен быть (CURRENT_TIMESTAMP - length) < gmt < (CURRENT_TIMESTAMP - delay) Приставка не должна посылать запрос на сервер с gmt выходящим за границы данного диапазона. Ссылка на комментарий Поделиться на других сайтах More sharing options...
Hadevs Опубликовано: 2 сентября 2016 Автор Жалоба Рассказать Опубликовано: 2 сентября 2016 Во-первых огромное спасибо за подробный ответ.Вот вроде поменял на "http://iptv.kartina.tv/api/json/settings_set?var=stream_standard&val=http_h264". Та же ошибка. посылаю запрос вроде правильный с параметром 1470183300. Очень жду вашей помощи, спасибо) Если можно, киньте работающий URL на котором можно проверить запрос. Ссылка на комментарий Поделиться на других сайтах More sharing options...
Гость empty Опубликовано: 3 сентября 2016 Жалоба Рассказать Опубликовано: 3 сентября 2016 все дело в той формуле, которую я написал выше. Вот что я вижу в логе: [2016-09-03 01:12:05] application.WARNING: Asking Catchup earlier than possible' => http_h264, 'start'=> 1471644845, 'gmt' => 1470183300, 'now' => 1472854325, 'end'=> 1472852525 [] [] Это означает что по мнению сервера время запроса было 1472854325 , начало архива 1471644845 (по формуле выше: 1472854325 - 1209480), а параметр gmt указанный в запросе 1470183300. 1471644845 - 1470183300 = 1461545 , т.е. происходит попытка запросить архив гораздо раньше чем он есть. Прошу еще раз обратить внимание на формулу из моего предыдущего поста, по ней должны фильтроваться все запросы перед отправкой на сервер. Ссылка на комментарий Поделиться на других сайтах More sharing options...
Hadevs Опубликовано: 3 сентября 2016 Автор Жалоба Рассказать Опубликовано: 3 сентября 2016 все дело в той формуле, которую я написал выше. Вот что я вижу в логе: [2016-09-03 01:12:05] application.WARNING: Asking Catchup earlier than possible' => http_h264, 'start'=> 1471644845, 'gmt' => 1470183300, 'now' => 1472854325, 'end'=> 1472852525 [] [] Это означает что по мнению сервера время запроса было 1472854325 , начало архива 1471644845 (по формуле выше: 1472854325 - 1209480), а параметр gmt указанный в запросе 1470183300. 1471644845 - 1470183300 = 1461545 , т.е. происходит попытка запросить архив гораздо раньше чем он есть. Прошу еще раз обратить внимание на формулу из моего предыдущего поста, по ней должны фильтроваться все запросы перед отправкой на сервер. А можете показать параметр, который нужно передавать в данном случае? И что такое get в вашей формуле? Ссылка на комментарий Поделиться на других сайтах More sharing options...
Hadevs Опубликовано: 3 сентября 2016 Автор Жалоба Рассказать Опубликовано: 3 сентября 2016 И я Ее не совсем понимаю, это скорее неравенство, чем формула. Например, что мне нужно сделать, чтобы gmt был больше? Ссылка на комментарий Поделиться на других сайтах More sharing options...
Hadevs Опубликовано: 3 сентября 2016 Автор Жалоба Рассказать Опубликовано: 3 сентября 2016 все дело в той формуле, которую я написал выше. Вот что я вижу в логе: [2016-09-03 01:12:05] application.WARNING: Asking Catchup earlier than possible' => http_h264, 'start'=> 1471644845, 'gmt' => 1470183300, 'now' => 1472854325, 'end'=> 1472852525 [] [] Это означает что по мнению сервера время запроса было 1472854325 , начало архива 1471644845 (по формуле выше: 1472854325 - 1209480), а параметр gmt указанный в запросе 1470183300. 1471644845 - 1470183300 = 1461545 , т.е. происходит попытка запросить архив гораздо раньше чем он есть. Прошу еще раз обратить внимание на формулу из моего предыдущего поста, по ней должны фильтроваться все запросы перед отправкой на сервер. А можете показать параметр, который нужно передавать в данном случае? И что такое get в вашей формуле? А можете показать параметр, который нужно передавать в данном случае? И что такое get в вашей формуле? Я сменил на нужное время, которое вписывалось в диапазон, все работает. А как правильное то выставить? Ссылка на комментарий Поделиться на других сайтах More sharing options...
Гость empty Опубликовано: 5 сентября 2016 Жалоба Рассказать Опубликовано: 5 сентября 2016 И я Ее не совсем понимаю, это скорее неравенство, чем формула. Например, что мне нужно сделать, чтобы gmt был больше? Да, это неравенство GMT должен быть только в этих пределах, потому что на серверах нет данных архива за другие периоды. Еще раз, зная gmt передачи в channel_list можно проверить выполняется ли неравенство указанное выше или нет, если нет - значит передачи в архиве уже нет. Или еще нет Ссылка на комментарий Поделиться на других сайтах More sharing options...
Рекомендованные сообщения