- Sep 30, 2021
-
-
Javier Marcet authored
--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>
-
Javier Marcet authored
required extension Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 27, 2021
-
-
Javier Marcet authored
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>
-
- Sep 26, 2021
-
-
Javier Marcet authored
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>
-
Javier Marcet authored
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>
-
- Sep 24, 2021
-
-
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: Javier Marcet <javier@marcet.info>
-
- Sep 23, 2021
-
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
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>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 21, 2021
-
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 16, 2021
-
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 13, 2021
-
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 09, 2021
-
-
Javier Marcet authored
while handling streaming responses. https://github.com/sanic-org/sanic/issues/2234 Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 08, 2021
-
-
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: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
everybody when it is an undocumented feature outside of the commits Signed-off-by: Javier Marcet <javier@marcet.info>
-
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: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
recording ffmpegs to avoid disrupting streams Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 07, 2021
-
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
in vod Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 06, 2021
-
-
Javier Marcet authored
traces Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
so long programs like 'Cuarto Milenio' are recorded fully Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
switching times, both for live channels (in the millisecond range) and vod programs (from 300 and something milliseconds all the way up to 700-800 even, depending on Movistar's servers's response times) Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
HttpProtocol instead of patching Sanic's server.py. This also means usage outside of docker will get the optimization. Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
to go lower I need to get hired by Movistar and tune it myself. This meant a huge refactoring in vod, now fully asynchromous and runnable both from within movistar_u7d as well as a separate process, so recordings continue to be independent from movistar_u7d once launched. Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
times in the catchup Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Sep 01, 2021
-
-
Javier Marcet authored
errors; drop seek2any since it does nothing and drop max_error_rate or a redundant frame at the beginning can abort early the recordings. Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
end up as errors when they may be complete Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
- Aug 31, 2021
-
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-
Javier Marcet authored
Signed-off-by: Javier Marcet <javier@marcet.info>
-