Skip to content
  1. Oct 10, 2021
  3. Oct 09, 2021
  5. Oct 08, 2021
  7. Oct 06, 2021
  9. Oct 04, 2021
    • Javier Marcet's avatar
      movistar_u7d.py & movistar_epg.py: expose new vod only m3u playlist · 03a564a1
      Javier Marcet authored 
      
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: default avatarJavier Marcet <javier@marcet.info>
      03a564a1
  11. Oct 03, 2021
  13. Oct 02, 2021
  15. Sep 30, 2021
  17. Sep 27, 2021
  19. Sep 26, 2021
  21. Sep 24, 2021
    • Javier Marcet's avatar
      movistar_u7d.py, movistar_epg.py & grafana-dashboard.json: · 061a16d8
      Javier Marcet authored 
      

 - 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: default avatarJavier Marcet <javier@marcet.info>
      061a16d8
  23. Sep 23, 2021
  25. Sep 21, 2021
  27. Sep 16, 2021
  29. Sep 13, 2021
  31. Sep 09, 2021
  33. Sep 08, 2021
    • Javier Marcet's avatar
      movistar_u7d.py, vod.py: turns out prioritizing normal clients over · 9ebd595d
      Javier Marcet authored 
      
recordings by killing one of the later, works quite smoothly.

This proxy is now able to serve cathcup programs as fast as Movistar
can deliver them, whilt at the same time maximizing the available
iptv bandwidth to server multiple clients and handle simultaneous
recordings, all without disturbing ongoing normal clients at any
moment.

Recordings are repeated when they fail so no issue killing them when
the need arises. Also bear in mind the memory allocated to the
container if handling recordings dynamically. 2GB seems to work
quite well to consume the 100mbps of iptv bw.

Besides that, the server is also able to cope with ddos attacks quite
well, all, as usual, without ongoing clients noticing anything.

In other words, it is ready to serve the bigggest of the families who
might be Movistar Fiber IPTV's customers.

TV glitches with Movistar IPTV (with decent network hardware) are a
thing of the past :D

Signed-off-by: default avatarJavier Marcet <javier@marcet.info>
      9ebd595d
    • Javier Marcet's avatar
      movistar_epg.py: fix silly mistake which made recordings enabled for · d8e42f64
      Javier Marcet authored 
      
everybody when it is an undocumented feature outside of the commits

Signed-off-by: default avatarJavier Marcet <javier@marcet.info>
      d8e42f64
    • Javier Marcet's avatar
      Control dynamically the number of allowed clients (and recordings), · f0cad193
      Javier Marcet authored 
      
although only for installations within the router itself, since to
control the iptv bw, the proxy needs direct access to the iptv
interface, otherwise measuring the used bw is a much more complicated
matter.

The maximum allowed iptv bw is set to a sane default of 85000 kbps,
out of a maximum capacity of 100000 kbits/second.

Since the avergae HD channel is around 6-8mbps, 85000 should be enough
to avoid deadlocking the remaining clients. This limit can be adjusted
with the env var IPTV_BW with the allowed bw in kbps, up to a maximum
of 90000, anything above will be cut down to 90000 kbps.

This is to ensure the smooth operation of all the existing clients,
when the limit if exceeded, streams start to drop packets.

Last, to also ensure regular clients are not rejected due to ongoing
recordings, with the IPTV_BW_RECS, by default set at 75000, you can
set the maximum bw usage over which recordings will be rejected.

It might me interesting to cancel the most recent ongoing recording
when a regular client wants to tune open a stream, I have to measure
if it would be fas enough to still be seamless for regular clients,
i.e., not seeing a 503 upfront and forcing the user (if the client is
not smart emough) to reopen the stream.

Signed-off-by: default avatarJavier Marcet <javier@marcet.info>
      f0cad193