mariman

iptv.kartina.tv для iPad и iPhone запущен почти год назад. Работает в обычном браузере на JSON варианте API. Символы которые вам не нравятся - это русские буквы кодированные стандартной библиотекой json... стандартное отображение unicode символов в JSON... и нормально отображаются в браузере. http://iptv.kartina.tv/img/ico/24/{id}.gif

1. Изначально было type="password". Но участились жалобы, что "неудобно набирать пароль ЦИФРАМИ на буквенной клавиатуре". После небольшого опроса было принято решение сделать пароль обычными цифрами... пока вижу только одного клиента против как минимум десяти которому это не понравилось. Если еще будут возражения - исправим.

Исправлено. К сожалению, нет полноценной возможности проверить работу под linux Ubuntu. Проверено на виртуальной машине. Просьба сообщить если проблема не устранилась.

Проблему под линуксами подтверждаю. Работаем.

Запоминается установленный уровень звука и канал. При перезапуске плеера (бразузера) (компьютера) продолжается вещание на остановленном канале и с выбранным уровнем звука. На панельке это не регулируется никак. Есть еще не выведенная на панель функция - спрятать панель плеера - кнопка "h" (hide). Достается панель ею же.

Исправлено. + Добавлены функции запоминания уровня звука и выбранного канала...

Да. это поле нужно игнорировать. Это служебное поле. Оно не документировано. Появившийся фильм может меняться но не значительно. Мелкие косметические изменения.

Очень тяжелый файл получится... Особенно когда там будет 1000+ фильмов (к чему и стремимся). Собственно, по этой причине специально и разделили на vod_list и vod_info. Если бить по страницам, то как решить проблему новых фильмов? Встречный вопрос: можно подробнее про "индексацию"? Зачем она вам? Если для поиска, то чем не устраивает mode=text ?

А не взболтнул ли я чего лишнего... Просьба привести пример где реально могла бы возникнуть ситуация с подобным количеством запросов? О качестве разработки: Лишь тот не ошибается, кто ничего не делает. Каким по Вашему мнению должен быть достойный и качественный продукт? Всегда рад помочь.

Форум читаем, даже имеем статистику как по отказам так и по нормальной работе. Видим все со стороны сервера... Сами являемся своими же клиентами (извините за тавтологию...) Даже хуже - нашими клиентами являются наши тещи, жены которые могут требовать похлеще некоторых клиентов на форуме... Еще раз: ограничение в 4 запроса в секунду на протяжении 5 секунд. (!!!) для одной клиентской сессии. Таким образом реальное ограничение равно 20 запросам. И еще раз повторюсь - это значение выведено эмпирически, то есть опытным путем. Это означает что мы анализировали накопленную статистику по запросам и пришли к вот такой вот цифре. При этом ограничении все имеющиеся приставки и сервисы работают отлично. Проверено. Поэтому непонятно ваше явное недовольство введенными ограничениями. Кстати, для MaxiBox и PeerTV (он же SIG) API использовали частично. А именно в работе с Видеотекой и механизмом установки клиентских настроек. На вещание, проблемы с пропаданием DNS и выходом из режима Standby это НИКАК не влияет. Форум читаем. С саппортом общаемся. По проблемам в курсе. Ограничения введены были тоже не на ровном месте. Были прецеденты НЕОДНОКРАТНО, после которых пришлось пойти на подобные меры. Иначе сервис бы уже не работал.

Имелось в виду задержка при загрузки файла. 1. Согласен. Достаточно жесткое ограничение. Но и вообще без ограничения - нельзя. Для того и дискутируем чтобы прийти к компромиссу по ограничениям. 2. Опять согласен. На этапе планирования архитектуры API рассматривали этот момент и решили "не усложнять". Возможно вернемся к подобной практике, но ключ не для разработчика а для устройства, как вариант, только для тех кто не шлет UserAgent в http-запросах. Нам важно тип приложения отключить... а не разработчика. Если, допустим, ошибка в новой версии - чтобы все остальные версии приложения работали... Поэтому еще и версия.

на пульте кнопочка ZOOM (чуть выше кнопки SETUP)

По большому счету вся дискуссия сводится к этому моменту. Реализация тут особого значения не имеет. Даже если рассмотреть момент, что лежит в кеше уже генерированный файл, этот файл будет достаточно объемным. При старте ваше приложение будет "задумываться" на ощутимо продолжительное время. Но вопрос в другом: Это потенциально "тонкое" место. Можно допустить ошибку программирования и запрашивать подобный файл на каждое обращение к EPG. Подобный запрос может вызвать "паразитическую нагрузку". Что не есть "хорошо". Думаю правильным будет ввести другое ограничение... Ограничение на количество получения EPG. В вашем случае, EPG на неделю будет возможно получить (допустим) не более трех раз за неделю... Что-то вроде "не более N запросов EPG на задаваемый период P". Если это необходимо для кеширования на заданный период, то такое условие как бы избыточное.

Dune HD на 100% использует наш API. Все документированные функции. Частично Maxibox и SIG используют API. Есть еще такие замечательные приложения, как VLC Record... плагин к XBMC который успешно может работать на AppleTV Думаю достаточно чтобы убедить в стабильной работе API.

Что значит НЕ РАБОТАЕТ?!?!? Какой ответ API? Должен вернуться хоть какой-то ответ. Что именно в ответе Вас не устроило? Убедительная просьба: При оформлении заявки о неработоспособности API просьба указать: 1. Четко и коротко саму суть проблемы. 2. Какие меры предпринимались для выявления ошибки и ее устранении (если предпринимались) 3. дата и время запроса к API 4. Запрос полностью. его параметры. 5. Полученый ответ. 6. Описание платформы и клиент который использовался для работы с API. Его версия. (если есть данные - используемые библиотеки) 7. Данные по абонементу используемому в работе API. 8. географическое местоположение абонемента, данные о провайдере, канале интернет, серверах вещания... 9. Данные обратной связи.

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

Итак. Прежде всего прошу прощения за задержку в ответах. Долгое время отсутствовал. Теперь хотел бы дать пояснения по введенным ограничениям и работе АПИ в принципе... @Alexvrs Основная мысль ввода ограничений - не дать возможности "долбить" приставкам и приложениям ресурсоемкие сервисы API. Ограничение в 4 запроса в секунду адекватное и было выведено эмпирически. Во всяком случае нормальный живой настоящий человек не в состоянии генерировать и воспринимать по 4 запроса (ответа) в секунду на протяжении 5 секунд... Подобное возможно, например, если "пробегаться" по каналам. На каждый канал приложение старается прогрузить свой EPG, вызвав тем самым избыточную нагрузку. Поэтому считаю целесообразным придерживаться принципа Оккама и "прогружать EPG" только при необходимости, т.е. когда это действительно нужно. Например в нашем случае делать запрос на новую порцию EPG по событию отпускания кнопки на пульте. Насчет предложения отдать EPG сразу на день - отрицательно. Во-первых объем. Это больше 100 каналов с примерно 30 программ с описанием ~ около 1 мегабайта текста. Во вторых - генерировать такой текст тоже непросто для сервера. Если при разработке этих проблем не видно, то они всплывают при промышленных нагрузках. Поэтому - грузим столько сколько надо. И только нужные каналы. /epg3 задумывалась для организации просмотра телепрограммы на подобии http://tv.yahoo.com/listings В целом о кешировании - отличная вещь! Но использовать ее необходимо грамотно. "1-2 запроса кешированных на сервере" - не совсем так. Вы не учитываете многих параметров как таймзоны, разновидности пакетов и т.п. пару запросами никак не обойдется.

Вводится ограничение на нагрузку использования API. Ограничение на 4 запроса в секунду для одной сессии. Мера вынужденная... для защиты системы от избыточных перегрузок. В случае возникновения ситуации возвращается стандартный ответ ошибки с кодом 31 (Query limit exceeded).

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

нет. Приставки писались когда не было API и с учетом возможностей конкретных приставок. Например SIG-220+ не умеет работать ни с XML ни с JSON. Для них были реализованы свои методы. Интересно, каким это образом вы хотите устанавливать несколько настроек? делается это /settings_set?var=<переменная>&val=<значение> т.е. в переменной var=... можно указать только одну переменную.

Да. Багу отловили. Благодарствуем. Фикс выпустили. epg3 у меня используется для получения текущей и следующей передач. это я поменяю на вызов epg_next. но уйдет ли проблема или останется -- не понятно. Над этим работаем... кстати epg3 и epg_next - разные вещи. 3 - показывает на ледующие 3 часа. а next - показывает три следующие (!!!) передачи.

только пока не очень работает на получение: 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} Можно подробнее насчет абонемента под которым вы пытаетесь сделать эту операцию? (можно в личку номер). Подобная ситуация возможна если у абонемента нет прав управлять битрейтом. Например демо-абонемент... и,кстати, спасибо за замечание. надо вывести более вменяемое сообщение об ошибке...

В итоге появится много объектов типа <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 средствами "как родной".

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

Ты прям как ясновидящий VLC тоже бывает не то маркирует, когда активна посл. передача вернее первая след. дня. Действ. неудобно, когда нужно нагружать с-му из-за такой мелочи! прошу... /epg_next?cid=<ID канала> Рад бы, да к сожалению... у нас нет ДОСТОВЕРНЫХ источников... а брать целую единицу в штат, чтобы просмартивал и расставлял категории на каналы - не оправдано.