Buffering of Live TV

I have a Synology DS918+ running DSM 6.2-23739 Update 2. The server has 8GB of RAM installed.

The server is running Plex 1.13.8.5395.

When I try to watch live TV from an HDHomeRun device connected to the network, I get constant buffering interruptions. From what I read in these forums, this shouldn’t be a problem.

The playback device is a Win10 laptop using Chrome.

Any idea as to what I’m doing wrong?

I’ve attached a log file for info.Plex Media Server Logs_2018-09-25_08-21-58.zip (7.1 MB)

Please confirm: 8GB of RAM is configured as 2x 4GB modules and not 1x 8GB

Please turn OFF the VERBOSE logging. your logs are of no use this way. We only use Verbose for isolated events requiring painstaking detail. VERBOSE logs only show 1-2 minutes of elapsed time.

Please turn VERBOSE OFF
Please turn DEBUG ON

recreate the issue,
stop playback
wait 30 seconds
collect the logs
attach here for review.

Thanks.

I followed your instructions. A new log file is attached.Plex Media Server Logs_2018-09-25_14-33-17.zip (6.2 MB)

The previously attached log file had a mix of VERBOSE ON at the beginning and VERBOSE OFF at the end.

Thanks for the help.

I forgot to answer your first question. The DS918+ was purchased with one 4GB memory stick installed. A second 4GB memory stick was added later. The DSM control panel shows physical memory as 8192 MB.

I am seeing your hardware acceleration enabling. Looking good there.

I am occasionally seeing video frames.

Sep 25, 2018 14:30:01.760 [0x7f9d8f3ff700] DEBUG - EPG[onconnect]: Next thing to start/end is at 2018-09-25 20:00:00 GMT (in 1800 seconds)
Sep 25, 2018 14:30:01.897 [0x7f9d72bff700] DEBUG - Request: [127.0.0.1:53758 (Loopback)] PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/stream?index=0&id=49&codec=mpeg2video&type=video (17 live) Signed-in Token (agbommarito)
Sep 25, 2018 14:30:01.898 [0x7f9d973ff700] DEBUG - Completed: [127.0.0.1:53758] 206 PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/stream?index=0&id=49&codec=mpeg2video&type=video (17 live) 0ms 227 bytes (range: bytes=0-) 
Sep 25, 2018 14:30:01.899 [0x7f9d6b735700] DEBUG - Request: [127.0.0.1:53760 (Loopback)] PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/stream?index=1&id=52&codec=ac3&type=audio (18 live) Signed-in Token (agbommarito)
Sep 25, 2018 14:30:01.899 [0x7f9d973ff700] DEBUG - Completed: [127.0.0.1:53760] 206 PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/stream?index=1&id=52&codec=ac3&type=audio (18 live) 0ms 227 bytes (range: bytes=0-) 
Sep 25, 2018 14:30:01.900 [0x7f9d86335700] DEBUG - Request: [127.0.0.1:53762 (Loopback)] PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/stream?index=2&id=53&codec=ac3&type=audio (19 live) Signed-in Token (agbommarito)
Sep 25, 2018 14:30:01.901 [0x7f9d97111700] DEBUG - Completed: [127.0.0.1:53762] 206 PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/stream?index=2&id=53&codec=ac3&type=audio (19 live) 0ms 227 bytes (range: bytes=0-) 
Sep 25, 2018 14:30:01.936 [0x7f9d6bd11700] ERROR - [Transcoder] [mpeg2video @ 0x1b0bb00] Invalid frame dimensions 0x0.
Sep 25, 2018 14:30:01.993 [0x7f9d86047700] ERROR - [Transcoder] [mpeg2video @ 0x1b0bb00] Invalid frame dimensions 0x0.
Sep 25, 2018 14:30:02.012 [0x7f9d80a23700] ERROR - [Transcoder] [mpeg2video @ 0x1b0bb00] Invalid frame dimensions 0x0.
Sep 25, 2018 14:30:02.033 [0x7f9d8c3ff700] ERROR - [Transcoder] [mpeg2video @ 0x1b0bb00] Invalid frame dimensions 0x0.
Sep 25, 2018 14:30:02.146 [0x7f9d72bff700] ERROR - [Transcoder] [mpeg2video @ 0x1b0bb00] Invalid frame dimensions 0x0.
Sep 25, 2018 14:30:02.665 [0x7f9d6b735700] DEBUG - Request: [127.0.0.1:53774 (Loopback)] PUT /video/:/transcode/session/a1d72457-4558-4396-8d36-c9e94bc5da4f/b1bba9f0-974a-40c1-a8a2-4ba051940bd0/progress/streamDetail?index=0&id=49&codec=mpeg2video&type=video&profile=Main&width=1920&height=1080&interlaced=1&sar=1:1&level=4&frameRate=29.970&closedCaptions=1 (22 live) Signed-in Token (agbommarito)

Some signal degradation in the line. You will need (typically) three parameters for a good recording. The signal will reflect good strength, signal quality, and, most importantly, Symbol quality.

I do not see which tuner you have but the Silicon Dust tuners will let you examine the channel lineup via their web interface. You can look there to see if there might be ‘one splitter too many’.

If this checks out, WiFi / networking is the next place to look. To play LiveTV without buffering, you typically need ~15 Mbps sustained for MPEG2 (which you are getting from your provider)

I’m using an HDHomeRun Connect. I used another computer to look at the tuner web page while the laptop was doing a live TV play. The status screen showed this:

image

The laptop wireless adapter properties shows a 300 Mbps connection. The adapter is an Intel AC-7265.

Any other things to check?

I would prefer better signal strength and quality but what can you expect .
If you count the number of splitters, and the dB drop of each, what does the total drop look like? (remembering 3 dB is a 50% reduction).

Also, if you tune another channel at the other end of the spectrum, do you experience the same difficulties?

( troubleshooting cable provider issues is a pain… haha)

I’ve been playing around with this issue and ran a few tests.

Using the same PC as a player, I opened a Chrome web client and an Edge web client at the same time. On both, I tuned to a live TV broadcast on the same channel.

The Chrome client does a lot of buffering but the Edge client never buffers.

The Chrome client says that the server is “Nearby” but the Edge client says the server is “Indirect”.

Both clients say that they’re doing HW transcoding and the server CPU doesn’t seem to go over 50% loading.

I made sure that the web client settings for both were exactly the same.

I then repeated the test but this time used a Chrome web client at the same time as an HDHomeRun player app. The Chrome web client buffers but the HDHomeRun app never does.

Does any of this make sense?

Here’s what I’m getting on my ds918+

Running latest DSM 6.2.1-23824 + Plex Server 1.13.9.5439 + WinTV-HVR-955Q
Hardware acceleration is enabled. Plex is installed directly on the NAS.
Live TV direct play to Nvidia Shield plex client works great.
Live TV hw transcode to Safari tab buffers every 2-5min.

Seems like it’s a hw transcode issue, no?

I’m running the same version of DSM and PMS as alexberman. But I’m using an HDHomeRun tuner instead of a Hauppauge tuner.

Live TV to an Android phone using HW transcode buffers every 30 seconds or so. I’ve tried playing with the quality settings but they didn’t seem to have any effect.

I’d agree with alexberman that there is something borked with the HW transcode.

I may have finally made a breakthrough on the problem I was having.

I think ChuckPA was right that the problem was due to signal degradation from the HDHomeRun to the PMS NAS box. The cause of the degradation seems to be that the signal from my antenna to the HDHomeRun was too strong. Depending on the station, time of day and atmospheric conditions, the HDHomeRun front end would get temporarily overloaded which would result in errors in the data stream that PMS couldn’t handle.

I put an attenuator between the antenna and the HDHomeRun input. I used a -7.5 dB attenuator as that was what I had on hand. This was done about one week ago and the problems seem to have disappeared.

Fyi I have a Qnap TS251+ running Plex to a Roku powered tv. My input for Live TV is a HDHomerun Prime . Recently got a lot of frequent buffering to any TV in the house running Plex over Roku. Live TV would start then buffer then run 5-10 and then repeat. I just downgraded the PLex version on Saturday to 1.13.5.5332 and now the buffering has disappeared. I suspect something is not working well with the latest version since this older version does not repeat the problem.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.