mariman
-
Публикации
118 -
Зарегистрирован
-
Посещение
Тип публикации
Профили
Форум
Календарь
Сообщения, опубликованные пользователем mariman
-
-
vse chto nado sdelat', eto pomenyat'
<input type="number" id="pass" name="pass" size="7"/>
na
<input type="password" id="pass" name="pass" size="7"/>
1. Изначально было type="password". Но участились жалобы, что "неудобно набирать пароль ЦИФРАМИ на буквенной клавиатуре". После небольшого опроса было принято решение сделать пароль обычными цифрами...
пока вижу только одного клиента против как минимум десяти которому это не понравилось. Если еще будут возражения - исправим.
-
Исправлено. К сожалению, нет полноценной возможности проверить работу под linux Ubuntu. Проверено на виртуальной машине. Просьба сообщить если проблема не устранилась.
-
Проблему под линуксами подтверждаю. Работаем.
-
да, спасибо. Действительно все- ок.
Молодцы, оперативненько так)))
А что значит "+ Добавлены функции запоминания уровня звука и выбранного канала..."
Где эти функции на панели ? Не вижу
Запоминается установленный уровень звука и канал. При перезапуске плеера (бразузера) (компьютера) продолжается вещание на остановленном канале и с выбранным уровнем звука. На панельке это не регулируется никак.
Есть еще не выведенная на панель функция - спрятать панель плеера - кнопка "h" (hide). Достается панель ею же.
-
Исправлено.
+ Добавлены функции запоминания уровня звука и выбранного канала...
-
или можно игнорировать это поле и предположить, что единожды появившийся в видеотеке фильм не обновляется?
Да. это поле нужно игнорировать. Это служебное поле. Оно не документировано.
Появившийся фильм может меняться но не значительно. Мелкие косметические изменения.
-
mariman, можно ли расширить функционал vod_list? был бы полезен mode=full (или типа того) который будет возвращать полный список содержимого Видеотеки, включая информацию из vod_info
вещь достаточно статичная, посему хорошо кешируемая. в этом режиме можно форсированно не поддерживать фильтрацию и поиск чтобы исключить использование не по назначению.
без этого режима индексация Видеотеки часто прерывается из-за превышения количества запросов в секунду (хотя пару раз умудрялась проходить без ошибок). можно, конечно, делать искусственно задержку, но в таком случае индексация займет столько секунд, сколько фильмов в Видеотеки, что в перспективном будующем станет до неприличия долго.
+ нагрузка на сервер будет существенно снижена
Очень тяжелый файл получится... Особенно когда там будет 1000+ фильмов (к чему и стремимся). Собственно, по этой причине специально и разделили на vod_list и vod_info. Если бить по страницам, то как решить проблему новых фильмов?
Встречный вопрос: можно подробнее про "индексацию"? Зачем она вам? Если для поиска, то чем не устраивает mode=text ?
-
В Вашем первом сообщении никакого упоминания о пяти секундах не было.
А не взболтнул ли я чего лишнего...
A:7,0,7,3,2,7,2,0,0,0 - 7+3+2+7+2 = 21 - Error#31B:19,1,0,0,0,19,1,0,0,1 - 19+1+0+0+1 = 21 - Error#31
C:4,4,4,4,3,5,4,5 - 4+3+5+4+5 = 21 - Error#31
...
Если сервер мог выйти строя без этих ограничений,...это,конечно, показатель качества разработки.
Еще раз спасибо за Ваши ответы.
Просьба привести пример где реально могла бы возникнуть ситуация с подобным количеством запросов?
О качестве разработки: Лишь тот не ошибается, кто ничего не делает.
Каким по Вашему мнению должен быть достойный и качественный продукт?
Всегда рад помочь.
-
Почитайте Форум - многие пишут "Два года все было хорошо, а сейчас..."
Форум читаем, даже имеем статистику как по отказам так и по нормальной работе. Видим все со стороны сервера... Сами являемся своими же клиентами (извините за тавтологию...) Даже хуже - нашими клиентами являются наши тещи, жены которые могут требовать похлеще некоторых клиентов на форуме...
Посчитайте количество запятых - и Вы получите количество запросов при старте,не считая Login. У меня получилось 6.Еще раз: ограничение в 4 запроса в секунду на протяжении 5 секунд. (!!!) для одной клиентской сессии. Таким образом реальное ограничение равно 20 запросам. И еще раз повторюсь - это значение выведено эмпирически, то есть опытным путем. Это означает что мы анализировали накопленную статистику по запросам и пришли к вот такой вот цифре. При этом ограничении все имеющиеся приставки и сервисы работают отлично. Проверено. Поэтому непонятно ваше явное недовольство введенными ограничениями.
Кстати, для MaxiBox и PeerTV (он же SIG) API использовали частично. А именно в работе с Видеотекой и механизмом установки клиентских настроек. На вещание, проблемы с пропаданием DNS и выходом из режима Standby это НИКАК не влияет.
Вы часто обосновываете свои серверные решения как защиту от ошибок клиентских приложений.Это понятно и, наверное, правильно. Частично. Поэтому почитайте, пожалуйста, Форум(хотя бы то, что модераторы еще не успели удалить) и посмотрите на свой Сервис глазами телезрителей.
Даже если клиентов много, а сервер один.
Успехов.
Форум читаем. С саппортом общаемся. По проблемам в курсе.
Ограничения введены были тоже не на ровном месте. Были прецеденты НЕОДНОКРАТНО, после которых пришлось пойти на подобные меры. Иначе сервис бы уже не работал.
-
не совсем так, подгрузка (обновление) ЕПГ организовывается в другом потоке (новейшие модели обладают 2-х ядерными процессорами) и/или по таймеру в ночное время
Имелось в виду задержка при загрузки файла.
1. ИМХО ограничение такое будет не уместным, например в случае если произошел сбой и пользователь вынужден перегрузить ПО, очистив кешь и ему необходимо обновить ЕПГ!2. для ошибок программистов есть более эффективный метод, который применяется ведущими мировыми компаниями (у них есть чему поучиться) - необходимо ввести в API понятие персональный индентификатор разработчика (например такой есть у Last.FM, google и т.д.) этот индентификатор выдается каждому разработчику и регламинтируется лицензионным соглашением, а также в случае не корректной работы приложения у вас появляется персональная обратная связь (e-mail) и однозначная индентификация этого разработчика + появляется цевилизованный механизм блокировки доступа приложения избранного разработчика, в случае возникновения нештатной ситуации до решения проблеммы (и/или выдача разработчику нового индентификатора, если необходимо отсечь не обновленное не корректно работающее ПО)
1. Согласен. Достаточно жесткое ограничение. Но и вообще без ограничения - нельзя. Для того и дискутируем чтобы прийти к компромиссу по ограничениям.
2. Опять согласен. На этапе планирования архитектуры API рассматривали этот момент и решили "не усложнять". Возможно вернемся к подобной практике, но ключ не для разработчика а для устройства, как вариант, только для тех кто не шлет UserAgent в http-запросах. Нам важно тип приложения отключить... а не разработчика. Если, допустим, ошибка в новой версии - чтобы все остальные версии приложения работали... Поэтому еще и версия.
-
Господа, бОльшая часть каналов идет не во весь экран (типа 4:3) и очень напрягают черные полосы слева и справа на экране телека (16:9).
Есть ли возможность в Дуне растянуть картинку 4:3 до 16:9?
В настройках видео нашел опцию "Соотношение сторон" пробовал ставить "Авто" и "16:9" - разницы не увидел.
Может нужно что-то более "умное" настроить или все так смотрят?
на пульте кнопочка ZOOM (чуть выше кнопки SETUP)
-
... Интересует выдача не на ОДИН день а сразу на все каналы на все дни одним файлом ...
По большому счету вся дискуссия сводится к этому моменту. Реализация тут особого значения не имеет. Даже если рассмотреть момент, что лежит в кеше уже генерированный файл, этот файл будет достаточно объемным. При старте ваше приложение будет "задумываться" на ощутимо продолжительное время.
Но вопрос в другом: Это потенциально "тонкое" место. Можно допустить ошибку программирования и запрашивать подобный файл на каждое обращение к EPG. Подобный запрос может вызвать "паразитическую нагрузку". Что не есть "хорошо". Думаю правильным будет ввести другое ограничение... Ограничение на количество получения EPG. В вашем случае, EPG на неделю будет возможно получить (допустим) не более трех раз за неделю...
Что-то вроде "не более N запросов EPG на задаваемый период P". Если это необходимо для кеширования на заданный период, то такое условие как бы избыточное.
-
Какие приставки используют API?
Dune HD на 100% использует наш API. Все документированные функции.
Частично Maxibox и SIG используют API.
Есть еще такие замечательные приложения, как VLC Record... плагин к XBMC который успешно может работать на AppleTV
Думаю достаточно чтобы убедить в стабильной работе API.
-
используя ВСЕГО несколько запросов равных кол-ву дней мы получали ЕПГ по всем каналам на весь период за 1 минуту и больше не передовали запросов на сервер (частота не превышала 1-го запроса в секунду) теперь это опять не работает!!!!
Что значит НЕ РАБОТАЕТ?!?!? Какой ответ API? Должен вернуться хоть какой-то ответ. Что именно в ответе Вас не устроило?
Убедительная просьба: При оформлении заявки о неработоспособности API просьба указать:
1. Четко и коротко саму суть проблемы.
2. Какие меры предпринимались для выявления ошибки и ее устранении (если предпринимались)
3. дата и время запроса к API
4. Запрос полностью. его параметры.
5. Полученый ответ.
6. Описание платформы и клиент который использовался для работы с API. Его версия. (если есть данные - используемые библиотеки)
7. Данные по абонементу используемому в работе API.
8. географическое местоположение абонемента, данные о провайдере, канале интернет, серверах вещания...
9. Данные обратной связи.
-
И в самом деле картина, сколько можно людей парить? Вы или ответьте по человечески, либо не суйте палки в колеса. Мы тоже люди, и хотим смотреть ваш сервис за который заплатили. Да мы смотрим не через ваши приставки, но это не повод над нами издеваться, ( я пользовался вашей приставкой, но к сожалению она меня не удовлетворила) теперь позвольте сделать нам свой выбор и смотреть на том, что мы хотим ( на том что-можно) по крайнее мере определитесь с API и учтите предложения по поводу его! . Или вы дальше будете навязывать свои приставки? Если всё так и есть, скажите прямо в лицо пользователям!
Спасибо за понимание! Ждем ответа от администрации!
Я не совсем администрация а разработчик, но подозреваю, что отношение у администрации к истерическим заявлениям типа Вашего как минимум нейтральное, поэтому ваш вопрос администрация скорее всего проигнорирует. Мне не совсем понятны Ваши претензии к работе 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=... можно указать только одну переменную.
-
отправил.
Да. Багу отловили. Благодарствуем. Фикс выпустили.
+ еще один баг-репорт появился, касаемый установленного таймшифта (-8 часов, если принципиально). копирую сюда как есть:/epg3 - на первый взгляд нормально учитывает таймшифт, но ближе к вечеру (по моему времени) начинает возвращать пустой список каналов (без названий передач). Соответственно подсказки у меня работают только утром;
/epg - при просмотре с задержкой, время программ никак не меняет. но зачем-то отдает совсем другой кусок программы. То есть вместо нормальных с ~4 утра до ~4 утра следующего дня и скорректированного времени передач, оно мне отдает программу с ~8 вечера вчерашнего дня, до ~8 вечера сегодняшнего.
/channel_list - тупо отдает текущие передачи без учета задержки, поэтому в списке каналов я всегда вижу передачи которые будут только через 8 часов.
epg3 у меня используется для получения текущей и следующей передач. это я поменяю на вызов epg_next. но уйдет ли проблема или останется -- не понятно.
Над этим работаем...
кстати epg3 и epg_next - разные вещи. 3 - показывает на ледующие 3 часа. а next - показывает три следующие (!!!) передачи.
-
Нововведения в 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}Можно подробнее насчет абонемента под которым вы пытаетесь сделать эту операцию? (можно в личку номер).
Подобная ситуация возможна если у абонемента нет прав управлять битрейтом. Например демо-абонемент...
и,кстати, спасибо за замечание. надо вывести более вменяемое сообщение об ошибке...
-
Видим, что возвращается много "обьектов" типа <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 средствами "как родной".
-
На сколько я понял, это было пожелание...
Формат вывода /channel_list не изменился а дополнился. Если разбирать xml стандартными библиотеками, то проблем с разбором не возникнет. Если парсить xml самостоятельно, то возможны ошибки.
Я использую стандардную библиотеку. Но я так "парсовал" ХМЛ как это было описано в первом постинге.
Прошу прощения, но ни в первом посте, ни в остальных, не давалось никаких описаний о методах парсинга XML. Был описан формат xml ответа. Не более. Таким образом, если обращаться к данным в xml через xpath, а не regexp (как я подозреваю), то ошибок можно было бы избежать. Собственно поэтому формат XML и был выбран... поскольку изначально подразумевается расширение (возможность дополнения другими данными) структуры ответа. Таким образом, изначально заданная структура НЕ ИЗМЕНИЛАСЬ, а дополнилась новыми полями.
-
товарищи!!!
сделайте дополнительный список каналов, в котором будет отображаться текущая а также последующая передача!!!
также ен хватает в епг у последней передачи время окончания
для показа в списке канала текущей и следующей передачи мне приходится делать запрос и перелопачивать епг на канал, что вечером приводит к тормозам.
также не могу при просмотре в архиве показать длительность последней передачи дня, тк для этого мне прийдется грузить епг на следующий день только ради того, чтобы узнать, когда начинается первая передача
Ты прям как ясновидящий
VLC тоже бывает не то маркирует, когда активна посл. передача вернее первая след. дня.Действ. неудобно, когда нужно нагружать с-му из-за такой мелочи!
прошу...
/epg_next?cid=<ID канала>
mariman, а есть ли возможность добавить категорию передачи (типа film, sport etc.)? По крайней мере в Media Center работала бы тогда "Цветовая дифференциация штанов"http://www.hack7mc.com/wp-content/uploads/.../12/Capture.png
Рад бы, да к сожалению... у нас нет ДОСТОВЕРНЫХ источников... а брать целую единицу в штат, чтобы просмартивал и расставлял категории на каналы - не оправдано.
Описание Rest Api
в REST API
Опубликовано:
iptv.kartina.tv для iPad и iPhone запущен почти год назад. Работает в обычном браузере на JSON варианте API. Символы которые вам не нравятся - это русские буквы кодированные стандартной библиотекой json... стандартное отображение unicode символов в JSON... и нормально отображаются в браузере.
http://iptv.kartina.tv/img/ico/
24/{id}.gif