Server Version#: Version 1.19.5.3006
Player Version#: Web Version 4.36.1
Tuner Make/Model: Hauppauge WinTV-quadHD (Model 1651xx-2, Dual ATSC/QAM)
Guide/Lineup name: Various
Using XMLTV?: YUS
Channel number/Name: Various
Having trouble tracking this one down. I would appreciate some pointers on where to look. Essentially, Live TV works very well and expected on Roku players on any of our 43 registered channels, but on the Web Player, some channels work while others result in the spinning circle of doom.
I’m having trouble tracking this one down as when I look at the Logs directory and attempt to stream a channel, no new logs are being written.
Doh, nope… false alarm. It seems like it works for a while now and then simply stops. Adding the logs. Note that they do not even update until the following error is displayed:
I’m no expert but I’d guess one player is transcoding and the other is direct play.
My antenna is in an attic with a radiant barrier (long story) so I typically get great signal at night but some channels get pixelated or drop entirely during the day. Interestingly enough, some of the changes I have trouble tuning for live TV record just fine. I suspect this is due to the signal being sufficient for recording but causing hiccups for on the fly transcoding.
I have no foundation for this suspicion but seems like a reasonable possibility.
Thank you for your reply @solstyce9 yeah the interesting thing is that I see two Plex Transcoder.exe's fire every time I select a channel in web player. The web player is configured for Direct Play, btw. But I have tried fiddling with that and transcoding and it’s always the same: sometimes the channel will play, sometimes not. The title/episode data loads in the title bar (when the 2nd Plex Transcoder.exe fires), but after that it’s the spinning circle of doom. I close the player, try again. Sometimes it works, sometimes not. On the Roku it works each and every time. Roku BTW is set to transcode.
Maybe it’s a combination of signal and transmission type? I have noticed that on the web player, there’s a few channels where it works each and every time. Those are lower resolution, @ 480i. The ones I seem to have trouble with are in the higher resolutions.
In any case, if the problem was signal strength/resolution, it would seem something would be displayed to the user and/or in the logs? Neither of those are happening which is why this is so, um, per-plex-ing.
They need all the log files and more specifically the ‘Plex Media Server.log’.
Web browsers can’t direct play mpeg2 streams so everything is transcoded. Are you using the default transcoder location and does the drive have plenty of storage?
Cool, the logs what I am primarily interested in, @pl_5309… to be sure, the logs I provided above are from a clean slate. I deleted all logs, and then reproduced the issue, the result of which were zipped and uploaded here. The interesting thing to note of course is that Plex Media Server.log is not updated/created/written-to at all during this process, which is leading to my confusion here.
I am tempted to enable Verbose and resend but that seems to be a no-no here on the forums. Please advise.
As for default transcoder location, it has been placed on the C:\ drive (Plex Media Server is on M:\) and C:\ is 50GB of 464GB used, or 414GB free.
If you deleted the log files while Plex was running then you need to restart so Plex can reinitialize the log handler. You would only go to VERBOSE level when you know what the error is and looking for specific detail.
Since you have the browser app open you can go to Server Settings > Console and filter on WARN
and ERROR. Attempt playback on another browser tab and see if anything is reported.
That’s awesome, @pl_5309! Thank you for that tip. I did clear all logs and restarted the server. What appears when filtering on Warning is sort of concerning out of the bat:
Also of note is that in restarting the server I got an upgrade ping for Version 1.19.5.3006, which I installed and used for my previous post. Meaning, everything above is using Version 1.19.5.3006. I have edited my original post to reflect this new version as well.
If the " add the command line parameter -noninteractive to the start up command of PMS" doesn’t work then the autologin approach in you link sounds like a better sollution.
Normally I would say stay off the Beta channel but there are some nice fixes in that update.
The invalid frame dimensions are just Plex not liking the stream coming from the tuner. That alone doesn’t usually break Plex.
With Live TV being latency sensitive, I would be concerned about timing conflicts arising between the Wifi and tuner card. Any way to connect via ethernet just for testing.
Thank you for your continued assistance and insight it is very much appreciated, @pl_5309.
This is possible. I would have to dig around for some cable. Before I do so, please note that my testing is directly off the server machine. That is, I am using the web browser on the server itself (connected via RDP). I am also experiencing the same when I connect via my personal machine (which I am RDPing from) so that is how I know it’s not just localized.
The reason I bring that up is that since I am testing it directly from the server and on the server, that should be a direct connection, correct? If there’s another consideration here please let me know and I can proceed to do so.
Also do keep in mind that Roku’s stream these same channels with zero problems, so I am not sure it is a networking/latency issue, but keeping an open mind here as I didn’t even know where the Console was.
Wanted to check in on this issue and confirm that it still occurs on Version 1.19.5.3035. BTW I am not sure if I am the one that is supposed to ping @sa2000 or not, but just in case there you go. Please let me know if there is any further information you require to help diagnose this issue.