Confirming that this is still an open, reported issue as of Version 1.24.4.5081.
This obvious and very reproducible bug was reported June 26th, 2020. This was 463 days ago:
Not been able to find developer in Michigan area to reproduce the problem and investigate
Would you know if there are equivalent channels in Seattle area we can try to repro the issue?
Thank you for your continued assistance and efforts towards addressing this issue @sa2000. Are you saying that all channels you have tried in the Seattle area do not exhibit this issue? As it appears to happen consistently and often with channels w/ dual audio channels, it should be pretty easy to reproduce anywhere.
Additionally, if it’s a matter of providing verbose logs and trying it out again to get you more information I would be happy to assist again/further. 
We have tried these 3 channels and they tuned ok and they did have multiple audio streams. It was actually San Jose and not Seattle
5.1 : KPIXDT (KPIXDT Affiliate: Columbia Broadcasting System)
7.1 : KGOLD (KGOLD Affiliate: American Broadcasting Companies)
11.3 : KSTSDT3 (KSTSDT3 Affiliate: National Broadcasting Company)
I am doing a compare between your zip code channel list and San Jose and will send you the list of channels that are for same affiliate and see if we can expand the test into other channels. Also could you confirm (i probably asked before) what your plex.tv audio / language default selection options are set to.
Might this be a case for using Verbose Logging to help track this down? 
May be verbose transcoder logging - but at this point after all this time i think we need to replicate the problem ourselves to allow the development team to have direct access to the issue when it arises.
It is unlikely that the developers will spend time on this without us being able to replicate it and allow them to troubleshoot the live session
Hey @sa2000 thank you for your continued assistance and patience here. After some poking, I have uncovered a vital piece of information with regards to this issue.
I am finding now that this issue occurs when using a virtual/RDP connection. If I connect with a device directly to my Plex server, the streams occur as expected with great regularity. That is, I cannot reproduce this on a direct, non-RDP/virtual connection. It is only when I use a virtual/RDP connection that this problem emerges.
For additional reference, I use Hyper-V extensively with my environment, so I connect to everything here locally via RDP/Hyper-V. This is how my testing has been done since discovering this issue.
Additionally, I seem to recall attempting this on a non-RDP connection at some point and experiencing the same issue, so this was not a consideration for disclosure. However, now that it appears that this works consistently with a direct connection and not with an RDP/virtual connection, then this issue appears to be due to this factor.
I would be interested in hearing if you can reproduce this issue on your end using a virtual/RDP connection.
Interesting - an RDP session does not have a local display adapter and that affects codecs and encoding / decoding - but only issue I was aware was when PMS is launched in an RDP session and we ended up with crashes
I will pass the information on
I would not expect one to use the player through an RDP session since remote access feature allows you to go direct through the public IP and public port - so as far as I can see there is no such valid use case
1 Like
but only issue I was aware was when PMS is launched in an RDP session and we ended up with crashes
No crashes and in fact, everything actually works well with the exception of these live streaming channels. Even then, it still works 10-20% of the time.
so as far as I can see there is no such valid use case
If this is the case then a message should be displayed to the user denoting as such. Otherwise you have users such as myself that basically are using your product in a way that seems normal and perfectly valid (and for the most part results in such via actual results) but is not. So either there is a technical issue here that needs to be addressed and/or a user interface/experience one that needs to be implemented. Unless, that is, you enjoy having users badger you for over a year over what are ultimately unsupported scenarios. 
Bad jokes aside, if this is a legitimately unsupported scenario a link to a resource that definitively describes it as such would be appreciated. However, since it’s so close to working, I would obviously prefer to see if we can find the extra cycles to make it work.
go direct through the public IP and public port
To be sure, are you saying I would have to expose my Plex server as a public IP address? If so, that is not a viable option for my environment, I am afraid.
I will pass the information on
Thank you so very much! 
Just need confirmation if PMS itself is launched in an RDP session - or is it automatically launched on server restart and the RDP is just being used for Plex Web session to playback the Live TV DVR channel
The only use of RDP is as a client to load a browser process that subsequently loads app.plex.tv/desktop. That is, I use RDP (and also Virtual Machine Connection) to load the browser client which then accesses the (Plex) server.
The Plex server/PMS is started automatically on machine start via Task Manager.
So, this one:
or is it automatically launched on server restart and the RDP is just being used for Plex Web session to playback the Live TV DVR channel
Thank You
Task Manager or Task Scheduler ?
And are Hardware Transcoding and Hardware Encoding options enabled on Server settings ? Do these settings change the behaviour for these channels RDP playbacks?
Use hardware acceleration when available
Use hardware-accelerated video encoding
DOH… Task Scheduler. 
Do these settings change the behaviour for these channels RDP playbacks?
They were both enabled. I attempted to toggle each one, save, and stream Channel 3.1. None of them were successful.
So, a bit of a bummer here @sa2000 … I used my Surface Pro 7 tablet here again and while I was able to easily and consistently load those stations on it previously last week, it no longer does so and I am running into the same issue now with it as well.
This is very surprising as I tried 5 or 6 times and each time the video loaded without issue. Now it is putting up a fight like the other RDP-enabled connections.
So this makes it 3 different devices that I am experiencing this issue on, 1 that is direct connect (without RDP), and the other two are RDP.
Can you tell me if Plex Media Server is launched through scheduled task for this?
To be sure the direct connect is through the Surface Pro 7 which uses a Chrome web browser instance. The PMS is hosted on a Windows 10 server and is indeed always launched on startup via scheduled task in the Task Scheduler.
For troubleshooting purposes, however, I tried closing all Plex Services and running the server from as a “regular” application, and the problem still occurs.
well - that brings us back to square one ! I thought we had an angle on this and it was to do with PMS running effectively as headless server and RDP for client playback sessions
I will still see if we can repro the problem as per previous info and park this new confusing outcome on the side
I will still see if we can repro the problem as per previous info and park this new confusing outcome on the side
Tell me about it… I am just as perplexed/confused about this whole thing. I do appreciate your efforts and time, of course. I would definitely see if you can repro it on your end using the information to date. I will continue to poke over here as well. It was working without issue when I first tried it on the Surface Pro 7… I will see if there’s a configuration or something that is perhaps contributing.
Boo… I am so irritated with this. It’s bombing out on the SP7 now each and every time now. The only thing I can think of is that when I initially tested it out on the SP7 I got really lucky and the shows that were on the channels I were testing were all single-audio channel.
In any case I am still open to providing additional logging if necessary, or even installing a special build if it can help you track this down if you cannot reproduce it on your side.
I’m just really surprised that this is not being reported by more users. Maybe people are not using Plex for their live local tv? And if they are they are not using a web browser?
We are hitting a dead end in our testing to reproduce the problem
We did a DVR setup in San Jose and tested out these channels
2.1 : KTVULD (KTVULD Affiliate: Fox Broadcasting Corporation)
5.1 : KPIXDT (KPIXDT Affiliate: Columbia Broadcasting System)
44.1 : KBCWDT (KBCWDT Affiliate: CBS-Warner Network)
44.4 : KBCWDT4 (KBCWDT4 Affiliate: TBD TV)
Setup was
- using same plex.tv account audio/language selection options
- PMS auto launch on login disabled
- PMS launched as scheduled task on windows start
- app.plex.tv/desktop Plex Web used in browser through an RDP session to stream these DVR live tv channels
All were successful
