christopher102994 3 Posted January 13, 2022 Share Posted January 13, 2022 Hello, My live TV stopped working a few months ago and I'm just now getting around to debugging it. The m3u is generated by a project I started: docker-toonamiaftermath that scrapes the associated website and builds a m3u playlist and XMLTV file. The m3u playlist works perfectly fine in VLC and had been working fine in Emby until a few months ago. OS: UNRAID Runtime: Docker Container: linuxserver/emby:beta GPUs: 2x NVidia 1060 6gb (no other applications utilize these) Version When Logs captured: 4.7.0.20 Note: I have tried switching to the stable branch and continue to get the same errors. The container is VPNd through another container for traffic ( --net=container:<vpn container> ), and has a reverse proxy configured using nginx and certificates provided by letsencrypt + duckdns. Additional info regarding the docker configuration and flags: --runtime=nvidia --device=/dev/dri:/dev/dri -e NVIDIA_VISIBLE_DEVICES=all Behavior: Essentially when trying to play on any of my devices I get a similar error. (PC (Web), NVidia Shield TV Pro, Chromecast (Emby App)) Any help/tips/advice to get this working again would be greatly appreciated! Please let me know if there is more information needed. ffmpeg-transcode-5908240b-301b-4dee-92fe-c4c42f6beb07_1.txt ToonamiAftermath.m3u embyserver.txt 1 Link to comment Share on other sites More sharing options...
Luke 37063 Posted January 14, 2022 Share Posted January 14, 2022 Hi, is this m3u url something we can test ourselves, or is it only accessible to you? Link to comment Share on other sites More sharing options...
christopher102994 3 Posted January 14, 2022 Author Share Posted January 14, 2022 @Luke the URL is only something I have access to. It's essentially nginx serving up the attached m3u and the XML file much like xTeVe does. Emby doesn't seem to have an issue (from my perspective) getting the data - the EPG displays perfectly fine in correlation to the channels. Link to comment Share on other sites More sharing options...
Luke 37063 Posted January 14, 2022 Share Posted January 14, 2022 Is there a way to make it accessible so that we can try it? Link to comment Share on other sites More sharing options...
christopher102994 3 Posted January 14, 2022 Author Share Posted January 14, 2022 (edited) Sure. I will PM you the info. @Luke Edited January 14, 2022 by christopher102994 Link to comment Share on other sites More sharing options...
christopher102994 3 Posted January 21, 2022 Author Share Posted January 21, 2022 @Luke any thoughts? 1 Link to comment Share on other sites More sharing options...
christopher102994 3 Posted January 26, 2022 Author Share Posted January 26, 2022 @Luke I just updated to 4.7.0.21-beta and I'm seeing the same issue. 1 Link to comment Share on other sites More sharing options...
christopher102994 3 Posted January 28, 2022 Author Share Posted January 28, 2022 @Luke I just updated to 4.7.0.22-beta and I'm still seeing the same issue. Link to comment Share on other sites More sharing options...
Luke 37063 Posted February 4, 2022 Share Posted February 4, 2022 OK I've just finally tested the source that you sent me, and the problem is in the source m3u. Many of the urls are coming back 404 not found. I can see this in a browser without even using Emby Server. The first channel I tried to play in Emby Server actually was successful, then i stopped and tried to play another channel. At that point I saw the behavior you described, looked in the server log and saw lots of 404 responses from the video urls. So then I opened up the m3u in a text editor and followed the links manually in the browser and saw the same thing. Link to comment Share on other sites More sharing options...
christopher102994 3 Posted February 4, 2022 Author Share Posted February 4, 2022 @Luke that's strange. I don't see any 404s in those logs. I also don't see any 404's in a log if I try right now. The channel simply doesn't play anymore. Is the 404 error obfuscated as some other message? Note: Channel 7 is an error-prone channel that will likely give you a 404 I need to remove: https://github.com/chris102994/docker-toonamiaftermath/issues/4 When I open the m3u file and open the m3u8 links it downloads a playlist that opens perfectly fine in VLC. Link to comment Share on other sites More sharing options...
christopher102994 3 Posted February 4, 2022 Author Share Posted February 4, 2022 So @Luke - I saw a different form post a while back that looked to be a similar issue (I can't find it now) -- and the cause was the VPN. Just for the heck of it I removed this container from my VPN container and now it works perfectly fine... Not exactly sure why this is the case though since I've had it routed through my VPN since I set it up (A few years ago at this point)... It would be nice to anonymize any external streaming.. I guess I'll have to use an M3U proxy if I wish to any longer.... Anyways thanks for your troubleshooting. Link to comment Share on other sites More sharing options...
christopher102994 3 Posted February 4, 2022 Author Share Posted February 4, 2022 Additional note: I can access the media just fine while the VPN is active via VLC on my local PC. Link to comment Share on other sites More sharing options...
Carlo 4330 Posted February 9, 2022 Share Posted February 9, 2022 Hi, if it works in VLC through the VPN it likely will in Emby as well. However it's not as simple. Emby determines your IP address and URL at startup based on WAN IP and network config settings. If you now start a VPN or some other such event that "pulls the rug" out so to speak on Emby Server then things aren't going to work correctly until Emby adjusts. So you can't usually have Emby running, start up a VPN, do something in Emby that requires it to fetch info from the Internet (such as m3u streams) and expect it to work. Emby will be marking packets based on what the network should look like but now doesn't. So the request will go through to the other party but nothing will be returned since it's using a mismatched set of IPs. So you need to be careful in testing with a VPN to make sure you start it first and have Emby properly setup to use the VPN. Worth mentioning as well. If you are setup to allow remote access to your server those people will be cut off with the VPN running unless you have port forwarding setup on the VPN server. Link to comment Share on other sites More sharing options...
Luke 37063 Posted February 10, 2022 Share Posted February 10, 2022 2 hours ago, cayars said: Hi, if it works in VLC through the VPN it likely will in Emby as well. However it's not as simple. Emby determines your IP address and URL at startup based on WAN IP and network config settings. If you now start a VPN or some other such event that "pulls the rug" out so to speak on Emby Server then things aren't going to work correctly until Emby adjusts. So you can't usually have Emby running, start up a VPN, do something in Emby that requires it to fetch info from the Internet (such as m3u streams) and expect it to work. Emby will be marking packets based on what the network should look like but now doesn't. So the request will go through to the other party but nothing will be returned since it's using a mismatched set of IPs. So you need to be careful in testing with a VPN to make sure you start it first and have Emby properly setup to use the VPN. Worth mentioning as well. If you are setup to allow remote access to your server those people will be cut off with the VPN running unless you have port forwarding setup on the VPN server. Actually no, the detected remote address does not affect outgoing http requests to his m3u tuner source. It will only impact the interaction between server and clients. So there must be some other reason for the problem with the vpn enabled. Link to comment Share on other sites More sharing options...
Carlo 4330 Posted February 12, 2022 Share Posted February 12, 2022 Tested the above and the packets are definitely mismatched Luke until the server is aware the remote address has changed and marks the packets with the correct return address. VPNs these days are full is issues in general for running a Server behind them since you won't be able to route unsolicited incoming packets without a VPN forwarding service to many providers banning VPN IP address spaces (due to abuse from those IPs). So in general a VPN started in this manner without being properly setup for this environment (server of some kind running behind it) is full of potential problems. Link to comment Share on other sites More sharing options...
christopher102994 3 Posted February 12, 2022 Author Share Posted February 12, 2022 @cayars so the way docker works - is that 100% of my traffic is forwarded through the VPN container (this is the VPN container for reference). The way this container works is that it won't even start if the VPN isn't connected - and if it disconnects for any reason the container is brought down - thus closing all other containers using it's network. The only connection traffic for this is routed through nginx to my local network on ONLY the specified Emby port(s). TLDR; emby itself only ever knows the VPN network. This also isn't a traditional "provider" it's a self-hosted web-scraped guide and channel listing for https://www.toonamiaftermath.com/ (when the website is up). Link to comment Share on other sites More sharing options...
Carlo 4330 Posted February 13, 2022 Share Posted February 13, 2022 Sounds like a lot of moving parts and network layers involved which can make diagnostics a wee bit harder. You mention in post one running Emby Server via Docker on Unraid. Is this the same container you mention above with the VPN? What I'm trying to understand is where the VPN itself runs. Is the VPN running on the host, in the same container as Emby Server or it's own container just for VPN? What does the network binding look like for each container involved? If you like, send me a private message (hover over by avatar and choose the message link) and we can try a remote session where it might be easier to show me the setup. Link to comment Share on other sites More sharing options...
Luke 37063 Posted February 15, 2022 Share Posted February 15, 2022 Were you able to find the answer? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now