Issue with certain streams

[Digitalone1]

Hello I noticed that aceproxy has issues with some particular streams. More specifically, streams that does not respect the live buffer option.

The majority of streams respect the live buffer option (I set it to 40 sec) and I can see the cache load when playing it through mpv. It's around 40 seconds, both using aceproxy (http://192.168.x.x:8000/pid/content-id) and the engine HTTP API (http://127.0.0.1:6878/ace/getstream?id=content-id).

There are other streams which does not respect the live buffer option: I notice this behavior when playing them on mpv and, in example, I see cache load reaching 5 minutes and then it stays around 5 minutes downloading normally.

This particular type of streams only works with the engine API. When I request them through aceproxy, it only download the parts reaching 5 minutes inside the cache, then nothing more. When playing with mpv I can see the cache loading to 5 minutes, then it decreases and is never filled with newer data. Reaching 0 seconds, the stream is stopped and mpv is shut down. But I see from aceproxy the following line:

[LINE:72 ]# ERROR ConnectionError(ReadTimeoutError("HTTPConnectionPool(host='127.0.0.1', port=6878): Read timed out."))

Don't know how to debug this. I have the content-id to reproduce this issue, but don't know if I can post here. Could I email it to you? If there's something to do in order to investigate, tell me.

[pepsik-kiev]

I know this problem. It does not apply to http api or engine api. And it applies only to the broadcast source in hls, as well as to how the AceStream code parses this data from the source and timely sends links to chunks to the client player. [LINE:72 ]# ERROR ConnectionError(ReadTimeoutError("HTTPConnectionPool(host='127.0.0.1', port=6878): Read timed out.")) This is a python requests library error, that is used by HTTPAceProxy when reading data from the engine. You can use Google to understand when it appears in this library.

I use AceStream version 3.1.51 and this error appears extremely rarely and sporadically by accident. To understand its nature, we need to add additional logging to the engine code in the ACEStream/DASH/HLS.py and HLSDownloader.py modules and track the timeouts for receiving chunks from the source and their formation for the player client... HTTPAceProxy has nothing to do with this error. Its simply states it as a fact that that an error occurs while reading data from AceEngine beyond the specified timeout (videotimeout=XX in aceconfig.py)

[Digitalone1]

I'm using Acestream 3.1.49. Are you using Acestream on Windows?

So this error is only related to HLS streams? I noticed that this happens when the stream is not respecting live cache buffer option. I wonder why if these two things are related.

Anyway, I have some sources where this issue is reproducible. Are you interested to debug it? Where can I send the content id? I don't think can post here.

[Digitalone1]

Oh, another consideration I forget to mention.

Aceproxy has nothing to do with this, but the http api is sending data continuously. The only difference with these "particular" stream is that it first fills the cache reaching several minutes (I counted 5 minutes in mpv) and then it serves data normally incrementing the cache from time to time (staying around 5 minutes of cache).

I wonder why a read timeout occurs if the http api is sending the data. It seems that Aceproxy is only able to fill the cache to 5 minutes getting the first flow of data, but it loses the remaining parts that acestream engine sends normally.

[pepsik-kiev]

So this error is only related to HLS streams?

This error only applies to HLS broadcast sources =) .... You can add a parameter --debug-all to acestream.conf аnd track the engine logs at the time of the error reading data

I wonder why a read timeout occurs if the http api is sending the data. It seems that Aceproxy is only able to fill the cache to 5 minutes getting the first flow of data, but it loses the remaining parts that acestream engine sends normally.

HTTPAceProxy reads everything that the engine gives and immediately gives the player. The data buffer in HTTPAceProxy can occur only when the client’s player’s buffer is full and it doesn’t read anymore data from HTTPAceProxy, but as soon as at least a byte of free space appears on the player and it requests data, HTTPAceProxy will immediately give this byte to the player.

p.s. HTTPAceProxy does not use HTTP API, I use only AceStream Engine API

[Digitalone1]

Using --degub-all in acestream.conf I see very few lines in acestream log. Is it the right parameter?

[pepsik-kiev]

http://dl.acestream.or…android/acestream.conf

Take debug options from this example

p.s. "--debug-all" - all possible acestream debug info in one parameter

[Digitalone1]

I left the default config. Watched the "particular" stream using aceproxy.

1. https://pastebin.com/raw/AjBaAQxS
2. https://pastebin.com/raw/0sPuSeXS
3. https://pastebin.com/raw/Vn2fcDi7

[Digitalone1]

Take a look at this:

2019-08-22 11:16:02,199|Thread-20|acestream.httpserver|acquire_inputstream: got response from mapper: streaminfo={'mimetype': 'application/json; charset=utf-8', 'stream': <cStringIO.StringI object at 0x7fafe4568ad0>, 'allow_cors': True, 'length': 61, 'content_disposition': None, 'statuscode': 200} mapper=<ACEStream.WebUI.WebUI.WebIFPathMapper instance at 0x7fafecde9b90>
2019-08-22 11:16:02,200|Thread-20|acestream.httpserver|get: not range request: close_stream=True
2019-08-22 11:16:02,200|Thread-20|acestream.httpserver|get: write done: bytes=61 time=0.000125885009766 total=61
2019-08-22 11:16:02,202|Thread-20|acestream.httpserver|get: request finished: time=0.0045919418335 bytes_sent=61

The stream get closed. Is this normal?

Edit: I see those lines also in other part of the log, seems fine.