Running behind Gluetun results in Exit code 4, stream does not start

[sparkison]

Describe the bug

This may be simply missing from the docs, but it seems that running through a Gluetun service the streams fail to start.

To Reproduce

Steps to reproduce the behavior:

1. Using the docker compose included below, compose the project (replacing the VPN credentials with your own provider details and updating the m3u urls). When attempting to play one of the streams from the playlist, the stream does not start and Exit code 4 is shown in the logs.
2. When bypassing the Gluetun network, the proxied stream works as expected.
3. The playlist sync is working fine, as do the various endpoints, e.g: /playlist.m3u

Expected behavior

Stream should work via Gluetun.

Actual behavior

Error received when attempting to stream: Exit code 4

docker-compose.yml contents

version: "3"
services:
  # Gluetun VPN
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    network_mode: bridge
    hostname: gluetun
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - VPN_SERVICE_PROVIDER=surfshark
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${SURFSHARK_KEY}
      - WIREGUARD_ADDRESSES=${SURFSHARK_IP}
      - COUNTRY="United States"
      - FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24
      - UPDATER_PERIOD=24h
      #- HTTPPROXY=on # Expose port 8888 to connect
      #- HTTPPROXY_STEALTH=on
    volumes:
      - /apps/gluetun:/gluetun
    ports:
      #- 8888:8888/tcp # HTTP proxy
      - 8001:8001/tcp # Built-in HTTP control server
      - 7001:7001 # M3U Stream Merger Proxy
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    restart: unless-stopped
  # M3U Stream Merger Proxy
  m3u-proxy:
    image: sonroyaalmerol/m3u-stream-merger-proxy:latest
    container_name: m3u-proxy
    network_mode: service:gluetun
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - PORT=7001 # Override the default port
      - DEBUG=true
      - BUFFER_MB=2
      - SYNC_ON_BOOT=true
      - SYNC_CRON=0 0 * * *
      - M3U_URL_1=https://iptvprovider1.com/playlist.m3u
      - M3U_MAX_CONCURRENCY_1=5
      #- M3U_URL_2=https://iptvprovider2.com/playlist.m3u
      #- M3U_MAX_CONCURRENCY_2=1
      #- M3U_URL_X=
    volumes:
      # [OPTIONAL] Cache persistence: This will allow you to reuse the M3U cache across container recreates.
      - /apps/m3uproxy:/m3u-proxy/data
    restart: unless-stopped
    # Ports exposed via gluetun service
    #ports:
    #  - 7001:7001
networks: {}

Container/Host Logs

m3u-proxy      | 2024/12/26 23:08:57 Received request from 192.168.1.19:49199 for URL: /p/api/stream/iptvprovider1.com/livetv/KLUv_QQA1QIAooUTGXA3AsQhum4lWiWz3cQNUYCmHJ74NQIAiBWJBYNztzQlbU7M4elDBURVSzH60FAIMpyTz7XJeUttbQ4UgPPkQBQhHbr5LcjYcY5WVUcEAgCGwlAqZOIBW--fIg.m3u8
m3u-proxy      | 2024/12/26 23:08:57 [DEBUG] Stream attempt 1 out of 5
m3u-proxy      | 2024/12/26 23:08:57 Current number of connections for M3U_1: 0
m3u-proxy      | 2024/12/26 23:08:57 [DEBUG] Successfully fetched stream from https://iptvprovider1.com/livetv/channel.100.m3u8
m3u-proxy      | 2024/12/26 23:08:57 [DEBUG] Headers set for response: map[Access-Control-Allow-Headers:[Origin, X-Requested-With, Content-Type, Accept] Access-Control-Allow-Methods:[GET, OPTIONS] Access-Control-Allow-Origin:[*] Cache-Control:[max-age=5] Connection:[keep-alive] Content-Type:[application/vnd.apple.mpegurl] Date:[Thu, 26 Dec 2024 23:08:57 GMT] Etag:["676de204-ed"] Expires:[Thu, 26 Dec 2024 23:09:02 GMT] Last-Modified:[Thu, 26 Dec 2024 23:08:52 GMT] Server:[nginx]]
m3u-proxy      | 2024/12/26 23:08:57 Proxying 192.168.1.19:49199 to https://iptvprovider1.com/livetv/channel.100.m3u8
m3u-proxy      | 2024/12/26 23:08:57 Exit code 4 received from https://iptvprovider1.com/livetv/channel.100.m3u8
m3u-proxy      | 2024/12/26 23:08:57 Finished handling GET request: 192.168.1.19:49199
m3u-proxy      | 2024/12/26 23:08:57 Client disconnected: 192.168.1.19:49199

[sonroyaalmerol]

Hi, @sparkison! Exit code 4 is not an error code and should still proceed to play the stream on the client side. I don't see how gluetun would affect this behavior. Were you able to stream without gluetun?

Also, can you try putting in the stream URL (the one with /p/api/stream/iptvprovider1.com/livetv/xxxxx.m3u8) in a browser and see if the contents are in proper .m3u8 format?

[sparkison]

Hi @sonroyaalmerol! Thank you for the help!

It looks like the link is downloading a valid .m3u8 file. I did notice that when loading directly from the IPTV provider it returns just the section name and when loading through the proxy it returns a full URL. When following the URL, I do get a 403 forbidden error, so guessing that has something to do with it.

Here's an example of the returned .m3u8 connecting directly to the IPTV provider:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:12
#EXT-X-MEDIA-SEQUENCE:2072
#EXTINF:12.008000,
17003091_2072.ts
#EXTINF:12.008000,
17003091_2073.ts
#EXTINF:12.008000,
17003091_2074.ts
#EXTINF:12.008000,
17003091_2075.ts
#EXTINF:12.008000,
17003091_2076.ts

And when grabbing the same .m3u8 file via M3U Stream Proxy:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:12
#EXT-X-MEDIA-SEQUENCE:2061
#EXTINF:12.008000,
https://80-251-153-103.my-servers.top:5052/live14/0tcVkW3Sa9-9JxeorPloXg/939092/1735693882/17003091_2061.ts
#EXTINF:12.008000,
https://80-251-153-103.my-servers.top:5052/live14/0tcVkW3Sa9-9JxeorPloXg/939092/1735693882/17003091_2062.ts
#EXTINF:12.008000,
https://80-251-153-103.my-servers.top:5052/live14/0tcVkW3Sa9-9JxeorPloXg/939092/1735693882/17003091_2063.ts
#EXTINF:12.008000,
https://80-251-153-103.my-servers.top:5052/live14/0tcVkW3Sa9-9JxeorPloXg/939092/1735693882/17003091_2064.ts
#EXTINF:12.008000,
https://80-251-153-103.my-servers.top:5052/live14/0tcVkW3Sa9-9JxeorPloXg/939092/1735693882/17003091_2065.ts

[sparkison]

@sonroyaalmerol let me know if there's any other details I can add to help out with this