Am 19.02.2019 um 05:29 schrieb Willy Tarreau:
Hello Thomas,
On Sun, Feb 17, 2019 at 05:55:29PM +0100, Thomas Schmiedl wrote:
Hello Bruno,
I think the problem is the parsing of the .m3u8-playlist in xupnpd2. The
first entry to the .ts-file is 4 hours behind the actual time. But I
have no c++ experience to change the code.
For me if it works but not correctly like this, it clearly indicates
there is a (possibly minor) incompatibility between the client and the
server. It just happens that if your client doesn't support https, it
was never tested against this server and very likely needs to be adapted
to work correctly.
Is it possible in haproxy to manipulate the playlist file (server
response), that only the last .ts-entries will be available and returned
to xupnpd2?
No, haproxy doesn't manipulate contents. Not only it's completely out of
the scope of a load balancing proxy, but it would also encourage some
users to try to work around some of their deployment issues in the ugliest
possible way, causing even more trouble (and frankly, on *every*
infrastructure where you find such horrible tricks deployed, the admins
implore you to help them because they're in big trouble and are stuck with
no option left to fix the issues they've created).
If it's only a matter of modifying one file on the fly, you may manage
to do it using Lua : instead of forwarding the request to the server,
you send it to a Lua function, which itself makes the request to the
server, buffers the response, rewrites it, then sends it back to the
client. You must just make sure to only send there the requests for
the playlist file and nothing else.
Could someone send me such a lua-script example and how to include in
haproxy. Thanks
I personally think this is ugly compared to trying to fix the faulty
client. Maybe you can report your issue to the author(s) and share your
config to help them reproduce it ?
Regards,
Willy