Skip to content
  1. Oct 03, 2021
  2. Oct 02, 2021
  3. Sep 30, 2021
  4. Sep 27, 2021
  5. Sep 26, 2021
  6. 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
  7. Sep 23, 2021
  8. Sep 21, 2021
  9. Sep 16, 2021
  10. Sep 13, 2021
  11. Sep 09, 2021
  12. 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
    • Javier Marcet's avatar
      vod.py: die cleanly · f78b84d5
      Javier Marcet authored
      
      
      Signed-off-by: default avatarJavier Marcet <javier@marcet.info>
      f78b84d5
    • Javier Marcet's avatar
      vod.py: nice up all ffmpeg/ffprobe/mkvmerge processes but the · 0c490599
      Javier Marcet authored
      
      recording ffmpegs to avoid disrupting streams
      
      Signed-off-by: default avatarJavier Marcet <javier@marcet.info>
      0c490599
  13. Sep 07, 2021
  14. Sep 06, 2021
  15. Sep 01, 2021