Описание Rest Api

[nitrogen14]

Есть вопрос на счет битрэйта.

 

Если скажу, что хочу битрэйт 900, тогда только еще смогу посмотреть то что и есть в битрэйт 900 или мне показывает то что есть в 900 в 900 а остальное в 1500?

 

Пример: Я хочу битрэйт 900. Если тепер посмотрю "Первый" будет такой битрэйт?

 

TimeShift: 0 --> bitrate 900

TimeShift: 1 --> bitrate 1500

...

TimeShift: 11 --> bitrate 1500

 

Или я только еще могу посмотрет "Первый" без "таймшифта" (TimeShift: 0) с битрэйтом 900?

как я понял битрейт меняется только для лайв вещания. таймшифт это архив(запись с неменяемым битрейтом)

[Jo2003]

Как мне mariman объяснил - тогда только идет то что и есть в 900. Но кажется что есть еще баг /channel_list ... будем видеть.

[technic]

Просто любопытно

А оригинальные присатвки делают такие же запросы как и вебплеер?

 

И ещё можно ли сразу несколько настроек в одном запросе установить?

Изменено 21 января 2011 пользователем technic

[mariman]

Просто любопытно

А оригинальные присатвки делают такие же запросы как и вебплеер?

 

нет. Приставки писались когда не было API и с учетом возможностей конкретных приставок. Например SIG-220+ не умеет работать ни с XML ни с JSON. Для них были реализованы свои методы.

 

И ещё можно ли сразу несколько настроек в одном запросе установить?

 

Интересно, каким это образом вы хотите устанавливать несколько настроек? делается это /settings_set?var=<переменная>&val=<значение> т.е. в переменной var=... можно указать только одну переменную.

 

 

[apodolsk]

Приставки писались когда не было API и с учетом возможностей конкретных приставок. Например SIG-220+ не умеет работать ни с XML ни с JSON. Для них были реализованы свои методы.

А новые приставки?

[barmalej]

видеотека упала

 

запрос на vod_genres:

 

<br />

<b>Fatal error</b>: Uncaught exception 'Exception' with message '7' in .../api.class.php:673

[technic]

Интересно, каким это образом вы хотите устанавливать несколько настроек? делается это /settings_set?var=<переменная>&val=<значение> т.е. в переменной var=... можно указать только одну переменную.

 

Спасибо понял. Думал может есть такая возможность, но не описана в апи.

Изменено 28 января 2011 пользователем technic

[mariman]

видеотека упала

 

 

Спасибо за найденый баг.

А видеотека не упала а отключили. разница есть. Наблюдались незначительные технические проблемы. Теперь в норме.

З.Ы. Обновили контент

[lufthanseat]

видеотека упала

 

 

Спасибо за найденый баг.

А видеотека не упала а отключили. разница есть. Наблюдались незначительные технические проблемы. Теперь в норме.

З.Ы. Обновили контент

 

Объявляйте в новостях плиз! А то не знаешь что и как и где искать! Так что по по поводу видеотеки?

[myview]

Есть проблема с API channel_list (По крайней мере XML точно)

Notice: Undefined index: 371 in /data/mware-staging/mod/channels/url_profile.class.php on line 57

Изменено 5 февраля 2011 пользователем myview

[Eugene]

в JSON тоже

[andr3y]

Hello, I need some help regarding the API. (I understand written Russian, but I can describe the problem better in English).

 

I'm logging in using "device=apple" for the "/login" request. But, sometimes the API returns channel URLs in response to "/get_url" in the form of either:

 

 

Type 1: http://<IP_ADDRESS_WITHOUT_PORT>/streaming/test6.m3u8?ticket=<CODE>

 

or

 

Type2: http://<IP_ADDRESS_WITH_PORT>/?ticket=<CODE>

 

 

Type 1 URLs play fine on iPad because I'm assuming the stream format is HTTP Live Streaming. Type 2 URLs do not work.

 

I've tested both with my paid Kartina account and the demo accounts. The paid account always returns non-apple Type 2 URLs. Demo accounts return either type of URL randomly - sometimes Type 1, sometimes Type 2.

 

This problem is also present when logging in on iPad through Safari at iptv-kartina.tv. Sometimes the stream works, sometimes it doesn't.

 

Why is the API returning Type 2 URLs for JSON calls with "device=apple"?

 

I'd appreciate any advice.

 

(I edited the post to clarify after some further testing.)

Изменено 11 февраля 2011 пользователем andr3y

[mariman]

Вводится ограничение на нагрузку использования API.

Ограничение на 4 запроса в секунду для одной сессии. Мера вынужденная... для защиты системы от избыточных перегрузок.

В случае возникновения ситуации возвращается стандартный ответ ошибки с кодом 31 (Query limit exceeded).

[Eugene]

Мера вынужденная... для защиты системы от избыточных перегрузок.

есть статистика с каких устройств приходят избыточные запросы?

[nitrogen14]

Мера вынужденная... для защиты системы от избыточных перегрузок.

есть статистика с каких устройств приходят избыточные запросы?

в этом и проблема, "любители" не посылают свой опозновательный знак.

от того ввели это чебы всех не банить за мизилла5.0

 

думаю это касается просмотра с скриптом от consros к примеру на азбокс и других где в плейлисте на канал прописан логин

там для получения линка на стрим сначала идет авторизация

[Eugene]

нитро, у меня тоже ходит избыточный запрос для проверки живучести сессии.. так что любой пук типа получения ссылки на поток или списка каналов, это 2 (или 3, если сессия оторвалась) запроса..

 

скорее всего это опять плагины для Энигмы чудят (как с Родным было)

[Alexvrs]

@mariman

 

В основном много считываний приходится для получения EPG,

этому так же способствует функция epg_next,

для того чтобы избавится от всех этих запросов,

нужно использовать выдачу всего EPG одним запросом (файлом) с указанием даты актуальности,

до наступления которой повторного обновления EPG не требуется!!! (при этом можно кешировать этот ответ со стороны сервера).

При этом разработчики клиентов просмотра КартинаТВ смогут делать локальный кешь для всей информации и кол-во запросов сведется к нулю!!!,

информацию о необходимости обновить EPG (новой или измененной дате) можно также передавать в остальных запросах, например при авторизации.

 

В таком варианте использование API сведется к следующему кол-ву запросов:

 

1. Авторизация и сравнение даты актуальности информации (можно некий UUID)

2. В случае обнаружения актуальности информации все данные берутся из локального кеша, включая список каналов

3. В случае обнаружения НЕ актуальности информации, сначала можно получить список каналов с текущими передачами для возможности быстрого использования списком текущих передач, а затем загрузить уже целиком EPG в кешь

 

P'S'

Неправдали здорова? Всего 1-2 запроса (кешированных на сервере) для каждого пользователя в сутки?

 

P'P'S'

все остальные запросы хороши для использования клиентов аля браузер: дал запрос -> ПОДОЖДАЛ ОТВЕТА N СЕКУНД -> вывел результат -> дал новый запрос -> ПОДОЖДАЛ ОТВЕТА N СЕКУНД (это раздражает активных пользователей желающих пощелкать каналы и нагружает излишне сервер)

 

 

Изменено 23 февраля 2011 пользователем Alexvrs

[pawlodar]

@mariman

ждём ваше мнение, вроде предложение от alexvrs корректно

[petruha]

ну что так и будете молчать, выкладывайте ваше мнение на предложение от alexvfs

[technic]

Или добавьте хотя бы получение епг для всех каналов на текущую и следующую передачу, со временем окончания!

[direktor]

А это наверно уже не в интересах картины, чтоб клиенты были довольны. Вон ребята бесплатно для вашего сервиса плагины пишут, вам бы радоватся да помогать им , а не палки в колёса вставлять. Вот вы меняете АПИ уже чyть ли не каждый день, и всё в худшую сторону, а лучше бы завели диалог с разработчиками плагинов и прислушались к ним. Звонишь в тех поддержку, спрашиваешь как связатся с тех директором ответственым за АПИ, а тебе отвечают,только через форум.А тут задаёшь вопросы и всё равно без толку.Февральские вопросы досихпор без ответа.

 

Tакое ощущение, что они с нами борются, позавчера все работало на 100 %

 

ПРИЧИНА В СЛЕДУЮЩЕМ:

 

1. есть такая функция REST API как

PHP код:

/epg3?dtime=<Дата и время старта EPG>&period=<на сколько часов вперед>

Выдача программы телепередач доступных каналов с времени указанного в dtime на следующие period часов.
необходима для организации функции "что идет сейчас" как на http://tv.yahoo.com/listings 
Программа генерируется с учетом timeshift переменной выставленной пользователем в настройках.

Параметры

dtime - дата и время (unixtime) начала EPG. По умолчанию выбирается текущий момент (по серверному времени)
period - на сколько часов вперед. По умолчанию выдается EPG на ближайшие 3 часа.

 

данная функция при позавчерашней проверки выдавала ЕПГ по всем каналам на 24 часа при помощи вот такой команды (параметр period=24 как раз это определяет):

 

PHP код:

http://iptv.kartina.tv/api/xml/epg3?dtime=1299701241&period=24&MWARE_SSID=xxxxxxx

 

теперь эта команда не выдает ЕПГ на 24 часа, а выдает на 4 или типа того:

 

PHP код:

<item>
        <id>2</id>
        <name>Первый</name>
        <epg>
        <item>
            <ut_start>1299699000</ut_start>
            <progname>Среда обитания. "Пилите, Шура, пилите...".</progname>
            <t_start>21:30</t_start>
        </item>
        <item>
            <ut_start>1299702600</ut_start>
            <progname>Ночные новости.</progname>
            <t_start>22:30</t_start>
        </item>
        <item>
            <ut_start>1299703800</ut_start>
            <progname>"КВН. 50 виртуальных игр".</progname>
            <t_start>22:50</t_start>
        </item>
        <item>
            <ut_start>1299707400</ut_start>
            <progname>Х/ф "А вот и Полли".</progname>
            <t_start>23:50</t_start>
        </item>
        <item>
            <ut_start>1299713400</ut_start>
            <progname>Х/ф "Двойник", 1 ч.</progname>
            <t_start>01:30</t_start>
        </item>
        <item>
            <ut_start>1299715200</ut_start>
            <progname>Новости.</progname>
            <t_start>02:00</t_start>
        </item>
        <item>
            <ut_start>1299715500</ut_start>
            <progname>Х/ф "Двойник", 2 ч.</progname>
            <t_start>02:05</t_start>
        </item>
    </epg>
</item>

 

используя ВСЕГО несколько запросов равных кол-ву дней мы получали ЕПГ по всем каналам на весь период за 1 минуту и больше не передовали запросов на сервер (частота не превышала 1-го запроса в секунду) теперь это опять не работает!!!!

 

 

[lufthanseat]

И в самом деле картина, сколько можно людей парить? Вы или ответьте по человечески, либо не суйте палки в колеса. Мы тоже люди, и хотим смотреть ваш сервис за который заплатили. Да мы смотрим не через ваши приставки, но это не повод над нами издеваться, ( я пользовался вашей приставкой, но к сожалению она меня не удовлетворила) теперь позвольте сделать нам свой выбор и смотреть на том, что мы хотим ( на том что-можно) по крайнее мере определитесь с API и учтите предложения по поводу его! . Или вы дальше будете навязывать свои приставки? Если всё так и есть, скажите прямо в лицо пользователям!

Спасибо за понимание! Ждем ответа от администрации!

Изменено 8 марта 2011 пользователем lufthanseat

[mariman]

Итак. Прежде всего прошу прощения за задержку в ответах. Долгое время отсутствовал.

 

Теперь хотел бы дать пояснения по введенным ограничениям и работе АПИ в принципе...

 

@Alexvrs

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

 

Насчет предложения отдать EPG сразу на день - отрицательно. Во-первых объем. Это больше 100 каналов с примерно 30 программ с описанием ~ около 1 мегабайта текста. Во вторых - генерировать такой текст тоже непросто для сервера. Если при разработке этих проблем не видно, то они всплывают при промышленных нагрузках. Поэтому - грузим столько сколько надо. И только нужные каналы. /epg3 задумывалась для организации просмотра телепрограммы на подобии http://tv.yahoo.com/listings

 

В целом о кешировании - отличная вещь! Но использовать ее необходимо грамотно. "1-2 запроса кешированных на сервере" - не совсем так. Вы не учитываете многих параметров как таймзоны, разновидности пакетов и т.п. пару запросами никак не обойдется.

 

[mariman]

И в самом деле картина, сколько можно людей парить? Вы или ответьте по человечески, либо не суйте палки в колеса. Мы тоже люди, и хотим смотреть ваш сервис за который заплатили. Да мы смотрим не через ваши приставки, но это не повод над нами издеваться, ( я пользовался вашей приставкой, но к сожалению она меня не удовлетворила) теперь позвольте сделать нам свой выбор и смотреть на том, что мы хотим ( на том что-можно) по крайнее мере определитесь с API и учтите предложения по поводу его! . Или вы дальше будете навязывать свои приставки? Если всё так и есть, скажите прямо в лицо пользователям!

Спасибо за понимание! Ждем ответа от администрации!

 

 

Я не совсем администрация а разработчик, но подозреваю, что отношение у администрации к истерическим заявлениям типа Вашего как минимум нейтральное, поэтому ваш вопрос администрация скорее всего проигнорирует. Мне не совсем понятны Ваши претензии к работе API. Есть масса успешных проектов использующих наш API. Есть АДЕКВАТНЫЕ И ВМЕНЯЕМЫЕ предложения. Если у вас что-то не получается, то вы либо не совсем одаренный программист, либо являетесь олицетворением статистического термина "грубый промах" в социальном плане который обозначает 3% постоянно озлобленных и всегда недовольных индивидуумов либо Вы от конкурентов...

[mariman]

используя ВСЕГО несколько запросов равных кол-ву дней мы получали ЕПГ по всем каналам на весь период за 1 минуту и больше не передовали запросов на сервер (частота не превышала 1-го запроса в секунду) теперь это опять не работает!!!!

 

Что значит НЕ РАБОТАЕТ?!?!? Какой ответ API? Должен вернуться хоть какой-то ответ. Что именно в ответе Вас не устроило?

Убедительная просьба: При оформлении заявки о неработоспособности API просьба указать:

 

1. Четко и коротко саму суть проблемы.

2. Какие меры предпринимались для выявления ошибки и ее устранении (если предпринимались)

3. дата и время запроса к API

4. Запрос полностью. его параметры.

5. Полученый ответ.

6. Описание платформы и клиент который использовался для работы с API. Его версия. (если есть данные - используемые библиотеки)

7. Данные по абонементу используемому в работе API.

8. географическое местоположение абонемента, данные о провайдере, канале интернет, серверах вещания...

9. Данные обратной связи.