Roku unable to Direct Play Interlaced 1080i Channels (HDHomerun)

[dialdown 3]

Is there any chance that has ever been done as in July of 2025 1080i still transcodes. If so how can I set it to force direct play, since all my devices can?

ffmpeg-transcode-6b0b8de6-4eed-4ad1-99d4-68e3a94412c8_1.txt

[troyhough 61]

2 minutes ago, dialdown said:

Is there any chance that has ever been done as in July of 2025 1080i still transcodes. If so how can I set it to force direct play, since all my devices can?

ffmpeg-transcode-6b0b8de6-4eed-4ad1-99d4-68e3a94412c8_1.txt 459.97 kB · 0 downloads

Buy a $20 or $30 onn 4K Plus box and replace them is my suggestion...

[Luke 42077]

19 minutes ago, dialdown said:

Is there any chance that has ever been done as in July of 2025 1080i still transcodes. If so how can I set it to force direct play, since all my devices can?

ffmpeg-transcode-6b0b8de6-4eed-4ad1-99d4-68e3a94412c8_1.txt 459.97 kB · 0 downloads

I believe there is an option in the app to try and direct stream live tv.

[dialdown 3]

7 minutes ago, Luke said:

I believe there is an option in the app to try and direct stream live tv.

The only option I see is Allow direct streaming of live streams.  I have tried it both ways, it still transcodes the video to deinterlace 1080i.  The HDHomerun roku app can play all channels fine.

[dialdown 3]

Here are the resulting ffmpeg logs.  First one is with allow direct streaming of live streams set to yes 5a6_1.txt and the second 1dc_1.txt to no

ffmpeg-transcode-d5abf75a-c751-4d19-8bf5-2638e6c585a6_1.txtffmpeg-transcode-5bc3002b-2728-4c72-89d3-8c882d2621dc_1.txt

[Luke 42077]

OK @speechleswill probably know what's going on. Thanks.

[ebr 16169]

Hi.  I believe the next release of the app may solve your issue.  It shouldn't be too long before it is out for you to try.

Thanks.

[dialdown 3]

On 7/9/2025 at 9:46 AM, ebr said:

Hi.  I believe the next release of the app may solve your issue.  It shouldn't be too long before it is out for you to try.

Thanks.

Thanks.  I can see that's it's direct streaming the video for 1080i now to my rokus, but now I see that the CPU utilization for the EmbyServer is running about 50%. When playing other media EmbyServer utilization ranges between <1% and 2%, utilization is for one core.  Fedora 42.

embyserver (1).txt

[Luke 42077]

On 7/30/2025 at 4:41 PM, dialdown said:

Thanks.  I can see that's it's direct streaming the video for 1080i now to my rokus, but now I see that the CPU utilization for the EmbyServer is running about 50%. When playing other media EmbyServer utilization ranges between <1% and 2%, utilization is for one core.  Fedora 42.

embyserver (1).txt 549.2 kB · 1 download

There is still going to be some cpu usage as the server has to repackage the stream into the container format needed by the Roku. It is not the same as playing a regular video.

[speechles 2055]

On 7/30/2025 at 1:41 PM, dialdown said:

Thanks.  I can see that's it's direct streaming the video for 1080i now to my rokus, but now I see that the CPU utilization for the EmbyServer is running about 50%. When playing other media EmbyServer utilization ranges between <1% and 2%, utilization is for one core.

TranscodeReasons=ContainerNotSupported

TranscodeReasons=ContainerNotSupported,DirectPlayError&allowVideoStreamCopy=false

It looks like the server attempts to send it to the Roku with just the container change shown first. This would be your 1-2% usage. But appears there is an error in attempting to play the video stream back directly on that particular Roku for whatever reason and the second reason is given. The video stream _is_ being transcoded. You can tell this is happening by the &allowVideoStreamCopy=false and the DirectPlayError listed on the transcode reason. The Roku is falling back to other forms of playback in order to get the item playable since the error can be recovered from. The Roku is very finnicky about signal strength. It takes a few seconds to build the buffer required to start playback and to keep playback going. If this takes longer than expected the Roku will cause an error which will stop playback. The Roku app will immediately restart playback using a different playback method to get the item to play through the error. You may not even notice this is happening. It is supposed to do this to make it seamless playback for the end user.

Edited August 1, 2025 by speechles

[dialdown 3]

On 8/1/2025 at 3:02 PM, speechles said:

TranscodeReasons=ContainerNotSupported

TranscodeReasons=ContainerNotSupported,DirectPlayError&allowVideoStreamCopy=false

It looks like the server attempts to send it to the Roku with just the container change shown first. This would be your 1-2% usage. But appears there is an error in attempting to play the video stream back directly on that particular Roku for whatever reason and the second reason is given. The video stream _is_ being transcoded. You can tell this is happening by the &allowVideoStreamCopy=false and the DirectPlayError listed on the transcode reason. The Roku is falling back to other forms of playback in order to get the item playable since the error can be recovered from. The Roku is very finnicky about signal strength. It takes a few seconds to build the buffer required to start playback and to keep playback going. If this takes longer than expected the Roku will cause an error which will stop playback. The Roku app will immediately restart playback using a different playback method to get the item to play through the error. You may not even notice this is happening. It is supposed to do this to make it seamless playback for the end user.

If that's the case why does the dash and stats for nerds overlay claim the only transcode is the container but the Video and Audio both say Direct Play.    The container transcode never took that kind of CPU utilization before.  Even if it were doing a non-GPU accelerated transcode wouldn't the CPU utilization happen under the ffmpeg process and not the EmbyServer process?

 

[speechles 2055]

19 hours ago, dialdown said:

If that's the case why does the dash and stats for nerds overlay claim the only transcode is the container but the Video and Audio both say Direct Play.    The container transcode never took that kind of CPU utilization before.  Even if it were doing a non-GPU accelerated transcode wouldn't the CPU utilization happen under the ffmpeg process and not the EmbyServer process?

 

Do you have transcode throttling enabled? Without it enabled the entire transcode session would occur at once and will transcode the entire file to the end as quickly as possible without caring if the end user watching is going to watch the entire thing or not. With throttling enabled this will pause transcoding until playback is very close to that point  then resume it and keep doing these pause/resume as the client requests more data.

Edited August 5, 2025 by speechles

[dialdown 3]

On 8/5/2025 at 12:37 PM, speechles said:

Do you have transcode throttling enabled? Without it enabled the entire transcode session would occur at once and will transcode the entire file to the end as quickly as possible without caring if the end user watching is going to watch the entire thing or not. With throttling enabled this will pause transcoding until playback is very close to that point  then resume it and keep doing these pause/resume as the client requests more data.

I don't understand how that would impact Live TV which is not something that can be transcoded all at once, it has to do it as it goes, right? But throttling is disabled. I just set it to enabled, and am running live TV right now.  It says it's direct playing the video of that same 1080i  channel, and here's the current CPU utilization.

I don't have any media that needs transcoding, but previously when it was transcoding the live TV video for de-interlacing, all CPU utilization was in ffmpeg and the EmbyServer was running about 2% to 5%.  So something is not right.

[Luke 42077]

On 8/8/2025 at 2:58 PM, dialdown said:

I don't understand how that would impact Live TV which is not something that can be transcoded all at once, it has to do it as it goes, right? But throttling is disabled. I just set it to enabled, and am running live TV right now.  It says it's direct playing the video of that same 1080i  channel, and here's the current CPU utilization.

I don't have any media that needs transcoding, but previously when it was transcoding the live TV video for de-interlacing, all CPU utilization was in ffmpeg and the EmbyServer was running about 2% to 5%.  So something is not right.

You're right. So I'm assuming that didn't change anything?

[dialdown 3]

On 8/12/2025 at 5:02 PM, Luke said:

You're right. So I'm assuming that didn't change anything?

Regardless of the throttling setting it was unchanged.  But After the latest Fedora updates, the past two days, it's been OK with the EmbyServer processing running between 4%-8%, which fine.  Thanks.