Roku not playing Live TV or shows in progress with Proxy in place.

[ab123ga 21]

I've moved to the use of a proxy (dispatcharr) to manage my streaming links etc. This way I can have failover with the use of 1 channel versus multiple in emby. Prior to this everything worked fine on roku. Now that I use a proxy,  I did not realize until one of my brothers who has Roku that its not working on that system since all but 1 of my tvs at my house is firetv. I have no issues /w FireTV and IOS but on Roku when you hit play it just spins and shows 26% then spins then spins. I have the video of that if needed. But attached are the logs. Example around 12:59PM ET I played American Hero Channel. It worked fine on Firestick. Around 1:03PM in Roku it generated many transcode files but fails every time. It seems like it does not like something about the proxy. I say that because I have 1 channel (buzzr)  in my proxy tool that I tell it to redirect; meaning send the m3u as-is and that is the one channel roku can play with no issue. I do not want to go away from what I built b/c 1) i spent too much time building it and it allows me better control than managing the streams in emby.  I upgraded this morning to 4.1.63 since looking at the log files showed an earlier version. No change. Also I can turn off option to play live direct same thing.

Note there's no issue playing recordings that are completed  or movies.

ffmpeg-directstream-eff2aa2d-1134-4817-956b-fe0debe3d89d_1.txt ffmpeg-transcode-842c0a7d-5d21-4695-aa7d-a0309edb03dd_1.txt ffmpeg-transcode-1a7f6f7f-bfd6-471c-9d97-4010c70b1a7a_1.txt ffmpeg-transcode-d44e1d4b-5053-4200-b285-796bc0e67537_1.txt ffmpeg-transcode-5aef2884-f10b-4572-9617-f3c92f0b6422_1.txt ffmpeg-transcode-7fad32b8-be87-4503-95dc-a8f67218d1ec_1.txt embyserver (4).txt

Edited May 8 by ab123ga

[speechles 2083]

Quote

13:03:40.205 [tcp @ 000001a5564b9bc0] Connection to tcp://127.0.0.1:8096 failed: Error number -138 occurred
13:03:40.205 http://127.0.0.1:8096/LiveTv/LiveStreamFiles/475542aa57004a8da63792107b36176a/stream.ts: Unknown error
13:03:40.207 EXIT

The Roku won't be able to resolve the 127.0.0.1 back to the server. That type of link will only work on that local machine. Other machines will not be able to process that link.

[ebr 16429]

20 minutes ago, speechles said:

The Roku won't be able to resolve the 127.0.0.1 back to the server. That type of link will only work on that local machine. Other machines will not be able to process that link.

That address is being accessed by ffmpeg on the server, not the Roku so that isn't specifically the issue.

However, it appears your server/ffmpeg cannot access that URI in this manner:

Connection to tcp://127.0.0.1:8096 failed

Is your proxy mapping incorrectly?  Should that be http://?

[ab123ga 21]

It must be because as noted it works fine for ios, firestick etc. Roku is the only app that cannot support the proxy structure. The general log has where I played this same channel on firetv. I don't know if i'm displaying everything needed but this shows when I tested the same channel 

 

2026-05-07 13:00:13.050 Info SessionManager: Playback start reported by app Emby for Android 3.5.34 on Cart Firetv playing American Heroes Channel. Position: 0 ms. PlaySessionId: 3ec6d9243e204257848560ad3402b08f. IsPaused: False
2026-05-07 13:00:13.051 Info PlaystateService-0HNL9A0CUHT11:00000001: http/1.1 Response 204 to host11. Time: 3ms. POST http://192.168.10.114:8096/emby/Sessions/Playing?X-Emby-Client=Emby for Android&X-Emby-Device-Name=Cart Firetv&X-Emby-Device-Id=afee2da186c8cf2e&X-Emby-Client-Version=3.5.34&X-Emby-Token=x_secret9_x&X-Emby-Language=en-us&reqformat=json. 
2026-05-07 13:00:13.051 Info Trakt: Playback Started
 

[ebr 16429]

5 hours ago, ab123ga said:

it works fine for ios, firestick etc

Are they also remuxing?  Are ffmpeg logs generated for any of those playbacks?

[ab123ga 21]

I just played the same channel again on my firestick and no it is not generating a log.  From the latest emby log 2026-05-08 18:17:12.179  time shows when this played the same channel again. 

 

 

 

embyserver (6).txt

Edited May 8 by ab123ga

[ab123ga 21]

Just to add a bit more. Playing the same channel from my laptop I get logs and the screen shows there's no available streams. However my brother's computer of the same channel played fine. Note that I have the roku and others set to auto on bit rate so that's not forcing transcoding. 

[ebr 16429]

15 hours ago, ab123ga said:

I just played the same channel again on my firestick and no it is not generating a log

Okay, so that's the difference and points to the problem area.

The issue is that your server machine cannot access the streams.  Again, I question whatever is mapping to tcp://...

[ab123ga 21]

Help me understand why you say that. The emby server and the proxy are on the same physical computer. And that proxy server should access the same set of streams since it all goes through emby then the proxy.  If I'm on Firestick the same emby server has access to the same proxy then the same streams and it works. However when I access from Roku, that same emby server which should be talking to the same proxy server cannot play the same set of streams. I don't get that sequence of steps since both Roku and Firestick are running their respective Emby apps connected to the same emby server.  Using what you said, it would be assumed that the proxy streams for channel "x" are different for Firestick vs Roku.

And I will remind you that I noted a specific stream on my proxy is set to redirect where the direct provider url comes to emby. In that scenario the emby server plays that ok on Roku. 

And to answer the other question: I have dropped all the other tuners in emby I had since it is managed via dispatcharr. The URL for that dispatcharr system is http://mydomain:9191/output/m3u.  This URL is fed into emby like any other tuner and it obtains the channels. I don't know any more about how dispatcharr works to answer any more than that. 

 

Edited May 9 by ab123ga

[ebr 16429]

8 minutes ago, ab123ga said:

Help me understand why you say that.

Because of this:

Connection to tcp://127.0.0.1:8096 failed

Again I ask, is that mapping correct?  Should it not be http://127...?

The port also looks questionable.  Why is ffmpeg trying to connect back to the Emby server port?  Shouldn't it be directed to the actual source, or the proxy port?

[ab123ga 21]

Unless there is a specific setting within Emby that I could have set, I don't know how or where to look to answer that question. I just played the same channel again on a firestick but set resolution to 480p to force  transcode. Log attached.  Based upon the log below again of the same channel it seems to not have an issue with http://127.0.0.1...

So unless there is something I have or can set to why Roku has an issue with this but Firestick does not, again, I can't answer that question.

 

ffmpeg-transcode-4c190f99-9661-40b0-bcd8-d05f37e95979_1.txt

[ebr 16429]

The Roku may be a red herring.  The real difference here may be coming from a remote connection vs a local one...

[Luke 42498]

Do other channels play?

[ab123ga 21]

The only channel that played is one in which I do not proxy and send directly. All other channels fail. I did however check the remote vs the local statement and realized my roku system was outside of the local network where the server is. It was on my ATT router which is outside. I moved it onto a local wifi and I tested the same stream plus another and it played. File attached. As an additional test, I validated that one of my firesticks was on the ATT network versus local to the server and it played ok. The firestick on the remote network did not generate any logs; ffmpeg-directstream nor transcode.

So from this test there's still appears to be a difference in how roku vs firestick reacts with the proxy but at least when roku is internal it streams against the proxy now.  However that still leaves me with the problem of my family who are all remote and are roku fans still have an issue. 

ffmpeg-directstream-c6f193eb-286f-48bc-89f8-1191550f99cd_1.txt

Edited May 9 by ab123ga

[ebr 16429]

15 hours ago, ab123ga said:

appears to be a difference in how roku vs firestick reacts with the proxy

The difference is not Roku vs Fire.  It is needing to remux/transcode vs. not.

The problem is somewhere in your proxy configuration when the request is coming from outside your network.

[ab123ga 21]

Going with the difference is not roku vs fire as you noted,  this does not explain why when my firestick is outside the network it does not require a remux/transcode where roku does. I will try different proxy options to see if that changes anything but there is nothing within the proxy that determines settings or configuration for one UI vs another nor are there options related to inside the network vs out. Emby is the sole app calling the proxy.

But as noted, I will try different proxy settings to see. I will also try a separate IPTV app to see if there's failure or success there. 

[ebr 16429]

3 hours ago, ab123ga said:

this does not explain why when my firestick is outside the network it does not require a remux/transcode where roku does

Because the need to remux/transcode in this instance has nothing to do with remote/local.  It has to do with the capabilities of each device.

[ab123ga 21]

After spending quite a bit of time testing settings, this is view of what's happening. Because I use a proxy it can work through multiple versions of a channel before it locks into one that works. Plus there is a channel initiation grace period that is also factored.  Roku remotely seems to be sensitive to the time delay. Why at this point I don't know nor care but what I did was: 

1) Tell the proxy to spend less time trying each stream before moving to the next. The default is 15 seconds however I had it at 10. I kept lowering the value to the point that Roku did not transcode. That was 6 seconds. 

2) Channel initialization default is 5 seconds, same as above, I dropped this value to 3 seconds. 

So with the 2 combined it could take way over 20 seconds before a working stream arrived and that seemed (to me) that this caused transcoding to just keep spinning up. I initially wanted longer periods to try the best streams first for me at home but that seems to come at a cost. Note that these values apply across the board. Regardless of app or in or off network. 

My brother tested his channels as well and they all spun up perfectly.

Issue closed

Edited May 11 by ab123ga

[ebr 16429]

Excellent.  Glad you found a solution.