1. Начало есть, но пока выглядит сыровато для полного перехода на этот АПИ в течении 3 месяцев. Предлагаю хотя бы удвоить время перехода до лета.

2. Если не затруднит, введите доп. функцию для двухступенчатой авторизации для лучшей защиты креденциалов клиента, по аналогии с уже имеющейся и отработанной схемой вашего веб плейера, т.е. доп. отдача сервером клиенту персональной соли (с её завязкой на account id, ip и timestamp или timerange for authorization like 3...30 sec. after server response) для хеширования креденциалов перед получением SID.

3. Определитесь с языками для интерфейса и дорожек сопровождения - ОБЕ либо 3, либо 2 символа (понятнее, конечно 3). Ведь язык он есть язык, не зависимо от места применения

4. Элементарная грамматика языка подсказывает, что параметр (item/channel) have_archive должен выглядеть как has_archive (или, ещё короче, archive или rec).

5. Из шаблонов путей (например, icons) логично исключить сервер, если, конечно, есть желание сохранить идею работы клиентов только через одино имя сервера. В любом случае, клиент должен априори знать кого вызывает.

6. Более существенным, сильно влияющим на скорость работы клиентского софта, считаю необходимость дать возможным делать запросы EPG для группы каналов, например cid=132,67,115 или cid=132;67;115, с сохранением последовательности каналов, данной в запросе. Здесь убедительная просьба, не ограничивать группировку каналов штатным параметром group и/или favorites, т.к. клиент может иметь свои наборы предпочитаемых каналов и схему их выбора.

7. По параметрам запроса EPG. Предлагаю использовать относительное значение параметра day, т.е. day=0 для текущего дня (по времени клиентского часового пояса), day=-1 для вчерашнего дня, day=7 для недели вперёд и т.д. Это упрощает логику клиентской стороны и не усложнит серверную. Отсутствие параметра day даёт текущую и следующую передачи, здесь всё путём.

8. Ещё важное пожелание по параметрам запроса EPG. Для работы клиента без доп. запросов (сейчас у вас иногда в текущей EPG добавляется в конец дня передача (напр. по daily EPG последняя передача былa 23:10-"Маша и слон", а в 23:30 вижу current 23:25-"Новые программы", next - 23:55-"Бесёнок Гу". То есть дневная EPG не корректируется и расходится с возвращаемой current/next. Здесь я могу ошибаться, т.к. мой клиент кеширует запросы дневной EPG текущего дня. В любом случае, при отображении текущей и следующей передачи в списке, для ускорения работы клиента, желателен лишь один серверный запрос EPG текущего дня. Для этого необходимо добавить, как минимум, параметр запроса inclusive. Если inclusive=0, то передачи дня видим как обычно, т.е. первая текущая начинается в 00:00 или позже текущего дня, последняя - в 23:59 или ранее. При значении inclusive=1 текущий день имеет первой передачей например 23:20 - 00:30 "До и после полуночи" для того, чтобы клиент в 00:10 мог отобразить без current/next перезапросa начало текущей передачи.
Аналогично, последняя передача в списке текущего дня должна содержать данные передачи следующего дня, например в 23:30 клиент отображает 23:20 - 00:20 "текущая передачка" и "следующая" с 00:20 - (01:50 = конец следующей передачи при параметре inclusive=2, или пусто(=-1 при minutes=1, см. пункт 10 далее) при inclusive=1 - это важно при (спец)обработке последней передачи в цикле).

9. По возврату EPG информации канала. Предлагаю дополнить так:
title - info - begin - end - rec, где значение REC, или flag RECorded, подскажет клиенту о возможности выбора конкретной записанной передачи (по картиновски, из "архива&quot.

10. Ещё одно дополнение по возврату EPG информации канала. Предлагаю дать опцию возврата времён начала и окончания передач не в формате "22:55", а как количество минут с начала суток в клиентском времени. Эта опция должна быть для всех запросов, возвращающих время передачи, т.к. клиенту нужна именно цифра для определения текущего % с начала передачи - без необходимости ежеминутного перезапроса вашего сервера. Предлагаю, например, ввести параметр minutes=1 (default is minutes=0 and returns regular time string "HH:MM&quot.

11. Для реализации полноценного клиента отсутствует ещё возможность смены не только родительского, но и основного пароля (или его хэш-вариации).

12. К настройкам аккаунта желательно добавить не только язык интерфейса, но, прежде всего, предпочитаемый/начальный язык звукового сопровождения. Например, preferred_lang=en,ru с приоритетом по порядку в списке.
При ЛЮБОЙ раскладке, поднимаю обе руки за трансляцию ВСЕХ имеющихся дорожек канала, т.к. например Xtreamer может свободно выбирать дорожку на лету, и, во многих случаях, это самый оптимальный и оперативный способ пользования (выбор часто зависит от качества дубляжа источника, жанра, внезапной смены аудитории и т.д.).
А. Введите параметр отключения передачи ЕПГ данных при запросе листа ТВ каналов. Обоснование - не все пользуются ЕПГ, а его % объём в ответе весьма значительный. В любом случае, для получения полноценного ЕПГ нужно делать доп. запрос как минимум на текущий день для, как минимум, группы каналов (или придётся тянуть для всех 100+, если нельзя вызывать cid=19,123,98,44!).

13. Верните в АПИ ответа параметр acc_level, откуда будет ясно, какой вариант доступа, или комплект каналов, клиент имеет с данными креденциалами логина. Неужели и это проблемно, ведь он там уже промелькнул!?

14. Если нет тага REC для прошедшей передачи (см. пункт 9), будет ли считаться ошибкой всегда вызывать запуск канала с параметром lts=... , даже для каналов без ЕПГ/архива ?

при выходе в список каналов я тащу у картины список, что идет сейчас