Jump to content

Constant buffering on Roku TV after 4.7 upgrades


jliebau

Recommended Posts

jliebau

Since the server was upgraded to 4.7 I am experiencing constant buffering while trying to watch either recorded (or in process of recording) TV stream. No problems watching on server (Windows 10) or on another device (iPad, Kindle Fire). Also no problems when watching shows recorded in MP4 format. System seems to really dislike playing TS files now. Ideas? Suggestions?

Thanks,

James

TCL TV model 55R635

Roku TV (A113X) Software Version 11.0.0 Build 419388

 

Link to comment
Share on other sites

image.png.41a75929497d55f7eaaadf787f961a0a.png

Hi. Do you have this setting enabled with a YES? Because live streams are normally composed of MPEG2 within TS we err on the side of caution and fully transcode. You can change this to YES and see if your Roku can tolerate the signal from your tuner directly. Any hiccups/errors in the stream may hang/stall the Roku video player when direct streaming. If it does you can use the cog/gear during playback and choose "attempt playback correction" which will fully transcode the video stream and work through errors which hang the player.

If this is set to YES and you still experience extreme buffering can you share any ffmpeg logs created? Those will give us a clue where the problem is happening. Thanks.

You can also enable the "stats for nerds" with the same cog/gear during video playback. This will include a "Transcode Reason" if the item is transcoding. That reason will explain why it has chosen to transcode.

Edited by speechles
Link to comment
Share on other sites

jliebau

Thank you for your suggestions. I checked "Allow direct streaming of live streams" and it was set to "NO". I recorded two show this evening, back to back. I watched the first show while it was being recorded and "stats for nerds" reported that it WAS being transcoded b/c "container not supported". There was no buffering and video played well. I then went to watch the second show (which had been fulled recorded at that point), and immediately saw the repeated buffering (above). I checked "stats for nerds" and it reported that the video WAS NOT being transcoded! They were exactly the same format files, so I again checked "allow direct streaming" and it was still NO. So I went back to the video, and, lo and behold, it was now being transcoded b/c "container not supported" (despite the fact that it was the same d*** container file). It was this inconsistent behavior that has been driving me crazy. Sometimes it worked, sometimes it didn't, with no clue why. Attached log files that cover tonight's encounter with buffering. Thanks for your help.

embyserver.txt ffmpeg-directstream-eb711a4d-1b0d-4d14-a03e-6d9574be6c9f_1.txt ffmpeg-directstream-148b4943-a0f1-4b14-bf74-da11859769f8_1.txt ffmpeg-directstream-09357434-6f1e-4bc7-94d9-86180e65e4d7_1.txt ffmpeg-transcode-180ff42b-4cae-4244-8a35-e14e2ecec3d3_1.txt ffmpeg-transcode-861c030c-e2a1-47a5-b3c2-163145110cfa_1.txt ffmpeg-transcode-375e223e-0811-46c7-90ed-face27e21f7b_1.txt

Link to comment
Share on other sites

  • 2 weeks later...

I am experiencing this issue as well, and it started with the initial 4.7 release and continues with all point releases after that. Playback was rock solid before that and it never buffered at all.  (Buffering may be technically incorrect, but the symptom is the spinner with a percent loading, and slowly at that.)

I did originally think that it was a transcoding issue causing a delay, but I have since ruled that out bcause when I turn on "stats for nerds", transcoding is 100% complete and the buffering still happens. I turned on advanced logging, but there are no errors in the embyserver.txt file that I could see.  I have included the embyserver.txt file that encompassed the time when the error happened as well as the transcoding file of the program I was watching when it last happened.  Playback began at the timestamp in the log 2022-06-21 13:45:35.977, though the buffering didn't start happening until about a half hour in or so (sorry, I didn't note the time).

ffmpeg-directstream-5e252948-45b9-4709-9f4f-0038aa46a9b2_1.txt
embyserver.txt

Link to comment
Share on other sites

The downloads page only has 4.7.4.  I searched for Beta releases, and found this page:  

 

But I only see Windows server downloads and I run Linux. Is there another location? 

 

Link to comment
Share on other sites

Happy2Play
46 minutes ago, ChipL said:

The downloads page only has 4.7.4.  I searched for Beta releases, and found this page:  

 

But I only see Windows server downloads and I run Linux. Is there another location? 

 

Sorry no the additional platform builds don't appear to be available yet, so am guess the build server may have issues again.

  • Thanks 1
Link to comment
Share on other sites

I was able to nab the 4.7.5 Linux version and installed it. Will watch a few programs this evening and report back.

  • Thanks 1
Link to comment
Share on other sites

I ended up letting a program run, and unfortunately the problem happened a lot during the playback while on 4.7.5.

Attached is the embyserver.txt file (it happened about 5 times in the last five minutes of the file).  I've also attached the transcode log for the program I watched.

In the log I noticed that there are a lot of "waiting 3000ms for subitle segment" messages -- could that be the issue, or is that just an FYI?

 

 

ffmpeg-directstream-2dc78f90-eccb-41c9-93ac-02bd1a59a944_1.txt embyserver (1).txt

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
ChipL

Is there more debugging I can do or more log files I can produce to help with this issue? It has gotten so bad that it's borderline unusable. My only use case for Emby is as an over-the-air DVR. Until the 4.7 release, it was superior to Plex and I was happy. Now I'm at the decision point of going back to 4.6 or Plex.  Both options pain me. I'm happy to do more debugging to help solve the issue, and can provide video files, etc. as needed.

Link to comment
Share on other sites

6 minutes ago, ChipL said:

Is there more debugging I can do or more log files I can produce to help with this issue? It has gotten so bad that it's borderline unusable. My only use case for Emby is as an over-the-air DVR. Until the 4.7 release, it was superior to Plex and I was happy. Now I'm at the decision point of going back to 4.6 or Plex.  Both options pain me. I'm happy to do more debugging to help solve the issue, and can provide video files, etc. as needed.

Hi, can you try setting the server transcoding temp folder back to default and see how that compares? Thanks.

Link to comment
Share on other sites

ChipL

You mean blank the field out in the screenshot?  I can do that, but I'll have to reconfigure the machine because the volume where emby lives doesn't have sufficient disk space for video files or transcoding. But if you think it could be the issue, I'll give it a try.image.png.dc3490ddc802352602a389926795df77.png

Link to comment
Share on other sites

3 hours ago, ChipL said:

You mean blank the field out in the screenshot?  I can do that, but I'll have to reconfigure the machine because the volume where emby lives doesn't have sufficient disk space for video files or transcoding. But if you think it could be the issue, I'll give it a try.image.png.dc3490ddc802352602a389926795df77.png

Yes. It may not resolve it but it's important to at least try it to rule it out. Thanks.

  • Like 1
Link to comment
Share on other sites

ChipL

I have made the change to my virtual machine to give it tons of disk space so it can store the transcoded files in the default location. I'll report back in a few days if the problem seems to be resolved, or as soon as I can see that the solution did not work.

  • Thanks 1
Link to comment
Share on other sites

ChipL

Sadly I can report that changing the transcode directory didn't resolve anything. I have attached the latest server log and the transcode log of the last program watched.

I'm pretty sure that the problem is not related to transcoding itself because the process happens pretty fast and the file is usually fully transcoded before the problem first exhibits itself.

Also, it doesn't seem to be a problem with a specific point in the playback. If the problem happens (say at position 12:01 for example), I can rewind a bit and won't happen again at that same spot. Not sure if that helps, but the result of some of my own troubleshooting.

 

ffmpeg-directstream-316bb9fc-4ead-48da-a3da-bb5717496e3d_1.txt embyserver (2).txt

Link to comment
Share on other sites

2 hours ago, ChipL said:

Sadly I can report that changing the transcode directory didn't resolve anything. I have attached the latest server log and the transcode log of the last program watched.

I'm pretty sure that the problem is not related to transcoding itself because the process happens pretty fast and the file is usually fully transcoded before the problem first exhibits itself.

Also, it doesn't seem to be a problem with a specific point in the playback. If the problem happens (say at position 12:01 for example), I can rewind a bit and won't happen again at that same spot. Not sure if that helps, but the result of some of my own troubleshooting.

 

ffmpeg-directstream-316bb9fc-4ead-48da-a3da-bb5717496e3d_1.txt 251.99 kB · 1 download embyserver (2).txt 1.66 MB · 0 downloads

OK, if you disable the direct stream live tv option in the Roku app, does that resolve the issue?

Link to comment
Share on other sites

ChipL

I have toggled the direct stream option multiple times to troubleshoot. It had always been OFF prior to this problem starting. I had turned it on initially to see if it would solve the problem based on suggestions in other posts. On or off doesn't seem to make any difference at all.

Link to comment
Share on other sites

4 hours ago, ChipL said:

I have toggled the direct stream option multiple times to troubleshoot. It had always been OFF prior to this problem starting. I had turned it on initially to see if it would solve the problem based on suggestions in other posts. On or off doesn't seem to make any difference at all.

OK we do have a lead we can try out and put an update into the app beta channel for you to try. I don't think it's related to the server version.

  • Like 1
Link to comment
Share on other sites

20 hours ago, ChipL said:

How do I find the beta channel? Googling it yielded dead links, etc. 

Hi. We'll have to invite you once we have tried this change.

  • Like 1
Link to comment
Share on other sites

ChipL

I thought of something else that may be an issue.

Most of my recordings are from one channel. This time of year, atmospheric conditions (tropospheric ducting) cause some reception issues on this channel only. This is usually evident with pixelization, lost frames, etc. Most days the recordings are watchable with a few hiccups. Some days it's so bad that the tuner can't even get a channel lock, but there's nothing Emby can do about that.  😀 

Could it be that these errors are not being handled gracefully during transcoding, causing the issue? I thought of this because yesterday I watched a recording from a different channel and had zero problems. It could be a coincidence, but I thought I would add this in case it helps.

Link to comment
Share on other sites

1 hour ago, ChipL said:

Could it be that these errors are not being handled gracefully during transcoding, causing the issue?

Yes, that is very possible.  The Roku player is notorious for not handling bad signals well.

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
×
×
  • Create New...