ejemplo

Signed-off-by: Javier Marcet <javier@marcet.info>

out updates like mkvtoolnix, which changes from v58 to v62

Signed-off-by: Javier Marcet <javier@marcet.info>

which is far more human readable

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

detect the bw it uses unless it is running in an isolate device or in
the router itself

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

recording is done

Signed-off-by: Javier Marcet <javier@marcet.info>

after previous refactor and add new method get_title_meta to cleanup
and parse title names, import it from tv_grab_es_movistartv and with
it finally fully synchronize cloud and local recordings and as bonus
enable local saving of cloud recordings, also add check for existance
of recording besides being indexed in order to not queue it

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

conversion of channel_ids and timestamps for _channels, _cloud,
_epgdata & _recordings; make them all int while in memory, this
makes the code much cleaner while also faster.

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

previous versions

Signed-off-by: Javier Marcet <javier@marcet.info>

cloud recordings which are not in the epg cache anymore for being
older than a week.

Now all Cloud Recordings should be accessible no matter the existing
epg cache.

Signed-off-by: Javier Marcet <javier@marcet.info>

category to the top 100, include them all

Signed-off-by: Javier Marcet <javier@marcet.info>

/recordings.m3u with the 100 most recent video files found within
RECORDINGS, ordered from newest to oldest.

This makes it really easy to identiy and locate recordings as they're
added to the collection, as well as accessing very quickly to the
newest recordings.

When the the recorings collection has some size it is hard to realize
in what group (path) new recorings have been added. It is shown as
the top most folder in TiviMate's Movies section.

Signed-off-by: Javier Marcet <javier@marcet.info>

it exists. Still left to implement the else case, i.e., no saved
information found for said cloud recording; it needs to get new epg
info and serialize it into all the needed fields in the epgdata in
memory.

This also meeans anyone with lots of old cloud recordings is having
now issues with autorec timers, sorry for that. Be a little patient
or checkout the repo before /recordings.m3u has been exposed.

Signed-off-by: Javier Marcet <javier@marcet.info>

for local recordings when the env var RECORDINGS is defined with the
local folder where recordings done by this backend should be stored
and now the folder whose content will be offered indexed in both
/recordings.m3u & /grabaciones.m3u endpoints.

Hence, even if the timers feature for automatic recordings of programs
is not used, just by defining RECORDINGS, its movies (files which end
in ay of ['.avi', '.mkv', '.mp4', '.mpeg', '.mpg', '.ts']), the m3u
will be updated every 5 minutes. All  entries include a logo if one is
found and content is grouped by folders, hence tv series.

This works amazingly well with TiviMate, adding a new vod only provider,
i.e. with no live channels. Content shows up in the Movies tab, with
all the groups being really easy to access. All in all, it works really
really well.

Curious thing was TiviMate, thus Android's ExoPlayer, plays streams
as Chrome do, i.e., to be able to seek/forward the video, the server
needs to offer Content-Rage support, which turned up really simple to
implement, and it performs as well as nginx itself, if not better, I
haven't measured it, it barealy consumes any cpu and it is really low
latency.

The only caveat with respecto to TiviMate is it does not show dvbsubs
when played from this vod m3u, unlike everywhere else, where they are
shown just fine.

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

exceptions

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

with channel_id and channel_key

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

Add new /cloud.m3u or /nube.m3u & /cloud.xml or /nube.xml endpoints
to access Movistar IPTV Cloud Recordings with flussonic clients
adding a new IPTV Provider, better named Recordings or something
which ends positioned after the main list once ordered
alphabetically, as most clients seem to do.

Moved cloud recordings endpoint to /cloud/channel_id/flussonic_url
because /recording is better left for local recordings.

Cloud recordings are updated every 5 minutes and persisted in the epg
db while they remain in the cloud. Both m3u list of channels with
existing recordings and the respective xml guide are also kept
in sync.

The only problem ATM is most clients limit the catchup days to less
than 1 month, while Movistar keeps them several months at the very
least.

We'll see if authors of TiviMate & OTT cooperate.

Still missing filling the epg with older recordings not present
anymore in the existing catchup guide, which means new recordings
will be kept while those 1 week older than installation of this
version will not show up ATM.

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

endpoint /recording/channel_id/flussonic_url

Signed-off-by: Javier Marcet <javier@marcet.info>

endpoint, this info is returned by both getCatchUpUrl and
getRecordingData with the actual recorded data

Signed-off-by: Javier Marcet <javier@marcet.info>

--recording, get the duration for local recordings from get_vod_info()
unless specified wih --time and cleanup the disabled rtsp logging

Signed-off-by: Javier Marcet <javier@marcet.info>

required extension

Signed-off-by: Javier Marcet <javier@marcet.info>

include the stop offset, do the same for catchup programs, so logs
record both the start and the stop offsets

Signed-off-by: Javier Marcet <javier@marcet.info>

metrics for live channels too, since it is all done without slowing
down streams it is nice to have all that info available

Signed-off-by: Javier Marcet <javier@marcet.info>

metrics and logs so they show up both the channel and the program
being played (also for live streams), plus some general cleanups

Signed-off-by: Javier Marcet <javier@marcet.info>

 - Since prometheus metrics are severely limited when working in
 multiprocess mode, move the registry to our state backend, and push
 events to it, proxying back export metrics. This way we get a live
 view of streaming clients, ordered visually by their initial latency
 and where we can see the channel, the client ip, the exact url for
 catchup streams, as well as the start and end times.

 - Far from impacting the measured latencies, thanks to pushing
 events with asyncio.create_task() and moving logging to the epg
 backend, I've seen catchup streams opened in as low as 281ms.

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

them as Prometheus /metrics, segregated by channel and whether live
or catchup streams. This will be great to analyze stream response
times, for example with:

 sanic_request_latency_sec_sum{method='catchup'}/sanic_request_latency_sec_count{method='catchup'}

&

 sanic_request_latency_sec_sum{method='live'}/sanic_request_latency_sec_count{method='live'}

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

Signed-off-by: Javier Marcet <javier@marcet.info>

while handling streaming responses.

https://github.com/sanic-org/sanic/issues/2234



Signed-off-by: Javier Marcet <javier@marcet.info>