Recording plays on iOS and on HTTP but not on Emby Roku

[ebr 16169]

14 hours ago, HappyGilmour said:

Logs sent from Emby

Same thing on the app end.  Just getting an invalid stream of some sort.

Player error.  Error Code: -5 Message: malformed data

 

[HappyGilmour 20]

2 hours ago, ebr said:

Same thing on the app end.  Just getting an invalid stream of some sort.

Player error.  Error Code: -5 Message: malformed data

 

Ok. Well Emby recorded the stream. And so you know....I played both the original recording and a converted file (using Emby's conversion tool) of the same event. Is there any way to find out why this is happening? TBH if I can't play Live TV recordings via Emby for Roku it really limits the usefulness for me. Thanks. 

[MBorland 0]

Are these recordings by chance "NextGenTV", ie ATSC 3.0? I believe Roku cannot do the audio on those.

[HappyGilmour 20]

2 hours ago, MBorland said:

Are these recordings by chance "NextGenTV", ie ATSC 3.0? I believe Roku cannot do the audio on those.

No. These are straight Emby recordings from a live tv stream. 

[HappyGilmour 20]

9 hours ago, MBorland said:

Are these recordings by chance "NextGenTV", ie ATSC 3.0? I believe Roku cannot do the audio on those.

I guess I didn’t think through your question. I don’t think that is the case as others who use the same service I do are not having this problem. And the files won’t play video or audio. Thank you for the suggestion. 

[Luke 42077]

Does the converted version play in the Emby Roku app?

[HappyGilmour 20]

On 11/29/2025 at 11:20 PM, Luke said:

Does the converted version play in the Emby Roku app?

No it does not. I tried to play them both as part of the test. The logs should include both versions.

[Luke 42077]

On 12/1/2025 at 9:20 AM, HappyGilmour said:

No it does not. I tried to play them both as part of the test. The logs should include both versions.

Which one is that, and what is the file name of the converted version?

[HappyGilmour 20]

10 hours ago, Luke said:

Which one is that, and what is the file name of the converted version?

The recorded version is .ts and the converted version is .mp4

[HappyGilmour 20]

So I solved this. For others having similar issues playing IPTV recordings on Roku devices (TV and STB’s.)

The incoming stream was recorded at 60 fps. Roku cannot handle this. It won’t play the live IPTV stream either. Even if you convert the recording using Emby’s “conversion” utility and using the Roku compatibility settings….it will not solve this issue. 
 

With a little help from ChatGPT I was able to write a script that checks the file - post recording (using ffprobe) and if it is > 30 fps it will create a new version that is 30 fps AND is Roku compatible (using ffmpeg.) In my case, I was able to utilize my NVIDIA GPU and convert a 4 GB, 4 hour football game recording in 15 minutes. I didn’t include the script because it will be different depending on your hardware. But if you are interested just hit me up and I will send it. Thanks. 

[Luke 42077]

Hi, where did you learn that your device cannot handle 60 fps?

[ebr 16169]

If you turn this option in the app off, do they work?

[HappyGilmour 20]

On 12/26/2025 at 5:35 PM, Luke said:

Hi, where did you learn that your device cannot handle 60 fps?

Hi,

It was actually ChatGPT that guessed it. Then I did testing and that was the common denominator. Do you want the ffmpeg command used to convert to a format that plays properly using the Roku version of Emby?

[Luke 42077]

5 hours ago, ebr said:

If you turn this option in the app off, do they work?

That might help for hevc but he has a lot example on the previous page that is h264.

[Luke 42077]

@speechles?

[speechles 2055]

@LukeThe issue is these are TS files which the Roku cannot natively direct play.

08:54:18.620   Stream #0:0 (h264) -> splitcc:default
08:54:18.620   splitcc -> Stream #0:0 (h264_nvenc)
08:54:18.620   Stream #0:1 -> #0:1 (copy)
08:54:18.620   splitcc -> Stream #1:0 (webvtt)
08:54:18.620   Stream #0:0 -> #1:1 (copy)

If instead these were MKV files they would direct play without issue. That is why the AI (which is incorrect) believes the Roku cannot play this at 60 fps. Because it doesn't understand context of a conversation. It will try to "glean" enough to try to get the "gist" but it just winds up making small mistakes that compound the issue and aren't really solving anything. It is confusing other issues with the fact they cause issues at 60fps with this issue. The AI is merely grasping at straws and shooting fish in the barrel until it has shot the right fish. But what if the right fish isn't in the barrel. Using AI will just waste your time in this case.

The subtitles are embedded into the video stream as EIA-608/708. The h264 stream is being stripped of the subtitles and these are sent sidecar as vtt. I think it is just taking longer than expected and the playback isn't being allowed to start and being exited.

08:54:20.176 elapsed=00:00:01.55 frame= 1275 fps=820 q=19.0 q=-1.0 size=N/A time=00:00:21.25 bitrate=N/A throttle=off speed=13.7x   

Only 21.25 seconds of video was converted in 1.55 seconds of ffmpeg running. It looks like it would've played but they didn't give enough time for that to happen.

@HappyGilmourWas that the only ffmpeg log created during that time? As errors are encounted and playback recovery happens the playback method changes. A change in playback method will create a new ffmpeg log with that new playback method. Does playback ever begin if you just wait longer?

Quote

This isn’t “AI misunderstanding you”—it’s AI overconfidently inferring context it doesn’t actually have.

And yeah… that’s a real problem.

https://chatgpt.com/share/6951e217-3460-800b-8275-ed396caba58c

Edited December 29, 2025 by speechles

[Luke 42077]

Ok but he also had a converted version that failed as well. What about that one?

[speechles 2055]

27 minutes ago, Luke said:

Ok but he also had a converted version that failed as well. What about that one?

That one appears to be MP4. It failed because the Roku rejected it with a direct play error. I cannot tell why in the streams. Everything looks fine. Except this is an MP4. Roku has some problems with MP4 playback that doesn't occur with MKV. It may bail at the fact there are EIA-608 subitles within the MP4 rather than inside a TS. Any reason why Emby doesn't convert into MKV? The MKV container is far more forgiving on the Roku and the MKVToolNix Utility can be used on files to correct them if faults are found.

@HappyGilmourDo you still have that recording in the original TS format? If you drag the original TS file into MKVToolNix GUI and have it remux into an MKV does this play without fault once added to your library? If you drag the MP4 Emby converted into MKVToolNix GUI and remux does the MKV it creates from the MP4 play without issue?

Very curious what the issue is here because by the looks of things the converting might not be making things Roku friendly.

[Luke 42077]

OK yea a converted mkv might be a useful test. Thanks.

[ebr 16169]

11 hours ago, speechles said:

The subtitles are embedded into the video stream as EIA-608/708. The h264 stream is being stripped of the subtitles and these are sent sidecar as vtt. I think it is just taking longer than expected and the playback isn't being allowed to start and being exited.

08:54:20.176 elapsed=00:00:01.55 frame= 1275 fps=820 q=19.0 q=-1.0 size=N/A time=00:00:21.25 bitrate=N/A throttle=off speed=13.7x   

Only 21.25 seconds of video was converted in 1.55 seconds of ffmpeg running. It looks like it would've played but they didn't give enough time for that to happen.

That's not what's happening in the log I saw.  The Roku player is reporting "malformed data".

[ebr 16169]

16 hours ago, Luke said:

That might help for hevc but he has a lot example on the previous page that is h264.

That's worth a test because I'm not sure the labeling on that option is correct at this point...

[HappyGilmour 20]

10 hours ago, speechles said:

That one appears to be MP4. It failed because the Roku rejected it with a direct play error. I cannot tell why in the streams. Everything looks fine. Except this is an MP4. Roku has some problems with MP4 playback that doesn't occur with MKV. It may bail at the fact there are EIA-608 subitles within the MP4 rather than inside a TS. Any reason why Emby doesn't convert into MKV? The MKV container is far more forgiving on the Roku and the MKVToolNix Utility can be used on files to correct them if faults are found.

@HappyGilmourDo you still have that recording in the original TS format? If you drag the original TS file into MKVToolNix GUI and have it remux into an MKV does this play without fault once added to your library? If you drag the MP4 Emby converted into MKVToolNix GUI and remux does the MKV it creates from the MP4 play without issue?

Very curious what the issue is here because by the looks of things the converting might not be making things Roku friendly.

Wow! Thank you guys for all the feedback. Ok so I still have the original .ts and the mp4. Just so you know...I left that .ts sitting for 10 minutes and didn't get it to play. I believe it kicked back an error but....I'm confused now. Here is what I will do:

 

1. I will play the .ts and leave it sit. Let you know what happens.

2. I will try the mkv conversion. But how is that different from using ffmpeg to convert to a .mp4 that does play at 30 fps (even though I know you don't believe that is the issue....but the file does play.)? 

[HappyGilmour 20]

29 minutes ago, ebr said:

That's worth a test because I'm not sure the labeling on that option is correct at this point...

Hi,

 

I set that option on with no effect on playback on Emby Roku. Thank you.

[HappyGilmour 20]

12 hours ago, speechles said:

@LukeThe issue is these are TS files which the Roku cannot natively direct play.

08:54:18.620   Stream #0:0 (h264) -> splitcc:default
08:54:18.620   splitcc -> Stream #0:0 (h264_nvenc)
08:54:18.620   Stream #0:1 -> #0:1 (copy)
08:54:18.620   splitcc -> Stream #1:0 (webvtt)
08:54:18.620   Stream #0:0 -> #1:1 (copy)

If instead these were MKV files they would direct play without issue. That is why the AI (which is incorrect) believes the Roku cannot play this at 60 fps. Because it doesn't understand context of a conversation. It will try to "glean" enough to try to get the "gist" but it just winds up making small mistakes that compound the issue and aren't really solving anything. It is confusing other issues with the fact they cause issues at 60fps with this issue. The AI is merely grasping at straws and shooting fish in the barrel until it has shot the right fish. But what if the right fish isn't in the barrel. Using AI will just waste your time in this case.

The subtitles are embedded into the video stream as EIA-608/708. The h264 stream is being stripped of the subtitles and these are sent sidecar as vtt. I think it is just taking longer than expected and the playback isn't being allowed to start and being exited.

08:54:20.176 elapsed=00:00:01.55 frame= 1275 fps=820 q=19.0 q=-1.0 size=N/A time=00:00:21.25 bitrate=N/A throttle=off speed=13.7x   

Only 21.25 seconds of video was converted in 1.55 seconds of ffmpeg running. It looks like it would've played but they didn't give enough time for that to happen.

@HappyGilmourWas that the only ffmpeg log created during that time? As errors are encounted and playback recovery happens the playback method changes. A change in playback method will create a new ffmpeg log with that new playback method. Does playback ever begin if you just wait longer?

https://chatgpt.com/share/6951e217-3460-800b-8275-ed396caba58c

Hi,

 

So waited 8 minutes and the file did not play. FYI. As to the different ffmpeg logs. I don't know. It was a while ago. 

[HappyGilmour 20]

Ok so here is something that may actually help. I went back through my ChatGPT logs. This command below did NOT work.

ffmpeg -i "inputfile.ts" -c:v libx264 -profile:v main -level 4.0 -r 30 -preset fast -crf 18 -c:a copy "outputfile_30fps.mp4"
 

But this command DID work. (note: Yes we changed to NVIDIA hw encoding but that didn't have anything to do with the results)

ffmpeg -i "inputfile.ts" -c:v h264_nvenc -profile:v main -level:v 4.0 -pix_fmt yuv420p -r 30 -g 60 -bf 2 -preset slow -rc:v vbr_hq -cq:v 19 -c:a aac -b:a 128k "outputfile_30fps_nvenc.mp4"

 

According to ChatGPT: 

Here’s what’s likely happening:

Frame rate isn’t the only issue

You converted to 30 fps, which Roku likes.

But other parameters matter:

Profile/level (main / 4.0)

GOP structure / interlacing

Container / codec flags

Web player vs Roku

Web player is forgiving—it will usually direct-play almost anything.

Roku is picky about H.264 streams: it expects compatible profile/level, keyframe spacing, and AAC audio.

Even if your video is 30 fps, if it’s encoded as High Profile or has unusual settings, Roku may refuse to play it.

Original source quirks

Your IPTV recording may have:

Strange timestamps

Variable frame rate (VFR)

Audio flags that Roku can’t handle

---

Next step:

We need to force Roku-compatible encoding, not just drop the frame rate. That usually means:

 

-c:v libx264 -profile:v main -level 4.0 -pix_fmt yuv420p -x264-params keyint=60:min-keyint=30 -r 30 -c:a aac -b:a 128k

pix_fmt yuv420p → Roku requires this color format

Keyframe interval (keyint) → helps Roku seek and play smoothly

AAC audio at 128 kbps → ensures compatibility

Basically, your first conversion was almost there, but not quite fully Roku-friendly.