No Stream Buffer Update

[chris102994]

Is your feature request related to a problem? Please describe. I was attempting to simply use a xTeVe docker container I made in order to organize streams on my unraid server. Since my container (or any others) don't yet support nvidia GPU the buffer options aren't as efficient as the emby container that does. Thus I would rather use it's ffmpeg to stream. An non-intuitive problem occurred when using the No Buffer option happened. xTeVe remuxed the stream and passed my emby server a .ts file that (for some reason) it couldn't start a stream from. (I'm assuming it requires the full m3u8.

Describe the solution you'd like An option to enable and disable muxing so that the No Buffer option can be more robust in integrating with Emby.

Describe alternatives you've considered Updating my container to use nvidia to ensure a good stream while using this on unraid. Which I plan on doing eventually. . . But requires me to rebase from alpine to debian since I need glibc rather than musl.

Additional context N/A

[mar-mei]

If the buffer is deactivated, the streaming URL from the M3U is sent to Emby / Plex via HTTP redirect. How did you set up xTeVe in Emby, M3U or HDHomeRun tuner? I have heard from the Emby developers that the HDHR tuner can only process TS streams.

[chris102994]

I have it as an m3u tuner.

[mar-mei]

Does the xteve.m3u work with VLC?

[chris102994]

No. It says Your input can't be opened: VLC is unable to open the MRL: <fqdn> check logs...

The logs say:

main debug: looking for meta fetcher module matching "any": 1 candidates
main debug: looking for access_demux module matching "https": 15 candidates
main debug: no access_demux modules matched
main debug: creating access: https://myserver.duckdns.org:443/stream/3fd839b2ffe8ad2522a4785cd8ede8e4
main debug:  (path: \\myserver.duckdns.org:443\stream\3fd839b2ffe8ad2522a4785cd8ede8e4)
main debug: looking for access module matching "https": 26 candidates
lua debug: Trying Lua scripts in C:\Users\name\AppData\Roaming\vlc\lua\meta\fetcher
lua debug: Trying Lua scripts in C:\Program Files (x86)\VideoLAN\VLC\lua\meta\fetcher
main debug: no meta fetcher modules matched
main debug: looking for art finder module matching "any": 2 candidates
lua debug: Trying Lua scripts in C:\Users\name\AppData\Roaming\vlc\lua\meta\art
lua debug: Trying Lua scripts in C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art
main debug: looking for tls client module matching "any": 1 candidates
lua debug: Trying Lua playlist script C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\00_musicbrainz.luac
gnutls debug: using GnuTLS version 3.5.18
lua debug: skipping script (unmatched scope) C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\00_musicbrainz.luac
lua debug: Trying Lua playlist script C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\01_googleimage.luac
lua debug: skipping script (unmatched scope) C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\01_googleimage.luac
lua debug: Trying Lua playlist script C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\02_frenchtv.luac
lua debug: skipping script (unmatched scope) C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\02_frenchtv.luac
lua debug: Trying Lua playlist script C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\03_lastfm.luac
lua debug: skipping script (unmatched scope) C:\Program Files (x86)\VideoLAN\VLC\lua\meta\art\03_lastfm.luac
main debug: no art finder modules matched
gnutls debug: loaded 80 trusted CAs from system
main debug: using tls client module "gnutls"
main debug: resolving myserver.duckdns.org ...
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Success.
gnutls debug:  - safe renegotiation (RFC5746) enabled

[mar-mei]

TLS fails. I guess you're using a reverse proxy. With proxy I can not help you.

_{Sent with GitHawk}

[chris102994]

I understand however, I can confirm it also didn't work without one. Since it's on unraid and the container doesn't currently support GPU (and even if it did it couldn't use the same one as emby) I have to use emby to do the transcoding in ffmpeg. I had to put emby on the VPN in addition to xteve. Since I do this the only way emby can communicate is with a reverse proxy. Either way if all it is doing is handing the .ts there should be no problem. I think that enabling xteve to simply give the m3u8 link rather than this obfuscation as an option will be extremely useful. Please consider this for people wanting to simply use it as a channel manager and sorter.

[mar-mei]

xTeVe is not an M3U editor. The URLs in the xteve.m3u must point to xTeVe so that changes to the buffer take effect immediately without updating the M3U.

If the buffer is deactivated, the client gets the original streaming URL from the source M3U. The client only needs to understand HTTP redirects.

CURL -> xTeVe buffer off:

curl -I http://xteve.local:34400/stream/433d7649b9a5b6db475bcd682d403e4c
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: rtsp://192.168.178.252:554/?avm=1&freq=330&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,5100,5101,1170,1176,2171,2172,5102,5103,5104,5105
Date: Sun, 19 Jan 2020 15:32:47 GMT

The way in which the client connects to the streaming server is up to the client.