[Описание Rest Api]

Повторю вопрос -

 

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

 

Нельзя ли разрешить seek по законченным (не дописываемым в данный момент) файлам?

 

На большинстве коробок на базе Realtek чипсета открытие потока Картины длится от 10 секунд. Даже если встраивать сложнейшую кастомную обработку нажатий кнопок (Realtek не предоставляет высокоуровневых средств для такой обработки) и слать запрос заново, всё равно каждый шаг перемотки будет занимать более 10 секунд. Каждый. Стоит ли говорить насколько это неудобно.

 

Если я не ошибаюсь, эфир у вас режется на фрагменты по 4 часа. Большинство просматриваемых из архива передач записаны более 4х часов назад. Пусть для открытых в настоящий момент файлов (последние 4 часа) приходит такой же ответ как и сейчас, читай: отлуп, а для дописанных файлов - происходил бы seek, как это было до октября.

 

Это очень сильно порадовало бы многих приставочных пользователей.

[Описание Rest Api]

Ну раз это коробка как-то умудряется заходить на картину и брать с неё поток - значит и как-то можно управлять ею.

 

Вот бы узнать - как это ей удаётся?!

[Описание Rest Api]

Зачем что-то переделывать. Если пользователь пытается перемотать - просто делается новый запрос и получается новый поток.

 

Есть ли понимание, что плеер - это платформозависимая программа-плеер внутри коробки? И она сама решает, что делать когда пользователь пытается перемотать? И у неё нет никакого API, как у VLC?

 

[Описание Rest Api]

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

Ах вот как, теперь понял, спасибо.

В таком случае у коробок нет шансов, конечно же. Надо переписывать сам плеер или добавлять прокси.

 

А вариант с seek по законченым файлам абсолютно не реализуем?

 

Ребята просят не только гарцевать, но и ответить таки на вопрос.

[Описание Rest Api]

Для работы с архивом необходимо делать другой HTTP запрос с параметром &gmt=... что описано в документации.

 

Ах вот как, теперь понял, спасибо.

В таком случае у коробок нет шансов, конечно же. Надо переписывать сам плеер или добавлять прокси.

 

А вариант с seek по законченым файлам абсолютно не реализуем?

[Описание Rest Api]

Для работы с архивом необходимо делать другой HTTP запрос с параметром gmt=... что описано в документации.

 

Да-да, это понятно, так мы и делаем. Я об этом случае и говорю.

 

Здравствуйте. Формат не изменился и никогда не менялся!!!

Мы убрали Content-length из заголовков ответа сервера.

 

Ага, понятно, я просто не вникал, заметил отсутствие перемотки и решил, что изменился формат.

 

Content-length был убран чтобы пользователь не делал seek по открытому файлу, поскольку эта процедура вызывает ошибку в случаях когда дописывается следующий фрагмент архива.

Архив - не файл. Архив - поток. поэтому у него Content-length быть не может.

 

То есть теперь поддержки перемотки нет совсем? Или как обойтись без seek по файлу?

И если я правильно понял проблему, нельзя ли вернуть content-length для всех законченых (не дописываемых в данный момент) файлов?

 

Без content-length коробки не верят в возможность перемотки и просто отключают эту функцию.

[Описание Rest Api]

Добрый день, я - один из авторов TVonTop проекта, позволяющего в том числе просмотр Картины на приставках на Realtek чипсете, как то: Xtreamer, Asus O!Play, IconBIT. Пользователи регулярно задают вопрос - есть ли возможность "включить обратно" перемотку а архиве. Дело в том, что около месяца назад формат отдаваемого из архива видео изменился и новый формат поддерживается плеерами ограниченно. В частности - не работает перемотка.

 

Поэтому вопрос такой. Нельзя ли с помощью какого-либо секретного параметра попросить сервер отдавать архив в старом формате?