Live TV pauses frequently, reports weak signal

Plex Media Server Desktops & Laptops
1

Hello:

I’m fairly new to Plex, and thought it could be the solution to my media needs.

I have a plex media server (with Plex Pass) running on a Xeon server, with ample CPU and RAM space allocated. I have an HD HomeRun Extend (auto-transcoding to MP4) hooked up to that and to an antenna on a tower (excellent signal quality). I then stream (through the Internet) my content, generally to a Fire TV Stick, but also tried an Android tablet.

When watching live TV, it will pause for about 5 seconds every 30 sec to 2 minutes. Its a pause, it resumes where it was when it pauses. Sometimes it reports “Weak Signal”. It is definitely NOT a weak TV signal, and the bandwidth and CPU resources are NOT underpowered.

If I record the program, wait for it to finish, and watch the same recording from my recordings list, it does NOT pause or have any issues.

I recently started playing around with bandwidth settings. In my case, my plex server is located over the internet from my viewing environment, but I found the “home bandwidth” settings are the ones that affect my viewing bandwidth. But I digress…

I’ve played with bandwidth extensively. I have about 8Mbps downstream at my home (viewing location); the server location has >100Mbps symmetric, and they are only a couple hops apart. My network topology is not to blame as long as I keep my bitrate to 6Mbps or less.

I am NOT getting errors about insufficient bandwidth, I am getting them for “weak signal”. It ONLY affects live TV; if the program is set to record, I can watch the recording after it finishes with NO ISSUES at the SAME OR GREATER bandiwdth. Same transcoding taking place.

On the server end, CPU utilization is typically about 27% during these issues.

I had the same issue on Fire TV and Android app. Visio TV app (my other TV smart interface) does not support live TV currently, so no data there. I don’t own a Roku, and I couldn’t get the android app to cast reliably, so I don’t have any other data to go on.

It seems to me that there is a bug in Live TV only. Is there a known fix for this problem? I’d like to watch some live TV soon, but the constant pauses are unbearable.

2 Likes
2

I’m not on the livetv team but can look and see what errors it’s outputing to your log.

CPU utilization of 27% is a bit suspicious if it’s a quad-core CPU. (sounds like a single-threading issue)

Please do the following:

  1. Verify only DEBUG logging is enabled in t Settings - Server - General
  2. Play something just long enough for it to fail / cause the problem
  3. Stop playback and wait about 30 seconds
  4. Settings - Server - Help - Download Logs
  5. Attach the ZIP file it gives you
3

Sorry for the long delay. Attached is the logs requested, i believe. Plex Media Server Logs_2018-07-31_03-34-17.zip (2.3 MB)

It generally starts glitching about 10 seconds in. most often with Amazon sticks; I’m on my second amazon stick with the same glitch.

I don’t have any other supported streaming devices for TVs, and I haven’t tested enough on my phone or computer (I don’t know if my phone is a valid test, and I can’t cast live TV yet, so I couldn’t test that way either).

I appreciate suggestions or corrections.

–Jim

4

This is strange… Maybe you can provide the background info?

At this time point, It was almost 15 minutes into a recording. Another session had started and was 111 seconds into it.

The next I see is the payback stopping as if terminated by the client player (android device)

bytes (pipelined: 29)
Jul 31, 2018 03:30:39.368 [0x7f3feb3f4700] DEBUG - Transcoder segment range: 0 - 111
Jul 31, 2018 03:30:39.409 [0x7f3fffbfc700] DEBUG - Transcoder segment range: 0 - 896
Jul 31, 2018 03:30:39.603 [0x7f3fecbf7700] DEBUG - Transcoder segment range: 0 - 112
Jul 31, 2018 03:30:39.699 [0x7f400f7ff700] DEBUG - Auth: authenticated user 1 as jim@kusznir.net
Jul 31, 2018 03:30:39.701 [0x7f3fee3fa700] DEBUG - Request: [192.168.4.65:34894 (WAN)] GET /:/timeline?duration=2001&guid=com.gracenote.onconnect%3A%2F%2Fepisode%2FEP007517000327&key=%2Flivetv%2Fsessions%2Fbdcac4a9-6014-4b69-a35b-c527faed874e&playQueueItemID=0&ratingKey=59&state=playing&time=2001&token=xxxxxxxxxxxxxxxxxxxx (22 live) TLS GZIP Signed-in Token (jim@kusznir.net)
Jul 31, 2018 03:30:39.702 [0x7f3fee3fa700] DEBUG - Client [d373bff849e965e0-com-plexapp-android] reporting timeline state playing, progress of 2001/2001ms for guid=com.gracenote.onconnect://episode/EP007517000327, ratingKey=59 url=, key=/livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e, containerKey=, metadataId=59
Jul 31, 2018 03:30:39.702 [0x7f3fee3fa700] DEBUG - [Now] User is jim@kusznir.net (ID: 1)
Jul 31, 2018 03:30:39.702 [0x7f3fee3fa700] DEBUG - [Now] Device is Android (Fire TV Stick).
Jul 31, 2018 03:30:39.702 [0x7f3fee3fa700] DEBUG - [Now] Profile is Android
Jul 31, 2018 03:30:39.702 [0x7f3fee3fa700] DEBUG - [Now] Updated play state for /livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e.
Jul 31, 2018 03:30:39.704 [0x7f3fee3fa700] DEBUG - Statistics: (d373bff849e965e0-com-plexapp-android) Reporting active playback in state 0 of type 12 (scrobble: 0) for account 1
Jul 31, 2018 03:30:39.708 [0x7f400effe700] DEBUG - Completed: [192.168.4.65:34894] 200 GET /:/timeline?duration=2001&guid=com.gracenote.onconnect%3A%2F%2Fepisode%2FEP007517000327&key=%2Flivetv%2Fsessions%2Fbdcac4a9-6014-4b69-a35b-c527faed874e&playQueueItemID=0&ratingKey=59&state=playing&time=2001&token=xxxxxxxxxxxxxxxxxxxx (22 live) TLS GZIP 9ms 844 bytes (pipelined: 18)
Jul 31, 2018 03:30:39.766 [0x7f3fec3f6700] DEBUG - Request: [127.0.0.1:51906 (Loopback)] GET /livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e/d373bff849e965e0-com-plexapp-android/00057.ts (22 live) Signed-in
Jul 31, 2018 03:30:39.767 [0x7f3fec3f6700] DEBUG - Content-Length of /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/Transcode/Sessions/plex-transcode-bdcac4a9-6014-4b69-a35b-c527faed874e/media-00057.ts is 1136272.
Jul 31, 2018 03:30:39.780 [0x7f400f7ff700] DEBUG - Completed: [127.0.0.1:51906] 200 GET /livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e/d373bff849e965e0-com-plexapp-android/00057.ts (21 live) 13ms 1136272 bytes (pipelined: 29)
Jul 31, 2018 03:30:39.816 [0x7f3fff3fb700] DEBUG - Transcoder segment range: 0 - 113
Jul 31, 2018 03:30:40.034 [0x7f3fed3f8700] DEBUG - Transcoder segment range: 0 - 114
Jul 31, 2018 03:30:40.180 [0x7f3fffbfc700] DEBUG - Request: [127.0.0.1:51904 (Loopback)] GET /livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e/d373bff849e965e0-com-plexapp-android/00058.ts (22 live) Signed-in
Jul 31, 2018 03:30:40.184 [0x7f3fffbfc700] DEBUG - Content-Length of /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/Transcode/Sessions/plex-transcode-bdcac4a9-6014-4b69-a35b-c527faed874e/media-00058.ts is 1084196.
Jul 31, 2018 03:30:40.194 [0x7f400effe700] DEBUG - Completed: [127.0.0.1:51904] 200 GET /livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e/d373bff849e965e0-com-plexapp-android/00058.ts (21 live) 14ms 1084196 bytes (pipelined: 30)
Jul 31, 2018 03:30:40.226 [0x7f3fecbf7700] DEBUG - Transcoder segment range: 0 - 115
Jul 31, 2018 03:30:40.455 [0x7f3fee3fa700] DEBUG - Transcoder segment range: 0 - 116
Jul 31, 2018 03:30:40.533 [0x7f400f7ff700] DEBUG - Auth: authenticated user 1 as jim@kusznir.net
Jul 31, 2018 03:30:40.536 [0x7f3fff3fb700] DEBUG - Request: [192.168.4.63:54226 (WAN)] GET /status/sessions/background (22 live) TLS GZIP Signed-in Token (jim@kusznir.net)
Jul 31, 2018 03:30:40.539 [0x7f400effe700] DEBUG - Completed: [192.168.4.63:54226] 200 GET /status/sessions/background (22 live) TLS GZIP 6ms 470 bytes (pipelined: 31)
Jul 31, 2018 03:30:40.541 [0x7f400f7ff700] DEBUG - Auth: authenticated user 1 as jim@kusznir.net
Jul 31, 2018 03:30:40.541 [0x7f3febbf5700] DEBUG - Request: [192.168.4.65:34894 (WAN)] GET /:/timeline?duration=2001&guid=com.gracenote.onconnect%3A%2F%2Fepisode%2FEP007517000327&key=%2Flivetv%2Fsessions%2Fbdcac4a9-6014-4b69-a35b-c527faed874e&playQueueItemID=0&ratingKey=59&state=stopped&time=2001&token=xxxxxxxxxxxxxxxxxxxx (21 live) TLS GZIP Signed-in Token (jim@kusznir.net)
Jul 31, 2018 03:30:40.542 [0x7f3febbf5700] DEBUG - Client [d373bff849e965e0-com-plexapp-android] reporting timeline state stopped, progress of 2001/2001ms for guid=com.gracenote.onconnect://episode/EP007517000327, ratingKey=59 url=, key=/livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e, containerKey=, metadataId=59
Jul 31, 2018 03:30:40.542 [0x7f3febbf5700] DEBUG - [Now] User is jim@kusznir.net (ID: 1)
Jul 31, 2018 03:30:40.542 [0x7f3febbf5700] DEBUG - [Now] Device is Android (Fire TV Stick).
Jul 31, 2018 03:30:40.542 [0x7f3febbf5700] DEBUG - [Now] Profile is Android
Jul 31, 2018 03:30:40.542 [0x7f3febbf5700] DEBUG - [Now] Updated play state for /livetv/sessions/bdcac4a9-6014-4b69-a35b-c527faed874e.
Jul 31, 2018 03:30:40.544 [0x7f3febbf5700] DEBUG - Statistics: (d373bff849e965e0-com-plexapp-android) Reporting active playback in state 3 of type 12 (scrobble: 0) for account 1
Jul 31, 2018 03:30:40.544 [0x7f3febbf5700] DEBUG - Streaming Resource: Terminating session 0x7f4006a09520:d373bff849e965e0-com-plexapp-android which is using transcoder slot.  Used slots is now 0
Jul 31, 2018 03:30:40.545 [0x7f3febbf5700] DEBUG - Streaming Resource: Terminated session 0x7f4006a09520:d373bff849e965e0-com-plexapp-android with reason Client stopped playback.
Jul 31, 2018 03:30:40.545 [0x7f3febbf5700] DEBUG - Streaming Resource: Removing session 0x7f4006a09520:d373bff849e965e0-com-plexapp-android
Jul 31, 2018 03:30:40.548 [0x7f40013ff700] DEBUG - Killing job.
Jul 31, 2018 03:30:40.548 [0x7f40013ff700] DEBUG - Signalling job ID 6564 with 9
Jul 31, 2018 03:30:40.548 [0x7f40013ff700] DEBUG - Job was already killed, not killing again.
Jul 31, 2018 03:30:40.548 [0x7f40013ff700] DEBUG - Stopping transcode session d373bff849e965e0-com-plexapp-android
Jul 31, 2018 03:30:40.548 [0x7f3ff2bff700] DEBUG - Cleaning directory for session d373bff849e965e0-com-plexapp-android (/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/Transcode/Sessions/plex-transcode-d373bff849e965e0-com-plexapp-android-65096cc1-8afb-4282-ae10-710cf6470d7d)
Jul 31, 2018 03:30:40.550 [0x7f400effe700] DEBUG - Completed: [192.168.4.65:34894] 200 GET /:/timeline?duration=2001&guid=com.gracenote.onconnect%3A%2F%2Fepisode%2FEP007517000327&key=%2Flivetv%2Fsessions%2Fbdcac4a9-6014-4b69-a35b
5

I didn’t now how to “clear the log”; I had experimented with a few different things tonight. The most recent would be the amazon stick playback.

I did try watching the program in my phone with the intent to cast. I started playback before connecting cast, couldn’t find the cast button, exited playback, found the cast button, then retried to start playback and got the not supported message.

I’m still getting used to plex, so sometimes I think I’ve stopped playback when I later notice its still in the active sessions. For this one, I think I may have “paused” rather than “stopped” the playback in question on the amazon stick.

–Jim

6

Jim,
When trying to figure out what’s happening, the best way to help us (surprisingly) is to simply restart PMS and recreate the problem with nothing else running (if possible).

When you do this, we see the restart in the logs making for a clean delineation. If there is one thing active, when it fails, it’s easy to spot.

PMS does take some time to master. It can do a lot all at once and, unfortunately, it’s easy to lose track of what’s actually happening.

Would you mind trying to recreate the sequence where you see the failure? When you see it, wait about 15 seconds , terminate playback (if it hasn’t already stopped/terminated), then another 10-15 seconds and gather the logs.

Doing this lets us see the failure, we then see PMS stop what it’s doing, then see the delineation again as you generate the log file capture.

It really helps us to simply walk backwards in time until we see the fault.

7

Ok, I think I got this one much cleaner.

I tried to watch Elementary, but quickly aborted that, as for some reason that channel isn’t working (been meaning to post a separate topic about that: when I try and tune from the PC, I get “Unable to tune channel: no parts” and my scheduled recordings for that channel fail too). I then tried Dateline NBC, and after two attempts, it never started playing (no idea there…), so then tried POV, and that worked as usual (it stuttered out and printed the message “Weak Singal”. i watched it for a few minutes (3 stutterings), then exited, waited a bit longer, and downloaded and attached logs here.Plex Media Server Logs_2018-07-31_05-13-35.zip (2.1 MB)

–Jim

8

Follow-up info:

I tried watching it from my laptop (chrome web browser), and while it didn’t show “weak signal”, it still frequently rebuffered and paused.

I also noticed after I sent that to you that there was a background (“nice”) transcoding taking place of a prior recording. That transcoding ended, so I reran both tests, and both failed in the same way.

I also tested earlier today on a different internet connection with my laptop, and had mixed results. it seemed HD sources had issues, but SD sources did not.

(Also, relating to my message above about “unable to tune channel: no parts”: I found that that specific channel has 3 sub-carriers: two in HD and one in SD. The SD carrier tuned OK, but the HD carriers did not (gave the no parts error).

Thanks for the help!
–Jim

9

and I just tried an SD carrier live tv (28.2) and had it stuttering a lot too, but no “weak signal” message.

–Jim

10

If you’re getting stuttering, I hate to say it but that Nehalem just can’t cut it. The MPEG2 decode & then encode to H.264 is simply too much for it in spite of its Passmark rating.

I see where a lot of i7-2xxx machines have trouble.

If you had anything -3xxx and above, you’d have HW trancoding availability and this wouldn’t be an issue whatsoever but the Nehalem predates QSV technology

11

Don’t know if it matters, but I’m using an HD HomeRun Extend (for most channels), so that is coming in h.264 by default, not mpeg.

I can watch pre-recorded programs without issue (and they are typically being transcoded) while live are the issue. That’s what confused me. Even when I was using my basic hdhomerun dual, I’d get the raw mpeg2 recording on disk, and if it was in my library and I watched it from there, the transcoding would work just fine. If I tried to watch it live, that’s where I had the issue.

In case it matters, the server in question is actually a VM on my oVirt server farm of Dell R610 servers, with a separate freeNAS dedicated storage system, with all network interconnects at 10Gbps. I can give it more cores (my base servers are Intel Xeon E5530 @ 2.4ghz (dual socket, quad core each socket, hyperthreading). ovirt passes through the Nahalem 3xx to its VMs. I can give it some more cores, but not much more.

BTW: when it transcoded a program (after recording), it did manage to do it at 4x speed (1hr program trancoded (“optimized”) in 15 minutes). I’d imagine that if it can do 4x realtime, then it should be able to do realtime too…

12

That REALLY would have helped knowing when this first started.

Knowing what the hardware is, or isn’t, is important when you’re trying to diagnose a performance problem. It’s also extremely important to know if the server is running native on the host or in any kind of abstraction (such as a VM).

I would like to pick this back up tomorrow. It’s 2am for me and I’ve been working in the forums for the better part of 14 hours now today.

I will say this. You’re still asking a lot of a 10 year old CPU but please do allow me to think about the entire issue overnight . Host OS + VM + PMS is quite a load

Edit: It is still multiplexing and transcoding the audio for the player. This is load nonetheless. Again, I’ll go through it again when my mind is fresh in the AM.

Edit2: Looking at oVirt, it doesn’t seem to have CPU Passthrough. All the stuttering would be gone if it could.

13

PMS is choking on the video stream and is unable to decode the material from time to time:

Example:

Jul 31, 2018 05:09:31.039 [0x7fa8fcbfd700] ERROR - [Transcoder] [h264 @ 0x31884c0] error while decoding MB 72 44, bytestream -7
Jul 31, 2018 05:09:31.081 [0x7fa8fa3fe700] ERROR - [Transcoder] [h264 @ 0x31884c0] error while decoding MB 54 44, bytestream -5

That’s what’s generating “weak signal” with live streaming. Of course, this is not an issue with recordings where the broken segments are just skipped and not stored in the file stored on your server.

Please let your HomeRun Extend do the first transcoding. Set the appropriate quality in the Plex DVR settings of this device, not “Original Quality” (https://support.plex.tv/articles/225877347-live-tv-dvr/#toc-2). Thus, the errors in the video stream are fixed by the HomeRun and PMS should be much more stable.

14

Thank you both for your reply. My tuner settings are already set to transcode, and when I watch TV, i see another transcode taking place, but it says H264 to H264, so the tuner definitely transcoded once already. I’ve got it set to “High 30 fps”; i started out with “Highest”.

I apologize about not giving all the VM details. Its been my experience that a lot of people with projects that are not typically run on a server farm fear virtualization, or just place 100% blame on virt and drop the issue. I’ve learned to generally leave that detail out, as normally its just noise that prevents finding the real problem.

My entire use case for plex is to get local TV at my new house. For my “day job” (I own some businesses that provide various IT and tech services, as well as a VoIP service), I have a VM infastructure to run my various servers at a small data center that happens to be up on a hill. My new house is in a valley and cannot receive any OTA TV. My data center already has TV antennas that pick up all the locals, so I just figured I’d drop some tuners and a server on my stack to capture OTA tv and allow me to watch from home. Plex looks like a good solution for that. Since I already had the tuners from my last hosue (where they were used with MythTV and had a good direct signal from the TV stations), my net cost would be just the plex pass. I’m running monthly until I know this will actually work.

So back to the issue, I’m confused by the transcoder errors…the tuner is already transocding, so those would have been taken care of already, right?

As to why I transcode: my house has about 7.8Mbps bandwidth. It appears that my recordings require about 8.2Mbps in “native/full quality” mode. So I’m just barely out of luck. The next setting down is 4Mbps, so I’ve been trying to get it working using that setting for everything. I would much rather use 6-7Mbps (Netflix streams at 7mbps without issue) and keep the higher quality…

15

Hm. Now please try the opposite of what I have said and set the DVR device transcoder quality to “Original format” :slight_smile: Just to make sure your HomeRun does not do something inappropriate :smiley:

16

Interestingly enough, from my PC, it didn’t glitch with the transcoding turned off. I’m at work now, so I couldn’t test with my amazon stick to see if it does the right thing. Also, on the pc app, when I clicked the “settings” that usually lets me choose my stream bitrate, that wasn’t an option. I did see on the plex web app (another window) that it was running a transcode from mpeg2 to h264, so it was doing a transode.

Looking at top on my server, there was 60% cpu idle. about 24% userspace, and about 19% nice. It appears the transcoding was well within the computational power of the (virtual) machine.

–Jim

17

Just finished more testing (looks like I generally only get the TV from the wife on Mondays…really, the main program we want to watch live is on Mondays.

In any case, the amazon stick still stuttered unwatchably and reported "weak signalPlex Media Server Logs_2018-08-07_03-37-47.zip (2.9 MB)
“. The only android device I could get into plex with was my cell phone, and on that (about 4” screen…), it played back smoothly, although even though I selected “watch from beginning”, it started live.

Logs attached. First playback was the Amazon Fire Stick, Second was the Android phone. Playbacks occured at 8:30 Pacific on Monday Aug 6th.

18

Transcoder is probably having issues due to low disk messages:

Aug 07, 2018 03:37:35.952 [0x7fa8e97f6700] WARN - Low disk space: 0B source file, 7.99GB capacity, 96.32MB available on "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/Transcode/Sessions/plex-transcode-7bd9e430-867b-41e1-91c0-4e8e370092f9"

Also probably because you have Plex set to not transcode using the Extend. Why purchase an Extend and force Plex to transcode mpeg2 video to h264:

Aug 07, 2018 03:00:00.259 [0x7fa8edfff700] DEBUG - DVR:Segmenter: Creating a new recorder for http://192.168.8.141:5004/auto/v22.1?transcode=none.

I see no playback at 8:30 pm on 8/6.

19

Hmm…

So, disk space is as follows:
[root@plex ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 8.0G 2.4G 5.7G 30% /
devtmpfs 860M 0 860M 0% /dev
tmpfs 883M 8.0K 883M 1% /dev/shm
tmpfs 883M 33M 851M 4% /run
tmpfs 883M 0 883M 0% /sys/fs/cgroup
/dev/sda1 100G 48G 53G 48% /plex-media
tmpfs 177M 0 177M 0% /run/user/0

The /dev/sda1 is the media storage location, as you can see, with 100GB. The rest is a small boot drive. There is plenty of disk space…is there a process trying to write to somewhere else and needs more space? If so, where is it trying to write? Can that be moved to the storage directory?

As to the extend transcoding being disabled, if you look up in the thread, the last troubleshooting tip I was asked to perform is to disable transcoding in the extend to make sure its not causing the issues. I have turned transcoding back on to “High (30fps)” setting.

–Jim

20

As you can see in the above message, PMS stores all meta data by default in /var/lib/plexmediaserver/Library/Application Support/Plex Media Server: media infos, thumbnails, chapter images, …, and the intermediate data created by the transcoder. Your 8 GB for this storage is awfully small (the storage for / relevant here) . In fact, too small.

At least, change the “Transcoder temporary directory” in the PMS Transcoder settings and make sure this directory is writable by Linux user plex.

You should probably also consider to move the complete PMS meta data storage: