Описание Rest Api

[nitrogen14]

товарищи!!!

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

также ен хватает в епг у последней передачи время окончания

 

для показа в списке канала текущей и следующей передачи мне приходится делать запрос и перелопачивать епг на канал, что вечером приводит к тормозам.

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

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

 

Действ. неудобно, когда нужно нагружать с-му из-за такой мелочи!

 

 

прошу...

 

/epg_next?cid=<ID канала>

 

спасибо!!!

вечером проверю.

это для текущей передачи и для последней передачи дня сработает?

[reflex]

Рад бы, да к сожалению... у нас нет ДОСТОВЕРНЫХ источников... а брать целую единицу в штат, чтобы просмартивал и расставлял категории на каналы - не оправдано.

 

Жаль, что в исходном сигнале нет этой информации.

Придется у себя шаманить. Делать что то типа поиска подстроки в описании и если найдено "комедия", "сериал", "Х/ф" то это film. и т.д. Не точно и наверняка будут ложные срабатывания, но все же лучше чем вообще ничего.

[nitrogen14]

/epg_next?cid=<ID канала>

 

еще раз спасибо, функция пашет, но:

зачем нужно было выкидывать циверки? типо время начала и конца передачи?

очень не хватает этих циверок (теперь не могу показать длительность передачи)

 

пожалуйста добавьте в просто епг последним пунктом время окончания передачи!!!

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

 

заранее благодарен

Изменено 12 января 2011 пользователем nitrogen14

[vladimir2]

Почему вы меняли API? API есть, чтобы вещи которые работают НЕЛьЗЯ менять. Вы хотите новые вещи в API, новые возможности - пожалуйста - но тогда надо делать что например новый "request" надо чтобы будет новый ответ и старый работает как и было. Это смысл АПИ! Например:

 

/channel_list --> работает как и было

/channel_list_ex --> навый формат ответа!

 

Как вы думаете будет дальше? Хотите менше клиенты т.к. VLC-Record больше не работает???

 

Чувствую, Joerg, им глубоко забить на тебя и на всех (нас) просматривающих

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

абонементом на год....

 

Я уже писал о подобном - http://forum.kartina.tv/index.php?showtopic=5151

 

но куда уж..

О нормальном девелопменте в этой конторе речь и не идет...

 

[nemezdsl]

...

О нормальном девелопменте в этой конторе речь и не идет...

и откуда столько негатива?!

так просвети! в какой конторе "нормальный девелопмент"???

[Jo2003]

На сколько я понял, это было пожелание...

Формат вывода /channel_list не изменился а дополнился. Если разбирать xml стандартными библиотеками, то проблем с разбором не возникнет. Если парсить xml самостоятельно, то возможны ошибки.

 

Я использую стандардную библиотеку. Но я так "парсовал" ХМЛ как это было описано в первом постинге.

[nitrogen14]

О нормальном девелопменте в этой конторе речь и не идет...

ты что чтото разрабатываешь? если нет, так покинь эту тему со своим нытьём не по делу.

мой плаг как пахал, так и пашет дальше

 

сейчас 86 человек онлайн используют мой плаг

http://stats.pristavka.de/stats_widget.php

Изменено 13 января 2011 пользователем nitrogen14

[mariman]

На сколько я понял, это было пожелание...

Формат вывода /channel_list не изменился а дополнился. Если разбирать xml стандартными библиотеками, то проблем с разбором не возникнет. Если парсить xml самостоятельно, то возможны ошибки.

 

Я использую стандардную библиотеку. Но я так "парсовал" ХМЛ как это было описано в первом постинге.

 

Прошу прощения, но ни в первом посте, ни в остальных, не давалось никаких описаний о методах парсинга XML. Был описан формат xml ответа. Не более. Таким образом, если обращаться к данным в xml через xpath, а не regexp (как я подозреваю), то ошибок можно было бы избежать. Собственно поэтому формат XML и был выбран... поскольку изначально подразумевается расширение (возможность дополнения другими данными) структуры ответа. Таким образом, изначально заданная структура НЕ ИЗМЕНИЛАСЬ, а дополнилась новыми полями.

 

 

[nitrogen14]

@mariman

сделайте милость, подсобите.

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

спасибо

http://forum.kartina.tv/index.php?showtopi...ost&p=54627

[Jo2003]

Прошу прощения, но ни в первом посте, ни в остальных, не давалось никаких описаний о методах парсинга XML. Был описан формат xml ответа. Не более. Таким образом, если обращаться к данным в xml через xpath, а не regexp (как я подозреваю), то ошибок можно было бы избежать. Собственно поэтому формат XML и был выбран... поскольку изначально подразумевается расширение (возможность дополнения другими данными) структуры ответа. Таким образом, изначально заданная структура НЕ ИЗМЕНИЛАСЬ, а дополнилась новыми полями.

 

Есть другие возможности а не только xpath. xpath очень просто работает в PHP ... а у меня не PHP но C++ (Qt). regexp я не использую. Я например использую XMLReader. А там всегда посмотрел на старт таг. Вот получилось так, что очень много элементы стартуют через "item"-таг - и вот там была проблема. Если там в XML есть 5 "item" а каждого стартует другогой тип элемента, в XMLReader будет сложно.

 

Чтобы это будет понятно: Там я делал парсинг как можно проше (и быстрее) для меня. Но за то реагирует не очень когда что то изменяешь. Вот в том была проблема. Тут - можно сказать - я причем. Но не причем я в том, что я только узнал о изменения когда это уже было активно. Если уже менять (дпольнить) АПИ надо об этом и ранше писать. А не только тихо менять 1-й постинг. Ну ... мы тут уже разбирались. Так я надеюсь, следующий раз ранше узнаю.

[nitrogen14]

спасибо @mariman за консультацию.

 

итак мой косяк, не заметил <ts>1294834800</ts>

использовал старую функцию запрашивающую ut_start.

со временем ясно.

для вычисления времени окончания последней передачи дня по епг нужно будет сделать такойжзе запрос на епг3, оно идет и на следующий день и не прийдется запрашивать весь епг на следующий день

 

еще раз огромное спасибо за сотрудничество

[reflex]

Еще одно замечание по XML.

К примеру возьмем XML который возвращается по команде channels_list.

 

<response>
    <groups>
        <item>
            <id>1</id> 
            <name>Общие</name> 
            <color>Silver</color> 
            <channels>
                <item>
                    <id>2</id> 
                    <name>Первый</name> 
                    <stream_params>
                        <item>
                            <rate>1500</rate> 
                            <ts>0</ts> 
                        </item>
                        <item>....

 

Видим, что возвращается много "обьектов" типа <item>, которые не идентичны по смыслу и типу данных. Обычно code rules предписывают каждому обьекту давать собственное наименование, которе и помогает разруливать проблемы парсинга.

Т.е. я бы предложил возвращать ХМL подобный этому

 

<response>
    <groups>
        <group>
            <id>1</id> 
            <name>Общие</name> 
            <color>Silver</color> 
            <channels>
                <channel>
                    <id>2</id> 
                    <name>Первый</name> 
                    <stream_params>
                        <param>
                            <rate>1500</rate> 
                            <ts>0</ts> 
                        </param>
                        <param>....

 

Если уж делать совсем правильно

Изменено 13 января 2011 пользователем reflex

[Eugene]

Нововведения в API

 

3. параметр bitrate в /settings

только пока не очень работает на получение:

17:59:56 T:2958290944 M:668635136  NOTICE: [Kartina.TV] REQUESTING: http://iptv.kartina.tv/api/json/settings?var=bitrate
17:59:56 T:2958290944 M:668655616  NOTICE: [Kartina.TV] Got {"error":{"message":"Need value (val) parameter","code":"21"},"servertime":1294937996}

[reflex]

гений, покаж свою поделку, охото посмотреть, что творят такие умные парни или ты только на советы горазд?

может ты еще слышал, что апи не изменяется?

 

А чего показывать то? У меня конвертор ЕПГ для WMC. Скриншот WMC?

Видео идет через прокси которое написано на C# и выложено www.pristavka.de

 

Про принципы АПИ я наслышан А написал в виде совета на будущее

[nitrogen14]

А написал в виде совета на будущее

а тут ктото советов просил?

[reflex]

а тут ктото советов просил?

nitrogen14, я в курсе, что круче тебя только горы, но добрее надо быть.

 

Год назад еще никакого АПИ не было и не известно как оно будет выглядеть через год.

 

[mariman]

Видим, что возвращается много "обьектов" типа <item>, которые не идентичны по смыслу и типу данных. Обычно code rules предписывают каждому обьекту давать собственное наименование, которе и помогает разруливать проблемы парсинга.

 

В итоге появится много объектов типа <param>...

 

Вообще для понимания "почему так" проще пояснить основные принципы которыми руководствовались при создании:

1. Результирующий xml должен состоять только из тегов. БЕЗ АТРИБУТОВ. Это решает очень многие проблемы при создании его же и разборе.

2. как вы уже догадались - делалось все на PHP. В изначальном виде данные в РНР это обычный хэш-массив. Таким образом конструкцию типа результата sql запроса представляет собой набор строк:

array(
  0 => array('id'=>NNN1, 'title'=>'<any text>' ...),
  1 => array('id'=>NNN2, 'title'=>'<any text>' ...),
  2 => array('id'=>NNN3, 'title'=>'<any text>' ...),
..
  N => array('id'=>NNNN, 'title'=>'<any text>' ...),
)

 

При всех вариантах оптимальным при переводе подобного массива в xml будет вариант замены цифровых ключей не некий тег. Нейтральным названием этого тега было выбрано имя <item>

Другие варианты излишне усложнили бы задачу.

 

Кстати в JSON подобный массив переводится встроенными PHP средствами "как родной".

[mariman]

Нововведения в API

 

3. параметр bitrate в /settings

только пока не очень работает на получение:

17:59:56 T:2958290944 M:668635136  NOTICE: [Kartina.TV] REQUESTING: http://iptv.kartina.tv/api/json/settings?var=bitrate
17:59:56 T:2958290944 M:668655616  NOTICE: [Kartina.TV] Got {"error":{"message":"Need value (val) parameter","code":"21"},"servertime":1294937996}

 

 

Можно подробнее насчет абонемента под которым вы пытаетесь сделать эту операцию? (можно в личку номер).

Подобная ситуация возможна если у абонемента нет прав управлять битрейтом. Например демо-абонемент...

 

и,кстати, спасибо за замечание. надо вывести более вменяемое сообщение об ошибке...

[reflex]

В итоге появится много объектов типа <param>...

<param> я оставил только для <stream_params>. Проглядели <item> -> <channel> и <item> -> <group>

 

Я не говорил что только так правильно, это было просто замечание по "структуре", которое мне (как Software Architect'ору c десятилетним стажем) бросилось в глаза.

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

[Eugene]

Можно подробнее насчет абонемента под которым вы пытаетесь сделать эту операцию? (можно в личку номер).

Подобная ситуация возможна если у абонемента нет прав управлять битрейтом. Например демо-абонемент...

отправил.

 

+ еще один баг-репорт появился, касаемый установленного таймшифта (-8 часов, если принципиально). копирую сюда как есть:

/epg3 - на первый взгляд нормально учитывает таймшифт, но ближе к вечеру (по моему времени) начинает возвращать пустой список каналов (без названий передач). Соответственно подсказки у меня работают только утром;

/epg - при просмотре с задержкой, время программ никак не меняет. но зачем-то отдает совсем другой кусок программы. То есть вместо нормальных с ~4 утра до ~4 утра следующего дня и скорректированного времени передач, оно мне отдает программу с ~8 вечера вчерашнего дня, до ~8 вечера сегодняшнего.

/channel_list - тупо отдает текущие передачи без учета задержки, поэтому в списке каналов я всегда вижу передачи которые будут только через 8 часов.

epg3 у меня используется для получения текущей и следующей передач. это я поменяю на вызов epg_next. но уйдет ли проблема или останется -- не понятно.

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

[Jo2003]

И у меня

 

settings?var=bitrate (XML)

 

не работает. Ругается, что "val" нехватает (что ерунда, т.к. я спрашиваю а не хочу сохранять). Даже если я даю какой то "val" (settings?var=bitrate&val=0) дает одну и тот же ошибку.

 

[mariman]

отправил.

 

Да. Багу отловили. Благодарствуем. Фикс выпустили.

 

+ еще один баг-репорт появился, касаемый установленного таймшифта (-8 часов, если принципиально). копирую сюда как есть:

 

/epg3 - на первый взгляд нормально учитывает таймшифт, но ближе к вечеру (по моему времени) начинает возвращать пустой список каналов (без названий передач). Соответственно подсказки у меня работают только утром;

/epg - при просмотре с задержкой, время программ никак не меняет. но зачем-то отдает совсем другой кусок программы. То есть вместо нормальных с ~4 утра до ~4 утра следующего дня и скорректированного времени передач, оно мне отдает программу с ~8 вечера вчерашнего дня, до ~8 вечера сегодняшнего.

/channel_list - тупо отдает текущие передачи без учета задержки, поэтому в списке каналов я всегда вижу передачи которые будут только через 8 часов.

epg3 у меня используется для получения текущей и следующей передач. это я поменяю на вызов epg_next. но уйдет ли проблема или останется -- не понятно.

 

Над этим работаем...

 

кстати epg3 и epg_next - разные вещи. 3 - показывает на ледующие 3 часа. а next - показывает три следующие (!!!) передачи.

[Eugene]

кстати epg3 и epg_next - разные вещи. 3 - показывает на ледующие 3 часа. а next - показывает три следующие (!!!) передачи.

знаю. просто epg3 появилось раньше, чем epg_next

 

mariman, можно об обновлениях API всегда сообщать новым сообщением в данной ветке + обновлять еще и дату первого сообщения?

а то получается, что изменения происходят безмолвно и отследить их практически невозможно

[technic]

Было бы ещё хорошо показывать епг 3-ёх следующих передач для всех каналов.

 

[Jo2003]

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

 

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

 

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

 

TimeShift: 0 --> bitrate 900

TimeShift: 1 --> bitrate 1500

...

TimeShift: 11 --> bitrate 1500

 

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

Изменено 18 января 2011 пользователем Jo2003