Problem with Rokutv and transcoding.

[Agent47 0]

I setup Emby server with TVH to run iptv via m3u and it works almost perfect on my windows pc and Samsung tv but on my Roku tv History channel will infinite load even tho tvh is still watching the stream and then when you go back or even exit out the app then the connection will still be stuck in TVH then I have to kill the connection manually because emby did not tell TVH it exited the stream. Other channels work fine I tried about 30 other channels and they loaded perfect its just History HD. I have tried changing my quality profile in Emby settings on my roku tv from auto to 4k 60mbps and I also tried 1080p FHD 60mbps and it didnt seem to change anything. I also tried limiting framerate to 30 fps in Emby settings on my roku tv, it didnt help. This is not an issue with my iptv provider, I think it has something to do with Embys transcoding. Any ideas would be great.

[Agent47 0]

• Exactly what you were doing and what happened.  I clicked on HistoryHD channel to watch it and then I just got a infinite loading screen and then I sent the log.
• The time you sent the log (in Eastern Time please - UTC -5)  8:24 AM EST Is when I sent the log.
• The name of the Emby user on the local server that was logged in at the time  Username: John

[ebr 16169]

Hi.  Please post the server and ffmpeg log from when the problem occurred.

[mattisam 8]

Hi, I know this person, so I want to chime in with my findings. I have the same tv provider, and also using TV Headend and Emby.

The channel works from tvheadend directly to VLC. It also works in Emby via the Emby Android app and via web browser. As he mentioned, it works on his Samsung TV.

The only place it does not work is Roku Emby app. So that is where the trouble sits. I have looked at the stream info data in VLC to see if this channel is using some strange codec or something else, and it lines up with other channels that work fine on Roku. I cant seem to find anything that makes this channel different.

I am looking at logs now. Agent47 if you can post your logs for ebr  that would be great.

[Agent47 0]

The logs are at different times but I replicated the same thing

Cwi_Q.txt fi083.txt A_Ahp.txt jhCkc.txt xOVxV.txt v25wY.txt

embyserver.txt

Edited July 10, 2025 by Agent47

[speechles 2055]

TranscodeReasons=ContainerBitrateExceedsLimit
TranscodeReasons=ContainerBitrateExceedsLimit,DirectPlayError&allowVideoStreamCopy=false
TranscodeReasons=ContainerBitrateExceedsLimit,DirectPlayError&allowVideoStreamCopy=false
TranscodeReasons=ContainerBitrateExceedsLimit,DirectPlayError
TranscodeReasons=ContainerBitrateExceedsLimit,DirectPlayError&allowVideoStreamCopy=false
TranscodeReasons=ContainerBitrateExceedsLimit,DirectPlayError&allowVideoStreamCopy=false

The allowVideoStreamCopy being added to the end would only happen if there was an actual error or you used Playback Correction. The ffmpeg logs only get created when transcoding happens. Direct play logs aren't created.

 

header("Content-Type: application/vnd.apple.mpegurl");

The Roku doesn't understand the application type. Are these headers you are creating?

header("Content-Type: application/x-mpegURL");

It might work if instead you sent the content type as this.

[mattisam 8]

Not sure at all what you mean speechles. We are not sending headers or doing anything crazy. Just trying to watch a channel on emby that works on every device except for Rokus.

[Luke 42077]

4 minutes ago, speechles said:

The part with "Headers: Content-Type=application/vnd.apple.mpegurl"  at the end there. Roku cannot play this type of content-type. Thats why I was asking how are these headers being generated? Can you correct them?

Where are you seeing that?

[speechles 2055]

27 minutes ago, Luke said:

Where are you seeing that?

Quote

2025-07-10 08:42:12.875 Info DynamicHlsService-0HNDU6BCRQMUO:00000001: http/1.1 Response 200 to ‌‍‍0.0.0.0‌. Time: 2ms. GET ‌/emby/videos/1737367/live.m3u8?DeviceId=9a0a5c1b-60f1-5bda-8ba0-4e130dc3b5ea&MediaSourceId=c510a109b483718d5df50c55b41602ca&PlaySessionId=c20baf9d15c74b6a88fab0e51a75f448&api_key=‌16280f4e38f64e1dbbfa4401820a63cb‌&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_c510a109b483718d5df50c55b41602ca&VideoCodec=h264,hevc,mpeg2video&AudioCodec=ac3,aac,mp2,mp3,eac3,flac,vorbis,lpcm&VideoBitrate=34872074&AudioBitrate=127926&MaxWidth=3840&MaxHeight=2160&AudioStreamIndex=1&TranscodingMaxAudioChannels=8&SegmentContainer=ts&SegmentLength=3&MinSegments=1&AllowInterlacedVideoStreamCopy=True&BreakOnNonKeyFrames=True&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-maxrefframes=16&h264-videobitdepth=8&h264-maxframerate=30&h264-profile=high,main,baseline,constrainedbaseline&h264-deinterlace=true&h264-level=41&h264-videorotation=0&mpeg2video-videorotation=0&mpeg2video-maxframerate=30&mpeg2video-deinterlace=true&hevc-videorotation=0&hevc-maxframerate=30&hevc-codectag=hvc1,hev1,hevc,hdmv,dvh1,dvhe&aac-audiochannels=6&eac3-audiochannels=8&ac3-audiochannels=6&flac-audiochannels=6&lpcm-audiochannels=6&mp3-audiochannels=2&mp2-audiochannels=2&vorbis-audiochannels=6&TranscodeReasons=ContainerNotSupported. Headers: Content-Type=application/vnd.apple.mpegurl, Date=Thu, 10 Jul 2025 12:42:12 GMT, Server=UPnP/1.0 DLNADOC/1.50, Cache-Control=no-cache, no-store, no-transform, must-revalidate, Content-Encoding=br, Expires=-1, Pragma=no-cache, no-store, no-transform, must-revalidate, Vary=Accept-Encoding, Content-Length=259, Cross-Origin-Resource-Policy=cross-origin, Private-Network-Access-Name=JellyMedia Server, Private-Network-Access-Id=f31029750f7d423d9853ffc34d483ba8

In his Emby Server logs.

The Roku supports all these content-type and that is among them. His Roku is saying the container isn't supported when fed the m3u8. Then it starts to roll through playback correction and eventually fails altogether to play at all. It isn't because of the content-type like I thought. It has to do with something else.

Edited July 11, 2025 by speechles

[ebr 16169]

The Roku player is reporting "malformed data" trying to interpret the stream so the headers could very well be the issue.

[Agent47 0]

Hello I'm not sure what you mean by the headers but I managed to replicate the problem with the channel US: MTV HD as well so its not just US: HISTORY HD as I thought before. I do remember watching US: MTV HD yesterday when I first found the problem with the HISTORY HD channel cause I was watching Ridiculousness. Here are the all of the ffmpeg logs that I have after the infinite spinning occurred for MTV HD I let it spin for a good 3 minutes at least, I uploaded them to Bashupload I hope that is ok

https://bashupload.com/AyvhP/drYEJ.txt
https://bashupload.com/M_Wum/1p-eh.txt
https://bashupload.com/e_AvF/CM5FG.txt
https://bashupload.com/Po-2H/f08Q9.txt
https://bashupload.com/UT8St/FO0HF.txt
https://bashupload.com/wFhu_/QV7og.txt
https://bashupload.com/gRF1G/rQf7_.txt
https://bashupload.com/z26IY/8ltzk.txt
https://bashupload.com/uebJd/fVnh6.txt
https://bashupload.com/KUEB1/iPyRh.txt
https://bashupload.com/EAFRi/QiTaK.txt
https://bashupload.com/aIG96/JES3h.txt
https://bashupload.com/ppLq-/Hshhy.txt
https://bashupload.com/6dgv4/9aH6H.txt
https://bashupload.com/teB_r/bhzVX.txt
https://bashupload.com/MJ6Vx/DVId3.txt
https://bashupload.com/mr93k/d1AK3.txt
https://bashupload.com/lhbUc/B3HA2.txt
https://bashupload.com/XLMyF/1cUQ0.txt
https://bashupload.com/RE89N/ARsNU.txt
https://bashupload.com/UW_rv/wJGyn.txt
https://bashupload.com/1ZgAN/rICja.txt
https://bashupload.com/fMAwd/2Awi4.txt
https://bashupload.com/v6mRn/atrfz.txt
https://bashupload.com/p7Evp/0IZmf.txt

[Agent47 0]

I am able to watch US: MTV HD now, I have changed nothing on my end.

[ebr 16169]

22 hours ago, Agent47 said:

I am able to watch US: MTV HD now, I have changed nothing on my end.

Hi.  This would be fairly clear evidence that it is an issue at the source.  Some players are more tolerant of bad inputs.  The Roku player is not tolerant at all.  It expects basically a perfectly formed input.

[mattisam 8]

We can give feed back to the provider, but we are not sure what to tell them. The codecs and all other stuff as far as I can tell are the same on this channel over others, at least looking at VLC. If we knew what was wrong that the Roku hated, that would be helpful.

[Agent47 0]

If it is a problem with Roku then why can Jellyfin stream the same channel from the same M3U?

[speechles 2055]

They are converting to 62 frames per second? Or is that the frames per second the media is? Why is it 62?

My guess is JellyFin isn't checking framerate at all and will throw incompatible media at the player hoping it will play. Even though it is 62 frames per second. The Roku player can and will drop frames every second if this direct plays. While we try to keep within the specifications that Roku has given us and would transcode this to 60 frames per second instead of leaving it at 62 frames per second.

Can you do an apples to apples test and show us the ffmpeg log created when you try that same channel/m3u with Emby as with JellyFin? Seeing the Emby ffmpeg log from that when they can play and we cannot would definitely give us the reason why.

Make sure this setting is set to YES.

Edited July 13, 2025 by speechles

[Agent47 0]

Absolutely, here is the logs.

 

JellyfinServerLog.txt ffmpeg-transcode-2898152a-9368-468a-b278-2660345220dd_1.txt ffmpeg-transcode-ca15a96b-0a82-4d23-a632-56cb5b4abcde_1.txt ffmpeg-transcode-187b2304-c8e9-4a5b-8ed1-1a728289bc21_1.txt ffmpeg-transcode-c4915684-f3ce-4cef-86f3-3d9df3c18b99_1.txt ffmpeg-transcode-b20e7e40-ca64-48ac-94bc-56e9f60b77a3_1.txt ffmpeg-transcode-6dbfc61c-0df5-44d1-bdaa-380580170bd0_1.txt ffmpeg-transcode-a3c903b5-fa3e-496f-a9dd-de9c9e575afe_1.txt ffmpeg-transcode-5b94365c-5000-4c84-837c-a77c6602a50f_1.txt embyserver.txt JellyfinffmpegLog.txt