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

Описание Rest Api


mariman

Рекомендованные сообщения

  mariman писал:
  Bigfan писал:
  nitrogen14 писал:
товарищи!!!

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

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

 

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

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

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

 

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

 

 

прошу...

 

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

 

спасибо!!!

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

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

 

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

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

 

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

Изменено пользователем nitrogen14
Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

 

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

 

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

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

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

 

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

 

но куда уж..

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

 

Ссылка на комментарий
Поделиться на других сайтах

  vladimir2 писал:
...

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

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

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

 

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

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

post-4657-1294907482_thumb.png

Изменено пользователем nitrogen14
Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

 

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

 

 

Ссылка на комментарий
Поделиться на других сайтах

@mariman

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

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

спасибо

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

Еще одно замечание по 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>....

 

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

Изменено пользователем reflex
Ссылка на комментарий
Поделиться на других сайтах

  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}

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

 

Ссылка на комментарий
Поделиться на других сайтах

  reflex писал:
Видим, что возвращается много "обьектов" типа <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 средствами "как родной".

Ссылка на комментарий
Поделиться на других сайтах

  Eugene писал:
  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}

 

 

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

Изменено пользователем reflex
Ссылка на комментарий
Поделиться на других сайтах

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

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

отправил.

 

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

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

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

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

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

Изменено пользователем Eugene
Ссылка на комментарий
Поделиться на других сайтах

И у меня

 

settings?var=bitrate (XML)

 

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

 

Ссылка на комментарий
Поделиться на других сайтах

  Eugene писал:
отправил.

 

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

 

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

 

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

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

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

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

 

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

 

TimeShift: 0 --> bitrate 900

TimeShift: 1 --> bitrate 1500

...

TimeShift: 11 --> bitrate 1500

 

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

Изменено пользователем Jo2003
Ссылка на комментарий
Поделиться на других сайтах

Гость
Эта тема закрыта для публикации сообщений.
  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...