Playback loop with HLS

[gr3m1in]

Good day,

I'm having problem with configuring HTTPAceProxy for HLS streaming. Basically it looks working, video and audio are fine. But the content itself is looped within about one minute.

There is no such problem with HTTP progressive streaming, but the stream is not that stable.

Operating system is Linux, in case it matters. Stream is viewed using VLC. Config file is attached (renamed with txt extension because of github upload naming limitation)

Is is this a bug or is there something I'm missing?

Any advice is deeply appreciated. Thanks in advance.

aceconfig.py.txt

[pepsik-kiev]

Hi ! I need a link to log file (www.pastebin.com) of the proxy at the time of looping where I can see translation PID so that I can repeat this situation

[gr3m1in]

Thank you for quick response!

This log contains the whole interval from service and playback start up to loop moment few seconds before playback and service were stopped. https://pastebin.com/ukTLUgK2

[pepsik-kiev]

I would recommend not to use hls in the stream type request settings from AceEngine in aceconfig.py. This does not affect the proxy stream output and only loads extra work AceEngine for cutting hls chunks from http progressive download. 95% of the broadcasts that you can find in the network are not hls... Setting up a stream request in hls is left to support archived recordings of TTV broadcasts

Based on your log, I do not see any proxy errors and I think that the translation looping is related to the cutting of hls from http progressive download by AceEngine, more precisely, the long-term buffering of AceEngine and the lack of data for cutting. Therefore, Ace loops through the stream in "ready" hls chunks until it receives the next sufficient portion for slicing from broadcaster.

Most likely it was a coincidence. I've been watching SpongeBob cartoon on a 2x2 channel (TTV broadcasting) for 40 minutes with "hls-ON" in aceconfig.py and there are no loops :(

[pepsik-kiev]

p.s. XXI century in the yard =) Try the fresh 3.1.35 instead of being 3.1.16 operated by you ... http://acestream.org/downloads/linux-beta/acestream_3.1.35_ubuntu_18.04_x86_64.tar.gz

[gr3m1in]

You're right things should be kept up-to-date.

After updating acestream-engine to v.3.1.35, HLS streaming stopped working at all, while progressive download works fluently. StreamReader:ReadTimeout(ReadTimeoutError("HTTPConnectionPool(host='127.0.0.1', port=6878): Read timed out. (readtimeout=30)",),)` Please take a look at the full log https://pastebin.com/KZQya6Kq

[gr3m1in]

I also tried to increase videotimeout to over two minutes, however it didn't help. Additionally, it caused an exception: https://pastebin.com/D2As1MR8

Is there any additional HLS-specific configuration required?

[pepsik-kiev]

You're right things should be kept up-to-date.

After updating acestream-engine to v.3.1.35, HLS streaming stopped working at all, while progressive download works fluently. StreamReader:ReadTimeout(ReadTimeoutError("HTTPConnectionPool(host='127.0.0.1', port=6878): Read timed out. (readtimeout=30)",),)` Please take a look at the full log https://pastebin.com/KZQya6Kq

According to your log, you continue to make a stream request from the AceEngine in hls. It is not necessary. This does not affect the type of stream sent by the proxy. It will always be http progressive download. Enter the value for acestreamtype = {'output_format': 'http'} in aceconfig.py

StreamReader:ReadTimeout(ReadTimeoutError("HTTPConnectionPool(host='127.0.0.1', port=6878): Read timed out. (read timeout=30)",),) This error indicates that the reader of the stream from AceEngine did not wait for data from it more than videotimeout = sec. In other words, AceEngine, for some reason, has ceased to give data more than given videotimeout = sec. You can understand the reason for this only in the log of AceEngine itself.

I also tried to increase videotimeout to over two minutes, however it didn't help. Additionally, it caused an exception: https://pastebin.com/D2As1MR8

Is there any additional HLS-specific configuration required? 1) Errors in this log are not related to videotimeout =. It was my fault and yesterday I corrected the source of the proxy so that these errors no longer occur. I would recommend setting the value to viseotimeout = no more than 60 seconds. Otherwise, you may encounter a situation in which the player you are using to view itself disconnects from the proxy on its own readtimeout 2) AceProxy does not have any settings for hls-output, since it always ALWAYS sends data in http progressive download with "Transfer-encoding: chunked". AceProxy can only REQUEST a stream in hls from AceEngine to work correctly with archived channel broadcasts in the official TTV widget for SmartTV (Samsung, LG etc.).

[pepsik-kiev]

p.s.

acehttp.py [LINE:403 ]# INFO [07.03 17:16:08] Ace Stream HTTP Proxy server on Python 2.7.12 starting ..... acehttp.py [LINE:404 ]# DEBUG [07.03 17:16:08] Using: gevent 1.4.0, psutil 5.5.0 acehttp.py [LINE:275 ]# DEBUG [07.03 17:16:08] AceEngine start up ..... acehttp.py [LINE:436 ]# INFO [07.03 17:16:08] Local AceStream engine spawned with pid 14 acehttp.py [LINE:466 ]# INFO [07.03 17:16:18] Load Ace Stream HTTP Proxy plugins ..... acehttp.py [LINE:474 ]# DEBUG [07.03 17:16:18] Plugin loaded: Stat acehttp.py [LINE:474 ]# DEBUG [07.03 17:16:18] Plugin loaded: Torrentfilms

Why don't you use ready-made plugins to form playlists? It's comfortable, just try =) Why do you manually add PID of translations to the VLC links ? ------> https://github.com/pepsik-kiev/HTTPAceProxy/issues/5

[gr3m1in]

Thank you for clarifying. I was thinking that it is about output format from proxy to player. Now I see it's definitely pointless to set HLS in configuration.

I'm using my own playlist builder to perform some filtering, additional sorting and grouping. Also when playlist refreshes at server-side, all players keep using old playlist and require manual playlist re-fetch. I'm writing my playlist builder to avoid sending acestream PIDs to players, and to build playlist urls based on channel names (base64-encoded) which are decoded at server side and mapped to real PID from the latest refresh. Then the request is being rewritten with proper PID and proxied to aceproxy. This adds a bit of automation :)

[pepsik-kiev]

I'm using my own playlist builder to perform some filtering, additional sorting and grouping. Also when playlist refreshes at server-side, all players keep using old playlist and require manual playlist re-fetch. I'm writing my playlist builder to avoid sending acestream PIDs to players, and to build playlist urls based on channel names (base64-encoded) which are decoded at server side and mapped to real PID from the latest refresh. Then the request is being rewritten with proper PID and proxied to aceproxy. This adds a bit of automation :)

The choice is yours =) But the same principle of updating PID broadcasts is also used in embedded plugins + using 'If-Modified-Since', 'Last-Modified' and 'If-None-Match' headers for requested and sent playlists to keep it fresh + updateevery= parameter in the config file of the corresponding plugin. And you can write your own playlist builder/parser using as example "built-in" plugins ....

p.s. For 'sorting' & 'grouping' just look in /modules/playlist.py .....