IPTV Playback Error - Forbidden

[rcutanda 13]

After a forum search, I have not found any topic I thought relevant for my problem, so I decided to create a new one. I apologise if I missed something.

MY SETUP:
Emby Server 4.8.10.0
Ubuntu 24.04.1 LTS
IPTV stream

ERROR:
Playback Error
Forbidden

This error only happens with the IPTV stream. I have another streaming signal from a LinkPi ENC1-V3 device which plays correctly. I get the error both with the full .m3u or with its individual .ts streams.

The IPTV signals have been working fine ever since I am using Emby. But I have recently made some important software and hardware changes in my network and now, for the life of me, I am unable to find out what may be wrong.

1. I have been almost two weeks without internet at home because a serious problem with the cables of my previous ISP provider, so I was forced to move to a new ISP. That means I have now a new internet router.

2. I took advantage of that extended downtime to make some changes: I upgraded my server to Ubuntu 24.04. I DID NOT directly upgrade the previous OS but decided to start from scratch formmating the server, so I recovered Emby from my previous backup.

3. I also upgraded my Ethernet network cables and switch from 1Gigabit to 2.5G.

As you can see, a lot of changes but I would swear the IPTV has been working for some time after the upgrade. However, I admit I am quite confused and maybe the new setup never worked properly after all the changes.

I have attached my server's log, but it is the first time that I do so and I have to admit the logs are quite daunting. There were tons of files and I was not sure what to send, so this is what I have done:

1. Created the backup folder in /var/lib/emby/logs/bk (just in case) and moved there all my logs to make sure I started from scratch and only relevant entries to my error were included.
2. I rotated the logs.
3. Played the IPTV stream.
4. Inmediately dowloaded the only log created (embyserver.txt) with the option "Anonymise log contents" marked.

Hopefully, I did it right.

Thank you,

 

embyserver.txt

Edited January 15, 2025 by rcutanda

[rcutanda 13]

PS: I would like to add that I have made no changes whatsoever to the IPTV stream. It still plays flawless on other devices using VLC and it has always played correcly on Emby since day one. Thanks.
 

[Luke 42077]

Hi, your provider is rejecting the connection. On the m3u setup screen there is configuration for the user-agent and referer http headers. You may need to use those in order to try and disguise emby server as some other software, like Vlc for example, or the Chrome browser.

Of course additionally you could also ask your provider to tell you the exact reason why they are sending back forbidden responses.

Please let us know if this helps. Thanks.

[rcutanda 13]

Hello, Luke:

I trully appreciate your answer. Using your ideas I have been making some extensive testing and I have to admit I am at least as puzzled as I was at the very beginning. So, here I go:

I thought at first that by "provider" you meant my new internet provider. I found it weird because I have no problem whatosever opening with VLC on my PC the very same IPTV stream Emby cannot open.

Just to be sure and rule that out, I opened a Windows Sandbox session on my PC, installed a VPN client, opened a OpenVPN UDP session and then made a fresh Emby install on the Sandbox. Even when using the VPN connection I got the exact same forbidden error. I tried using the VPN client only on the Sandbox and only on the host Windows. The result was always the same: Forbidden.

I re-read your answer and then I realised: maybe you were refering to the IPTV provider, and not my internet provider. So I tried three things:

1. A free IPTV list for Digital Terrestrial Television:

https://github.com/LaQuay/TDTChannels

It worked flawlessly, so I thought that confirmed that my IPTV was blocking Emby for some reason.

2. As suggested, tried a custom user agent. Because VLC has always worked, I used this user agent HTTP header:

VLC/3.0.21
(Source: https://user-agents.net/string/vlc-3-0-21)

I got the same Forbidden error, so I tried another one, but with the same result:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

3. Then I tried Threadfin as a proxy installed on a Raspberry Pi. With that setup, it is my believe that what my IPTV provider sees is NOT Emby directly but Threadfin, which is not even in the same physical device. To my surprise, the result was EXACTLY THE SAME. Even when Threafin redistributes the stream, VLC can play it while Emby cannot.

So, summing-up:

a) I can reproduce the error on two different OS: Ubuntu and a "fresh" Sandbox Windows 11 with a fresh Emby setup. That suggests this should not be a configuration problem on my real Emby setup.

b) I can play the IPTV stream on other players such as VLC and I can reproduce the Forbidden error on Emby even while using a VPN connection. This suggests my ISP is not blocking the connection.

c) I can play other IPTV lists with Emby, so it seems the problem is specific to my IPTV list. However, I do not understand how I can also reproduce the error even while using a Threadfin proxy which, to the best of my knowledge, should hide all real clients from my IPTV provider.

d) Finally, let's not forget that everything was working normally just a couple of weeks ago...

I am so lost and I have spent so much time on this that I have really given up hope. However, and just in case this could be useful for the developers or other users, I just wanted to follow-up and share all my testings.

I attach the new log created in the Windows Sandbox while using the OpenVPN connection in case it may be of help.

Thank you once again for your interest in this matter.

Kind regards,

embyserver.txt

Edited January 16, 2025 by rcutanda

[sa2000 674]

The log shows this failing

2025-01-16 18:23:20.621 Info HttpClient: GET http://host4/x_path6_x/x_path7_x/x_path8_x/x_path9_x
2025-01-16 18:23:20.762 Info HttpClient: Http response 403 from http://host4/x_path6_x/x_path7_x/x_path8_x/x_path9_x after 141ms. Headers Connection=keep-alive, Date=Thu, 16 Jan 2025 17:23:19 GMT, Server=nginx/1.26.1

The raw log file would show you the actual url that this request is for

Log files here 

C:\Users\WDAGUtilityAccount\AppData\Roaming\Emby-Server\programdata\logs

As this is http and not https, you should be able to use wireshark and find exactly what is being sent and what the http headers

You compare this with what gets captured by wireshark when using other application that works ok

 

[rcutanda 13]

Thank you so much four your reply, sa2000.

The real http address is either the one of the IPTV provider or the one by Threadfin. I guess I will need to use Wireshark to know what is going on. The problem is that I have never used that tool, so even if I have a basic idea of what is used for I am sure it will take me a while to figure out, on the one hand, how to use it and, on the other, what to do with the data captured. I am afraid I can no loger spend more time on this issue for the time being, so I will leave my issue (and this thread) on hold. Should I find out any more details I will share them here. As I mentioned before, even if I cannot fix my problem, hopefully, others may learn from my situation.

Regards,

[sa2000 674]

3 hours ago, rcutanda said:

The real http address is either the one of the IPTV provider or the one by Threadfin

I already identified the timestamp for you in the emby server log for the request - so you just need to find the embyserver log file that has that timestamp that I picked out of the santitzed downloaded log

So look in the logs folder "C:\Users\WDAGUtilityAccount\AppData\Roaming\Emby-Server\programdata\logs" for the embyserver-xxxxx.txt log that has the timestamp at 2025-01-16 18:23:20.621 and the following request - you will see the actual http domain that the request is going to instead of the host4 that you see in the downloaded log

"2025-01-16 18:23:20.621 Info HttpClient: GET http://host4/x_path6_x/x_path7_x/x_path8_x/x_path9_x"

And when you know what host4 is - then you can use nslookup in windows command line to find the ip address

Note that log files get purged after 3 days - so that log file will be deleted after the 19th January

3 hours ago, rcutanda said:

The problem is that I have never used that tool, so even if I have a basic idea of what is used for I am sure it will take me a while to figure out, on the one hand, how to use it and, on the other, what to do with the data captured.

Using wireshark is fairly simple. You download it from their web site here and install it. When you launch it, you select the network interface to capture and if you have wifi + wthernet you can multi-select both and then you click on the start caprure icon in top left area 

There is a filter field where you can put in for example -  

http && ip.addr == xx.xx.xx.xx 

and the xx.xx.xx.xx being the ipv4 address of the domain you looked up in nslookup

and you repeat exactly what you did on the 16th Jan at 18:23 and when you get the 403 - you stop the wireshark capture and start looking at the packets. if you have difficulties doing that - you can save the capture in wireshark to the default pcap filetype and zip it and send it to me by Private Message together with the full url you found in the raw embyserver-xxxx.txt file i  mentioned

and if it is working with another application - you could also test that with wireshark running and then save and let me have that pcap and the time of the test

Edited January 17, 2025 by sa2000

[rcutanda 13]

Again, I appreciate your time and patience.

This is what I have found with some guidance from ChatGPT:

1. The direct URL for one of the streams included in the .m3u file has the following format:

http://123456.feed.com/live/user/password/123456.ts

2. Using "curl -I" found this:

HTTP/1.1 301 Moved Permanently
http://123456.newfeed.com/live/user/password/123456.ts

3. Testing the new URL directly in the browser I also get a 403 Forbidden error.

4. I tried to use ffmpeg directly:

ffmpeg -i http://123456.newfeed.com/live/user/password/123456.ts

[http @ xxx] HTTP error 403 Forbidden
[in#0 @ xxx] Error opening input: Server returned 403 Forbidden (access denied)
Error opening input file http://123456.newfeed.com/live/user/password/123456.ts.
Error opening input files: Server returned 403 Forbidden (access denied)

5. So, if that URL always generates a 403 Forbidden error, how VLC can stream it? I used VLC log to see what was going on:

"C:\Program Files\VideoLAN\VLC\vlc.exe" http://123456.newfeed.com/live/user/password/123456.ts --intf dummy --file-logging --logfile=C:\vlc-log.txt --verbose=2

6. I admit that I can hardly read a log so I am not certain of which sections from the log could be useful here in the forum and which would expose personal data, so I will share it privately. Hopefully, it will show some light in this issue.

Thank you once again.

Regards,

[sa2000 674]

53 minutes ago, rcutanda said:

I admit that I can hardly read a log so I am not certain of which sections from the log could be useful here in the forum and which would expose personal data, so I will share it privately. Hopefully, it will show some light in this issue.

I cannot find any mention of 123456.newfeed.com or newfeed in the vlc log you sent me.

Are you able to run wireshark? Selecting your network interfaces to capture and start the capture - then do the Emby Server test and get the 403 error and then do the vlc test for exactly the same channel / video source and stop the wireshark capture, save all as pcap file, zip the pcap file - send it to me privately together with the zip of the raw emby server logs and vlc log

 

[xfitinx 0]

Morning!!, same error that @rcutandafor here!!!

We have the same error until this last sunday.

I tested the same m3u file with VLC, and works perfectly.

I have a emby server 4.8.10.0 version running over docker container.

BR!

 

[sa2000 674]

39 minutes ago, xfitinx said:

Morning!!, same error that @rcutandafor here!!!

I am working with @rcutandato get wireshark capture of the 403 on emby and successful stream with vlc and will liaise with the development team

[sa2000 674]

@xfitinx@rcutanda

M3U TV Tuner 1.0.36 has just been released. If you have got it, please restart the server to pick it up. if not, then restart the server to get it checked for and after it is downloaded as seen in the dashboard, please restart the server againn to complete the installation

Please confirm the outcome after updating to 1.0.36

[rcutanda 13]

No changes: VLC plays the stream, but Emby still returns the "Forbidden" error.

EDIT: For some reason, Emby is not anonymising my log. I will upload it once I solve this.

 

Edited January 18, 2025 by rcutanda

[sa2000 674]

3 minutes ago, rcutanda said:

No changes: VLC plays the stream, but Emby still returns the "Forbidden" error.

That is bad news. Please do the same before - raw log file + wireshark or tcpdump if linux of both emby server and vlc for same stream and send privately

 

[sa2000 674]

I am continuing to work with  @rcutanda to get diagnostics but would love to get from other users to see if there are similarities. Specifically from users for whom Emby was working ok with the m3u tv tuner plugin before 1.0.35.0 and is still not working with 1.0.36.0 after the install and server restart

What I need is wireshark or tcp dump capture of a 403 error plus the raw embyserver log file - sent privately by Private Message in the forum

And if you can also do exactly same stream test with other app where it works eg vlc and again capture the http packets with wireshark or tcpdump and include the zipped pcap file for this as well

Which of you has the problem now in 1.0.36.0 after server restart but did not have it before version 1.0.35.0 of the plugin?

[sa2000 674]

@xfitinxAre you using default User Agent and Referer in the M3U Setup page ?

[rcutanda 13]

M3UTuner 1.0.38 works for me!

I have tried it both in my real Ubuntu server and in a Windows Sandbox testing environment. Both works.

Great Job, Emby team!

[dius 4]

testing

Edited January 19, 2025 by dius
testing

[xfitinx 0]

Morning!!!,

Good news!!, with the m3u tunner 1.0.38 version, looks like works fine!!....

i`ll test during today....

BR!