Live TV first attempt fails due to wrong user-agent

[thymon]

Hello,

I'm using Jellyfin's Live TV feature with an M3U playlist, which is proxied through a Docker container named aiptv. I've noticed an issue where the first attempt to start a stream always fails, but the second attempt works perfectly.
After checking the logs, I found that on the second attempt, Jellyfin correctly uses this user-agent, and the stream works:

Code:

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

To fix the issue, I manually set this user-agent in the Live TV settings.

However, despite this configuration, Jellyfin still uses :

Code:

Jellyfin-Server/10.10.5

on the first connection, which causes the stream to fail.

Why is Jellyfin not applying the configured user-agent on the first request?


Logs Analysis
On the first attempt, Jellyfin makes a request with the default user-agent (Jellyfin-Server/10.10.5), which leads to a failure:

Code:

[18:29:23] [INF] [108] Jellyfin.LiveTv.LiveTvMediaSourceProvider: Opening channel stream from Emby, external channel Id: m3u_48befa82a0e2e34bd7396e3c0edc788e3022ce538d29744f03b832863039f1d4
[18:31:03] [WRN] [135] Jellyfin.LiveTv.TunerHosts.M3UTunerHost: HEAD request to check MIME type failed, shared stream disabled

However, on the second attempt, Jellyfin now correctly uses the configured user-agent, and the stream starts successfully:

Code:

[18:31:06] [INF] [144] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: Starting /usr/lib/jellyfin-ffmpeg/ffprobe with args -analyzeduration 3000000 -probesize 1G -user_agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"

[theguymadmax]

There will be changes in how Jellyfin scans LiveTV data during the first scan vs. a refresh in the 10.10.6 release. If the issue isn’t resolved in the next bug fix, please open an issue on the Jellyfin GitHub repo.

[thymon]

There will be changes in how Jellyfin scans LiveTV data during the first scan vs. a refresh in the 10.10.6 release. If the issue isn’t resolved in the next bug fix, please open an issue on the Jellyfin GitHub repo.

Great !!
Thx a lot

[thymon]

There will be changes in how Jellyfin scans LiveTV data during the first scan vs. a refresh in the 10.10.6 release. If the issue isn’t resolved in the next bug fix, please open an issue on the Jellyfin GitHub repo.

Nothing in the changelog for 10.10.6 regarding the user-agent used.

My question is: why is the user-agent modification in the LiveTV settings not being applied?

[theguymadmax]

I forgot to reply back to this tread. After posting that last comment, I looked at the PRs and they were related to image and guide data and didn't affect the user-agent. You should go ahead and open an issue on the GitHub repo.

[gnattu]

Well this is because the first one was not actually opening the stream, it is just trying to probe the stream type, and that failure won't affect the playback because that is only used to determine if shared http stream can be used or not.

[thymon]

Well this is because the first one was not actually opening the stream, it is just trying to probe the stream type, and that failure won't affect the playback because that is only used to determine if shared http stream can be used or not.

I understand, but how can I change this behavior?
We have to wait for a while before the stream returns an error and can be restarted again.
And this happens for all channels.
In the WebUI, we get a loading screen followed by a message, but on a FireTV, there's nothing except a black screen, making it unclear what's happening.

[thymon]

I did another test by changing the IPTV proxy. I used XTEVE.
I got the same results. Jellyfin presents itself with the user-agent: Jellyfin-Server/"version".
It takes 1 minute and 30 seconds for the session to fail before restarting the stream and getting the correct user-agent.

Code:

2025/02/18 17:27:43 [xTeVe] Client User-Agent:      Jellyfin-Server/10.10.6
2025/02/18 17:27:43 [xTeVe] Streaming Status:      Playlist: M3U - Tuner: 1 / 1
2025/02/18 17:27:43 [xTeVe] Streaming Type:        [TS]
2025/02/18 17:27:43 [xTeVe] Streaming URL:          http://HIDDEN
2025/02/18 17:27:43 [xTeVe] Streaming Status:      HTTP Response Status [200] OK
2025/02/18 17:27:43 [xTeVe] Content Type:          video/mp2t
2025/02/18 17:29:23 [xTeVe] Streaming Status:      Client has terminated the connection

Code:

2025/02/18 17:29:24 [xTeVe] Streaming Status:      Playlist: M3U - Tuner: 0 / 1
2025/02/18 17:29:26 [xTeVe] Buffer:                true [xteve]
2025/02/18 17:29:26 [xTeVe] Buffer:                true [xteve]
2025/02/18 17:29:26 [xTeVe] Buffer Size:            1024 KB
2025/02/18 17:29:26 [xTeVe] Channel Name:          HIDDEN
2025/02/18 17:29:26 [xTeVe] Client User-Agent:      Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36