Read through there, I think you have the same problem.
#74

You have to configure HTTPS in your proxy, there is already a topic here
#80

I call the update.xepg through the cronjob.sh of alturismo's docker container via localhost (because its the same host, why i shouldn't?). After that xteve changes the url in xteve.xml -> Plex won't load icons anymore.

Now i go to the web interface that i am accessing through a reverse proxy and make some changes in the mapping. Again another wrong url in xteve.xml -> Plex won't load icons anymore.

To get the right url in xteve.xml i have to access the web ui in the same way plex can access it?
Thats definitely a lack in design!

Just provide a possibilty to override this url used in xteve.xml otherwise people will get a headache this way.

And why don't you use the reverse proxy URL for Plex?

I now have finally fixed my problems with my icons.
Letting plex connect through the reverse proxy allows my remote plex client to download the icons through the reverse proxy.

The reason one rather have plex connect through the internal docker network is for portability.
If you ever change domainname, you have to manually change the new URL for the DVR in plex.

Not much work you can say, but if you have to do it for 100's of configurations / containers...

The docker network allows name resolution, so you could connect to http://xteve:34400 which resolves to the docker internal network ip address of the xteve container. This will always be the same, no matter what DNS name you are using on your proxy.

By using internal docker networking everything works fine, except for the icons, because a remote client (on the wan) also would look on the internal URL to download the icon. Somehow plex decided not to proxy those icons.

This is not a design issue with Xteve in my opinion. Plex proxies everything, except for the icons which is inconsistent to say the least.

Xteve has an option to cache icons. By choosing not to cache icons, xteve will retain the original URLs / locations of the icons. Disabling that option allows you to use internal networking between plex and xteve, while still having the icons.

I now have finally fixed my problems with my icons.
Letting plex connect through the reverse proxy allows my remote plex client to download the icons through the reverse proxy.

The reason one rather have plex connect through the internal docker network is for portability.
If you ever change domainname, you have to manually change the new URL for the DVR in plex.

Not much work you can say, but if you have to do it for 100's of configurations / containers...

The docker network allows name resolution, so you could connect to http://xteve:34400 which resolves to the docker internal network ip address of the xteve container. This will always be the same, no matter what DNS name you are using on your proxy.

By using internal docker networking everything works fine, except for the icons, because a remote client (on the wan) also would look on the internal URL to download the icon. Somehow plex decided not to proxy those icons.

This is not a design issue with Xteve in my opinion. Plex proxies everything, except for the icons which is inconsistent to say the least.

Xteve has an option to cache icons. By choosing not to cache icons, xteve will retain the original URLs / locations of the icons. Disabling that option allows you to use internal networking between plex and xteve, while still having the icons.

This answer is another prove for the unnecessary complexity of the image caching. To disable the caching is my current workaround and there are a lot of possible workarounds for this problem. But the design of software should not be to force the user using workarounds to access its features.

And why don't you use the reverse proxy URL for Plex?

I don't want to add another dependency to plex and it would not match my network design. Maybe I have to because an outside client has to access xteve to load images like solipsist01 said but thats another point.

It is rather an issue because an access through another url (and making changes in the mapping for example) changes the url for another service like in this case plex. You have to invest time to understand this behavior to avoid it or have a workaround for it.

@solipsist01
You seem to have another network problem. Each Plex Client in the WAN only connects to the Plex Server. Plex caches the icons, no client connects to xTeVe for icons or streams.

@klatka
Let's assume someone implements such a function. I understand it like this, you would like to have an input field by entering a "Base-Address". This address would then be inserted in all links pointing to xTeVe?

Icon Example Base Address:

<channel id="1032">
    <display-name>ESPN</display-name>
    <icon src="http://MY_BASE_ADDRESS:34400/images/15dbb84da186ab92ba3de8d8ab7d10b6.png"></icon>
</channel>

What would you enter there in your network constellation?

Let's assume someone implements such a function. I understand it like this, you would like to have an input field by entering a "Base-Address". This address would then be inserted in all links pointing to xTeVe?

Yes, but more general (maybe someone wants to change port or proto):

<channel id="1032">
    <display-name>ESPN</display-name>
    <icon src="MY_BASE_URL/images/15dbb84da186ab92ba3de8d8ab7d10b6.png"></icon>
</channel>

What would you enter there in your network constellation?

In my case: http://xteve.stack_local:34400 to have the same value like in plex dvr settings. Then i could change settings through reverse-proxied webui or api knowing that plex icons still will work because this url is overridden with a static one.

I use traefik v2 as a reverse proxy.
It has a rule which exposes https://xteve.domainname.com
It reverse proxies http://xteve:34400
Also configured is a forwardauth configuration with 2factor authentication.

I use this, so i can login safely into my environment using 2factor auth.
the DVR in plex is setup to http://xteve:34400 (internal URL)

I have tested the following:
Enable image caching in Xteve

docker exec -it plex bash
wget http://xteve:34400/xmltv/xteve.xml

cat xteve.xml shows that image urls are http://xteve.domainname.com/images/f25ca48ff66828f9ca1a465e44329fe2.png
This ofcourse will not work, because the plex container will never 2factor auth.

Perhaps extracting the Request URL from the requestheader to get the desired base url?

In my case: http://xteve.stack_local:34400 to have the same value like in plex dvr settings. Then i could change settings through reverse-proxied webui or api knowing that plex icons still will work because this url is overridden with a static one.

I suspect http://xteve.stack_local:34400 can only be reached from the LAN.

The following requests from the WAN would no longer be possible if there was a local address in the files.

http://my_home.dyndns.org:34400/m3u/xteve.m3u
http://my_home.dyndns.org:34400/xmltv/xteve.xml
http://my_home.dyndns.org:34400/images/some_image.jpg

As already described above: If all clients, regardless of whether Plex, Emby, IPTV Player or VLC use the same URL and this can be resolved via DNS, it already works.

xTeVe looks at the HTTP headers with every request to find the Request URL via which the call was made. Except for the for the xteve.xml file, this URL is used immediately for Plex / Emby DVR, M3U and images. It takes too long for slower servers to create the xteve.xml for several hundred channels and some clients then run into a timeout.

MY_BASE_URL should also be used in xteve.m3u if manual override is active.

I suspect http://xteve.stack_local:34400 can only be reached from the LAN.

The following requests from the WAN would no longer be possible if there was a local address in the files.

There is no need for me to access xTeVe from the WAN (if Plex proxies everything from xTeVe).
If someone manual overrides the MY_BASE_URL to a static string with local hostname in it, he shouldn't be suprised that he can't access this requests from the WAN.

If someone manual overrides the MY_BASE_URL to a static string with local hostname in it, he shouldn't be suprised that he can't access this requests from the WAN.

Correct and therefore the URL from the last request is used, then it also works for 99% of people.

So you can not use xTeVe with two different URLs at the same time.

This is possible if all clients can resolve all URLs.
xTeVe is a web server with the difference that you don't have to configure which domain or IP should answer queries.

I saw screenshots where people copied the xteve.m3u URL to Plex DVR. If they still have to fill up fields with a Base_URL, I have no peace at all.

I understand your point but this can be an optional, more expert option like FFmpeg Options.

xTeVe is a web server with the difference that you don't have to configure which domain or IP should answer queries.

xTeVe looks at the HTTP headers with every request to find the Request URL via which the call was made. Except for the for the xteve.xml file, this URL is used immediately for Plex / Emby DVR, M3U and images. It takes too long for slower servers to create the xteve.xml for several hundred channels and some clients then run into a timeout.

Is that mentioned in the docs? It would save me a lot of time.

xTeVe looks at the HTTP headers with every request to find the Request URL via which the call was made. Except for the for the xteve.xml file, this URL is used immediately for Plex / Emby DVR, M3U and images. It takes too long for slower servers to create the xteve.xml for several hundred channels and some clients then run into a timeout.

What if you didn't create it from scratch, but do a search and replace. That would take less time methinks.

Could be an advanced option which you enable or disable

Is that mentioned in the docs? It would save me a lot of time.

I have to check if it is missing, I add it.

What if you didn't create it from scratch, but do a search and replace. That would take less time methinks.

Could be an advanced option which you enable or disable

I have not yet fully understood why different clients access xTeVe via different URLs.

If it is only about Plex that contains the "wrong" URL during an XMLTV update, this can certainly be solved now with the xTeVe API.

I have not yet fully understood why different clients access xTeVe via different URLs.

This is my usecase.

I have hosted a server offsite.
On this server is running Xteve and Plex in docker containers.
Plex connects to the Xteve microservice on the internal docker network

On this server is also running a reverse proxy which only listens to ip addresses of cloudflare.
Cloudflare is also a reverse proxy which reverse proxies the reverse proxy running on on the offsite server.
DNS records point to cloudflare.

Onsite i have a raspberry pi 4 with Kodi on it.
Kodi connects to the server (through cloudflare and the reverse proxy) with an IP whitelist rule to Xteve for providing liveTV

I connect from my work location to Xteve to make a quick adjustment, via 2factor auth.

You could say, why not connect plex to xteve through the reverse proxy?
Plex would be dependant of the reverse proxy, and all traffic would be routed through cloudflare.

We could also make a path which isn't routed through cloudflare, but why do that when we can connect internally.

In the docker world, Microservices always connect internally to eachother. All my services do.

However, for me this isn't a big issue, because i just don't cache the icons. This solution is also perfectly viable for me. It is however inconsistent.

It's a bit more complex. I have no idea what the Cloudflare network looks like from the inside. But I would simply run an update.xepg 5 minutes before Plex updates the EPG via xTeVe API and curl and there is already the correct icon URL in the xteve.xml file.

@solipsist01
may "in the docker world" to make adjustments and dont open xteve webui, rather use a browser in docker to access local sites and edit them ... then it would be solved too ;)

i also use xteve in docker, plex in docker, reverse proxy in docker, remote access overall ... etc etc ...
but this discussion about a hard coded link in xml is obviously ... it really makes more sence its handled now, specially for your special purposes u have a api feature ... use it and u done, 1 line cron job for special purposes ... instead rewrite and produce errors for alot more users who want the links fitting the client without hard setting something, forgetting about it .. and then asking ...

After all there should be a possibility to disable the automatic recognition and changing of IP or FQDN through the request. I don't want to get everything generated with the wrong URL just to call the api from the right network to generate the files again with the right URL that plex can connect to.

People will run into this issue because its a very unexpected behavior and i think that you always will have some open issues with this topic. A simple setting would solve this and all related issues completely.

see how different the views are, and i really dont understand why you just not use the api call with a proper ip, and call it before your plex update and(or even use the plex update function from my docker ... then u have xteve update properly and plex right behind ... set the plex internal timer just besides it and there is nothing u have to worry about, but u always have the proper setup from anywhere u call xteve actually ... plex only updates once / day ... come on ....

You have to understand that for new users it is not easy to understand that behavior. You are using this workaround and it works, now i am using it too. But look how many issues there are on github related to this behavior...
The additional option in settings i asked about would help new users to avoid spending a lot of time to understand and implement this workaround.
This is a proxy for Plex, i don't understand why it is so important to have always the proper setup from anywhere you call xteve.. And the good thing about an optional setting is that you don't have to use it, but there are obviously some people who would use it.

I have now a working setup for plex with a workaround to use xTeVes web ui with a reverse proxy without losing the ability of plex to connect to xTeVe. Thanks for your time.

You can also disable image caching. A quick look at the Plex Client and you can see that Plex also caches the images.
background-image: url("blob:http://plex.local:32400/9a1186af-ffba-4172-a435-075e383574af");

width: 80px;
height: 60px;
background-image: url("blob:http://plex.local:32400/9a1186af-ffba-4172-a435-075e383574af");
background-size: contain;
background-position: center center;
background-repeat: no-repeat;

Can we reopen this issue? I have xteve running on a server that has an internal IP, and a VPN IP. Xteve has chosen the VPN IP for the ip address it uses in xteve.xml This is a problem for two reasons:

1. I don't allow that port through the firewall over the VPN
2. I don't want internal users attempting to resolve external IP addresses to play resources.

Just like we can specify a port for xteve, we should be able to specify the IP address or hostname uses in the xml file.

That's quite the same issue I ran into.

I still think that this issue will be a problem for new users but I don't think that somebody will create an option in xTeVe to change the base URL or IP...

Reopened to arouse some importance :)

this can and will only be a issue when you dont use xteve like intended to use

it uses the ip which is triggered, so use the ip u with by using the ip way and not the path.

sample, u trigger externally, xteve will write the external ip to the xml due its been called there, now, when u use the path for another client it will have the path in there, when u use the ip to fetch it has the internal ip like its supposed ...

static would mean in case u use both ways you have issues, the way it is now its just a wrong setup on your client sides ...

may to make a more real life scenario

xteve on host
client(s)
plex server on host (using local path to xteve file's)
kodi on remote (using remote url to xteve file's)
--> plex will have remote addresses in its file(s) due kodi is externally triggering xteve to update file(s)

xteve on host
client(s)
plex server on host (using local url to xteve file's)
kodi on remote (using remote url to xteve file's)
--> plex and kodi will have the correct url's in its own enviroments due they trigger them for themselves

or as described, simple make a api call from your prefered location before "whatever" u do on updating from whereever to keep your xml files the way you want them, its a oneliner ...

The problem is still that this design has no separation between admin (Web UI) calls and service (plex) calls. They don't have to be in the same network... In other words, there are many users with their own network setups who can not benefit from your easy but restrictive design.

In this setup where it is necessary to separate every time you access the UI, you have to make sure to run the API call.

This issue is not really big after you understand (or developed) it but it is a potential headache for new users (and I don't think that this software is intended to be used by users, who don't know how to use a mouse....).

may point out a real life scenario so i could potentially follow the "issue" you have

webui management externally through reverse proxy as sample, when you hit save, yes, it will use the url you connected to xteve (some external ip), now your client (lets say plex for sample on the host mashine) which is using the external ip is your issue i assume then cause the management was done externally before, then yes, you have to use the oneliner ...

and now we are at the point, when you use xteve like this you should know what you do and be capable to cron your oneliner

Yes we are capable of a cron oneliner.
Oneliner or not, at least we could admit that it's inconsistent.

It doesn't matter which hostname i use to visit the webinterface. The webinterface adjusts itself, and the URLS according to the request URL.

The XML file however does not.

The reason people keep bringing this up, is that one gets surprised that the XML file behaves different then you'd expect.

Was hit by this myself. As a new xteve user this weekend, first of all THANK YOU!

I have a simple server setup with a single configured IP address, but I also run libvirtd which creates a default network bridge (192.168.122.1/24).

For some reason xteve picks 192.168.122.1 as it's preferred address to populate the generated files. For example:

#EXTINF:0 channelID="x-ID.2" tvg-chno="1002" tvg-name="FCAM1" tvg-id="1002" tvg-logo="" group-title="Wayne Manor",FCAM1
http://192.168.122.1:34400/stream/7c5c0654320cdb2102494df3ea3ef61b

I went looking for an option to change this, but sadly I ended up here.

I have the same problem.

Even if I get my .m3u file from an external https url, all logos inside are using a docker-network internal url.
So my Plex is not showing any logo.

If I remove image caching I think it kinda solves my problem, but I would love to keep image caching on.

Is there any way to solve this ?

I guess there is still no real solution for this problem? it seems like all we are asking for is an option to specify the host IP address so using cached images it shows as the base url address in .m3u and .xml

They wont fix this issue. They even ignored the pull request, because of stubborness.

Apparently they fix everything with cron oneliners.

Also, this project is dead.
There is an active fork though. Highly recommend.

https://github.com/Threadfin/Threadfin

I wonder if brycelarge/xteve-vpn works with Threadfin.

There are serperate openvpn containers. You can attach every container to that vpn container you like. When im behind a computer, i can share a docker-compose example :)

version: '3.4'
services:
  vpnstack:
    container_name: vpnclient
    image: ghcr.io/xstar97/openvpn-client
    cap_add:
      - net_admin
    read_only: true
    tmpfs:
      - /run
      - /tmp
    security_opt:
      - label:disable
    stdin_open: true
    tty: true
    volumes:
      - /dev/net:/dev/net:z
      - ${CONFIG}/vpnclient:/vpn
    command: -f -d -a 'username;password' -o --mute-replay-warnings
    networks:
      - vpn
    restart: always

  deluge:
    container_name: deluge
    image: binhex/arch-deluge
    depends_on:
      - vpnstack
    environment:
      - PUID=0
      - PGID=0
      - TZ=${TZ}
    network_mode: "service:vpnstack"
    volumes:
      - ${CONFIG}/deluge/config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: always

traffic from container deluge will be routed through the VPN.

Thanks for sharing, that's a good solution.