Jump to content

Live TV Issues with Roku


EmbyOak
 Share

Recommended Posts

EmbyOak

I set up a new Roku Ultra 4k at a friends place and turned on HGTV for her.  The picture didn't work.  I tried "attempt to fix image" and that still didn't work.  

I tried on my AppleTV HD, worked flawlessly.  I then tried on my AppleTV 4kv2, it worked flawlessly.  

Then I tried on my Roku Premiere+.  It doesn't work either.  Something occurred within the last few updates and now LiveTV seems to not work well on Rooks.

I'm also noticing that all of my AppleTVs work great with LiveTV, but I can't seem to get any LiveTV working on any friends' AppleTVs (since the update) (their accounts do not an Emby subscription).  But LiveTV works in their browsers.  Is this a license issue?

 

 

ffmpeg-directstream-0de2c59f-3162-4a68-83ee-9432204d7ecf_1.txt ffmpeg-transcode-433b3684-b1ef-4b61-a416-44858bec937f_1.txt

Link to comment
Share on other sites

Hi.  The difference is probably that the Roku requires transcoding while the others do not.  The transcode log is full of what looks like source errors:

15:55:47.883 [libx264 @ 0x167c0c0] VBV underflow (frame 1155, -771 bits)
15:55:47.888 [libx264 @ 0x167c0c0] VBV underflow (frame 1156, -771 bits)
15:55:47.889 [libx264 @ 0x167c0c0] VBV underflow (frame 1157, -155 bits)
15:55:47.891 [libx264 @ 0x167c0c0] VBV underflow (frame 1158, -163 bits)
15:55:47.893 [libx264 @ 0x167c0c0] VBV underflow (frame 1159, -771 bits)
15:55:47.903 [libx264 @ 0x167c0c0] VBV underflow (frame 1160, -771 bits)
15:55:47.904 [libx264 @ 0x167c0c0] VBV underflow (frame 1161, -155 bits)
15:55:47.907 [libx264 @ 0x167c0c0] VBV underflow (frame 1162, -163 bits)
15:55:47.908 [libx264 @ 0x167c0c0] VBV underflow (frame 1163, -771 bits)
15:55:47.915 [libx264 @ 0x167c0c0] VBV underflow (frame 1164, -771 bits)
15:55:47.916 [libx264 @ 0x167c0c0] VBV underflow (frame 1165, -155 bits)
15:55:47.918 [libx264 @ 0x167c0c0] VBV underflow (frame 1166, -163 bits)
15:55:47.921 [libx264 @ 0x167c0c0] VBV underflow (frame 1167, -771 bits)

Could also be related to settings if you have customized any of the transcode settings.

Link to comment
Share on other sites

EmbyOak

The funny thing is that it used to work on the older versions of Emby. The rokus are set up at 25mbps to ensure no transcoding (because it isn’t needed). And I know the stream has not changed as it is a commercial feed. 

Link to comment
Share on other sites

3 minutes ago, EmbyOak said:

The rokus are set up at 25mbps to ensure no transcoding (because it isn’t needed)

That won't ensure "no transcoding" as there are situations where it will be needed.  The Roku does not directly support the TS container and that is why it is transcoding in this situation.

Link to comment
Share on other sites

Looking more closely at your log, the source appears to be HLS itself.  Do you have the option of changing that to TS?

Link to comment
Share on other sites

4 minutes ago, EmbyOak said:

I tried that, still doesn't work.  

Can we please look at an example of that?

Thanks.

Link to comment
Share on other sites

That source does not appear to be TS.  It is mpd (DASH).

Link to comment
Share on other sites

Surprising through that ffmpeg can't handle it.

Link to comment
Share on other sites

EmbyOak

@ebrYes, you are correct.  Sorry about that.

@Luke Maybe too much buffering now... :)

I know it used to work which is the weird thing.  I tried connecting my Roku to a friend's Emby server who has access to the same content I have.  Same issue, it will not play.  I thought it was HD content versus SD content, but even that I cannot find a common ground on the channels that do not play on the Roku.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...