Описание Rest Api

[gipsyjack]

Доброе время суток всем!

Я автор плагина для картины под медиапортал. Позвольте пару вопросов.

К примеру я забрал клиентом группу фильмов. Теперь человек хочет отсортировать их по рейтингу или по времени изменения\добавления в видеотеку. По тому что есть сейчас я должен снова делать запрос на сервер с соответствующим параметром даже если речь идет о ТЕХ же самых фильмах. На мой взгляд такое поведение глуповато. Нельзя ли в json-овый ответ (vod_list) добавлять сразу некую цифирь\стринг, указывающую правдивую дату модификации или добавления конкретного фильма, чтобы по крайней мере в рамках сессии я уже не напрягал сервер из-за каждой мелочи.

Тут раньше спрашивали за поле dt_modify, но ответ был, что мол оно неактуально. А поле как раз неплохое.

То же самое и по-поводу best. Хотя можно найти компромис. Я просто могу сортировать фильмы по цифИри рейтинга. Его вы включаете в ответ. Хотя это получится не тот best, который вычисляется у вас. Включив же цифирь просмотров вы бы освободили клиента снова и снова бежать за списком фильмов, и сортировать уже локально однажды полученную группу фильмов (по крайней мере в рамках сессии).

[mariman]

Теперь человек хочет отсортировать их по рейтингу или по времени изменения\добавления в видеотеку. По тому что есть сейчас я должен снова делать запрос на сервер с соответствующим параметром даже если речь идет о ТЕХ же самых фильмах. На мой взгляд такое поведение глуповато. Нельзя ли в json-овый ответ (vod_list) добавлять сразу некую цифирь\стринг, указывающую правдивую дату модификации или добавления конкретного фильма, чтобы по крайней мере в рамках сессии я уже не напрягал сервер из-за каждой мелочи.

 

на мой взгляд глуповато сортировать все в пределах одной страницы... (20 фильмов всего... по умолчанию) Кстати прогружать и держать в памяти данные о (пока всего лишь) 1000 фильмах тоже не самая гениальная идея.

 

Тут раньше спрашивали за поле dt_modify, но ответ был, что мол оно неактуально. А поле как раз неплохое.

 

Никто не говорил что его нельзя пользовать. Это поле даты последнего изменения. т.е. если обнаружится в описании где либо ошибка и она будет исправлена модератором - поле изменится. Если обновится рейтинг - поле тоже изменится. Вообще любой чих с записью - дата фиксируется. Можем рассмотреть возможность добавления поля dt_create - дата создания записи. Как оказалось, тоже не совсем актуально. Некоторые фильмы уже забиты но ждут "одобрения" и могут не сразу опубликоваться... а спустя достаточно длительное время.

 

То же самое и по-поводу best. Хотя можно найти компромис. Я просто могу сортировать фильмы по цифИри рейтинга. Его вы включаете в ответ. Хотя это получится не тот best, который вычисляется у вас. Включив же цифирь просмотров вы бы освободили клиента снова и снова бежать за списком фильмов, и сортировать уже локально однажды полученную группу фильмов (по крайней мере в рамках сессии).

 

на данный момент в планах Видеотеки:

- алфавитный поиск (по первой букве)

- рейтингование пользователями фильмов (добавление самими пользователями оценки фильму по принципу нравится/ненравится. Будет формироваться соответствующий рейтинг.)

- рейтинг по просмотрам за последний месяц (актуальные фильмы)

- настраиваемые фильтры

 

Если есть какие либо конструктивные предложения - всегда рады обсудить.

 

[gipsyjack]

на мой взгляд глуповато сортировать все в пределах одной страницы... (20 фильмов всего... по умолчанию)

Я вытягиваю весь список (без картинок) и сортирую в нем. Картинки тянутся отдельно и только их дельта.

 

Кстати прогружать и держать в памяти данные о (пока всего лишь) 1000 фильмах тоже не самая гениальная идея.

У каждой идеи есть свое обоснование, ок? 1000 фильмов весит около 3 мегабайт. ДЛя современного pc не самый большой размер, правда? Когда будет 10000-30000 - будет xml, когда будет 30000+ - будет база. Идея заключается в автономной работе без беготни на сервер.

 

Никто не говорил что его нельзя пользовать. Это поле даты последнего изменения. т.е. если обнаружится в описании где либо ошибка и она будет исправлена модератором - поле изменится. Если обновится рейтинг - поле тоже изменится. Вообще любой чих с записью - дата фиксируется. Можем рассмотреть возможность добавления поля dt_create - дата создания записи. Как оказалось, тоже не совсем актуально. Некоторые фильмы уже забиты но ждут "одобрения" и могут не сразу опубликоваться... а спустя достаточно длительное время.

Такие решения нужно принимать вам. Возможно нужно завести поле, которое будет изменяться согласно четким бизнес-правилам, а не "любым чихам". Лишний if не красит код, но все же.

 

на данный момент в планах Видеотеки:

- алфавитный поиск (по первой букве)

- рейтингование пользователями фильмов (добавление самими пользователями оценки фильму по принципу нравится/ненравится. Будет формироваться соответствующий рейтинг.)

- рейтинг по просмотрам за последний месяц (актуальные фильмы)

- настраиваемые фильтры

 

Если есть какие либо конструктивные предложения - всегда рады обсудить.

Предоставление облегченного списка всех фильмов для работы только с дельтами.

Буквально:

id,

dt_publish,

dt_modify (то же самое что и сейчас)

Список сохраняется один раз локально.

* Если теперь изменяется dt_publish, то значит под данным Id появился другой фильм

(при условии, что вы не делаете инкремент ключу, иначе некий флаг, что id "ушел")

Как следствие перетягивается movie_details (содержимое того же json-а)

* Если изменился dt_modify - также перетягивается информация, но, допустим, без картинки

* В противном случае Ничего Не делается и сразу в клиентскую вьюху.

 

Все, что Вы перечислили можно успешно выполнять локально, при наличии соответствующих данных.

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

Хотя тогда придется пересмотреть все же политику изменения dt_modify или добавить другой какой-нибудь "признак".

 

Да, забыл добавить. Наполнение локального storage будет происходить естесственным образом lazy load.

Я понимаю, что "автономная работа" режет слух DBA-я, но не стоит забывать, что в конечном итоге речь идет о довольно скромном обьеме данных.

Например в сумме все постеры на 1000 фильмов от вас весят целых 16763966 байт, текстовая информация к ним и того меньше.

Где-то 20-25MB на каждую 1000 фильмов. Думаю до 20000 фильмов пользователь даже не почувствует. Зато получит реакцию локального приложения со всеми вытекающими.

Да и сервер не будет дергаться без надобности.

======================

Детали можно обсудить

 

 

 

[bellorusha]

А чего архив закрыли даже на API уровне для apple?

 

http://iptv.kartina.tv/api/xml/get_url?cid...;gmt=1303175100

poluchayu

 

<message>Error generate URL. Bad parameters</message><code>8</code>

 

Изменено 14 октября 2011 пользователем bellorusha

[apodolsk]

Хотелось бы иметь функцию поиска в АРХИВЕ а лучше вместе ЛАЙФ и АРХИВ то есть записанные можно пометить буквой "R" , плюс сопровождающая информация (Канал, дата, время, серия ).Например задаём передачу " ЧТО,ГДЕ,КОГДА" после чего - к примеру показывает есть но в ЛАЙФ через 4 дня на канале .... дата.....время.....часть/серия , илиже в Архиве с меткой "R" (и при нажатии ОК переходим к просмотру ).

Или у Картины уже есть что то подобное в планах ?

Спасибо за пожелание - учтем.

@mariman - очень хотелось бы, чтобы Вы обратили внимание на это предложение.

[hanryz]

Уважаемые админы, для простоты пользования REST API, не могли бы вы пожалуйста выложить здесь PDF или WORD с полним описанием REST API.

 

Спасибо заранее.

[consros]

Добрый день, я - один из авторов TVonTop проекта, позволяющего в том числе просмотр Картины на приставках на Realtek чипсете, как то: Xtreamer, Asus O!Play, IconBIT. Пользователи регулярно задают вопрос - есть ли возможность "включить обратно" перемотку а архиве. Дело в том, что около месяца назад формат отдаваемого из архива видео изменился и новый формат поддерживается плеерами ограниченно. В частности - не работает перемотка.

 

Поэтому вопрос такой. Нельзя ли с помощью какого-либо секретного параметра попросить сервер отдавать архив в старом формате?

[mariman]

... месяца назад формат отдаваемого из архива видео изменился и новый формат поддерживается плеерами ограниченно. В частности - не работает перемотка.

Поэтому вопрос такой. Нельзя ли с помощью какого-либо секретного параметра попросить сервер отдавать архив в старом формате?

 

Здравствуйте. Формат не изменился и никогда не менялся!!!

Мы убрали Content-length из заголовков ответа сервера.

Для работы с архивом необходимо делать другой HTTP запрос с параметром gmt=... что описано в документации.

Content-length был убран чтобы пользователь не делал seek по открытому файлу, поскольку эта процедура вызывает ошибку в случаях когда дописывается следующий фрагмент архива.

Архив - не файл. Архив - поток. поэтому у него Content-length быть не может.

 

Уважаемые админы, для простоты пользования REST API, не могли бы вы пожалуйста выложить здесь PDF или WORD с полним описанием REST API.

 

Спасибо заранее.

 

Чем неудобна подача информации через ветку форума?

 

[consros]

Для работы с архивом необходимо делать другой HTTP запрос с параметром gmt=... что описано в документации.

 

Да-да, это понятно, так мы и делаем. Я об этом случае и говорю.

 

Здравствуйте. Формат не изменился и никогда не менялся!!!

Мы убрали Content-length из заголовков ответа сервера.

 

Ага, понятно, я просто не вникал, заметил отсутствие перемотки и решил, что изменился формат.

 

Content-length был убран чтобы пользователь не делал seek по открытому файлу, поскольку эта процедура вызывает ошибку в случаях когда дописывается следующий фрагмент архива.

Архив - не файл. Архив - поток. поэтому у него Content-length быть не может.

 

То есть теперь поддержки перемотки нет совсем? Или как обойтись без seek по файлу?

И если я правильно понял проблему, нельзя ли вернуть content-length для всех законченых (не дописываемых в данный момент) файлов?

 

Без content-length коробки не верят в возможность перемотки и просто отключают эту функцию.

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

[mariman]

То есть теперь поддержки перемотки нет совсем? Или как обойтись без seek по файлу?

И если я правильно понял проблему, нельзя ли вернуть content-length для всех законченых (не дописываемых в данный момент) файлов?

 

Без content-length коробки не верят в возможность перемотки и просто отключают эту функцию.

 

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

/get_url?cid=<ИД канала>&gmt=<дата время позиции архива>&protect_code=<пароль для закрытых каналов>

 

Параметры

 

cid - идентификатор канала полученный из channel_list

gmt - дата время позиции архива в формате unixtime

protect_code - цифровой пароль для закрытых каналов. если канал закрыт а пароль не передан, либо передан неверный пароль, то в тэге <url> возвращается слово "protected".

[consros]

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

Ах вот как, теперь понял, спасибо.

В таком случае у коробок нет шансов, конечно же. Надо переписывать сам плеер или добавлять прокси.

 

А вариант с seek по законченым файлам абсолютно не реализуем?

[consros]

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

Ах вот как, теперь понял, спасибо.

В таком случае у коробок нет шансов, конечно же. Надо переписывать сам плеер или добавлять прокси.

 

А вариант с seek по законченым файлам абсолютно не реализуем?

 

Ребята просят не только гарцевать, но и ответить таки на вопрос.

[Задавака]

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

Ах вот как, теперь понял, спасибо.

В таком случае у коробок нет шансов, конечно же. Надо переписывать сам плеер или добавлять прокси.

 

А вариант с seek по законченым файлам абсолютно не реализуем?

 

Зачем что-то переделывать. Если пользователь пытается перемотать - просто делается новый запрос и получается новый поток.

 

 

Единственный минус - время на перебуфирезацию.

 

 

[consros]

Зачем что-то переделывать. Если пользователь пытается перемотать - просто делается новый запрос и получается новый поток.

 

Есть ли понимание, что плеер - это платформозависимая программа-плеер внутри коробки? И она сама решает, что делать когда пользователь пытается перемотать? И у неё нет никакого API, как у VLC?

 

[Задавака]

Зачем что-то переделывать. Если пользователь пытается перемотать - просто делается новый запрос и получается новый поток.

 

Есть ли понимание, что плеер - это платформозависимая программа-плеер внутри коробки? И она сама решает, что делать когда пользователь пытается перемотать? И у неё нет никакого API, как у VLC?

 

 

Ну раз это коробка как-то умудряется заходить на картину и брать с неё поток - значит и как-то можно управлять ею.

[consros]

Ну раз это коробка как-то умудряется заходить на картину и брать с неё поток - значит и как-то можно управлять ею.

 

Вот бы узнать - как это ей удаётся?!

[Задавака]

Ну раз это коробка как-то умудряется заходить на картину и брать с неё поток - значит и как-то можно управлять ею.

 

Вот бы узнать - как это ей удаётся?!

 

Наверное так же как и инициализировать просмотр, через resp_api

[AlexTitoff]

А чего архив закрыли даже на API уровне для apple?

 

http://iptv.kartina.tv/api/xml/get_url?cid...;gmt=1303175100

poluchayu

 

<message>Error generate URL. Bad parameters</message><code>8</code>

Такая же хрень. Но если убрать параметр gmt то выдаст ссылку на прамой эфир.

Дайте пример _работающего_ запроса. Раньше ведь все работало.

[AlexTitoff]

сам разобрался. Поменяли параметры входа. http://iptv.kartina.tv/api/xml/login?login...ss=<pass>&device=device&settings=all

Теперь работает.

Кто пользовался плагином KartinaTV v2 для PLEX можете вечером обновить его.

[barmalej]

а разве device=all не автоматом ставится или на яблоко?

Изменено 9 декабря 2011 пользователем barmalej

[Lord KiRon]

Ребята, я тут попытался написать апликацию для смарт-ящиков от LG , но возникла проблемка, ваш сервер при запросе в стиле: http://iptv.kartina.tv/api/xml/login?login=xxx&pass=xxx возвращает ошибку:

 

XMLHttpRequest cannot loadhttp://iptv.kartina.tv/api/jsonp/login?login=xxx&pass=xxx. Origin http://localhost:8110is not allowed by Access-Control-Allow-Origin response header.

 

Не могли бы вы поставить на вашем сервере "Access-Control-Allow-Origin" на * ?

 

 

Edited:

Не важно уже разобрался как это делать через JASONP, ну и извращенцы эти господа веб программеры

Изменено 4 января 2012 пользователем Lord KiRon

[Lord KiRon]

В комманде channel_list не возвращается поле protected, по крайней мере в JSONP.

Это так и планировалось? - тогда надо изменить первый пост, иначе - баг.

[consros]

Повторю вопрос -

 

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

 

Нельзя ли разрешить seek по законченным (не дописываемым в данный момент) файлам?

 

На большинстве коробок на базе Realtek чипсета открытие потока Картины длится от 10 секунд. Даже если встраивать сложнейшую кастомную обработку нажатий кнопок (Realtek не предоставляет высокоуровневых средств для такой обработки) и слать запрос заново, всё равно каждый шаг перемотки будет занимать более 10 секунд. Каждый. Стоит ли говорить насколько это неудобно.

 

Если я не ошибаюсь, эфир у вас режется на фрагменты по 4 часа. Большинство просматриваемых из архива передач записаны более 4х часов назад. Пусть для открытых в настоящий момент файлов (последние 4 часа) приходит такой же ответ как и сейчас, читай: отлуп, а для дописанных файлов - происходил бы seek, как это было до октября.

 

Это очень сильно порадовало бы многих приставочных пользователей.

Изменено 10 января 2012 пользователем consros

[technic]

сам разобрался. Поменяли параметры входа. http://iptv.kartina.tv/api/xml/login?login...ss=<pass>&device=device&settings=all

 

Обновите доку пожалуйста...

 

[Eugene]

Повторю вопрос -

 

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

Нельзя ли разрешить seek по законченным (не дописываемым в данный момент) файлам?

+1 в пользу XBMC и многих других ffmpeg-based проигрователей