Yes as this is the way the app identifies audio devices. MPV uses this name as the identifier when selecting between multiple devices.
That’s a good question and likely the real crux of your issues. The only time I’ve seen them change for the same device is through a driver update/remove and re-install/etc.
Does MPV select the Audio Device or does Plex tell MPV which Audio Device to use by name? Not knowing how the relationship is structured (and how the communicate with each other), I’m not sure if this would be possible, but it seems to me that if Plex utilized the description to identify/select the Audio Device (and its corresponding configuration) and then provided the current proper name to MPV, that would both solve this particular situation as well as make Plex more user-friendly from the standpoint of relying on the name displayed in the UI (which appears the same whether the problem is happening or not) rather than some hidden identifier for Audio Device selection.
Where are the device → settings mappings stored? In a Plex config file or an MPV one?
Any thoughts on how to proceed in troubleshooting this? It seems like it is not caused by Plex updates, because those seems much less frequent than how often this problem occurs. @jcorn mentioned the computer going to sleep as a possible cause–I have not had a chance to test this, but it might explain the trigger (although it makes no sense to me why it would be happening as a result sleep/wake-up is very much about NOT changing state other than power). It is possible it is Windows Update running and updating things (new drivers, etc), that certainly seems to happen more often (on my main desktop at least) but even then, it’s not every day. What really bugs me, though, is that I have multiple audio devices on my main desktop. If the identifier was changing this frequently, how does Windows always know which device was last selected and manage to properly track all the settings for them?
It would really help to know how those unique identifiers are assigned. I wonder if it is a consequence of the HDMI configuration/handshake between the HTPC ↔ AVR being different because of whether or not the AVR sees the display device is on or not? So it’s kind of a timing thing? If the TV/projector is on already (at least enough for the AVR ↔ display HDMI handshake) then the AVR handshakes differently with the HTPC as compared to when the display is off?
I feel like I’ve entered the realm of wild speculation, particularly since I’m guessing many people run their HTPC through their AVR to the display device… I would think more people would encounter this. Maybe they just don’t notice that their AVR has started receiving PCM?
I feel like we’re one step away from resolving this, but I just can’t see the next step.
I did a little searching around and while I’m not sure whether this is relevant or not, it sounded like it might be helpful:
Examples of driver behaviors and events which result in a loss of user settings on audio endpoints and will make an audio endpoint appear “new” to the system, potentially triggering a change in the default device, are:
- Installing a different driver. For example, switching between the HDAudio class driver and the matching 3rd party driver for the hardware. This is expected and by design, as the user settings and available endpoints are not assumed to be the same between two or more unrelated driver installations.
- Uninstalling and reinstalling the driver. Uninstalling the audio driver causes AudioEndpointBuilder to delete the user settings associated to the driver. Installing a new driver will cause AudioEndpointBuilder to create new audio endpoints. This is expected behavior and by design, however this behavior should be avoided by automated installers when it results in an unexpected loss of user settings.
- Any changes to the audio endpoint filter reference string or pin ID. Audio endpoints are identified by the reference string passed to PnP when the KS interface was created, along with the pin ID for the external connector. Changing these values will cause a new audio endpoint to be created. This new audio endpoint will not contain the user settings associated to the prior reference string and connector pin ID. Reference strings and connector pin IDs must not change for the life of the driver installation, including across driver updates.
- A HDMI or display audio device changing the terminal type or sink ID. The terminal type and sink ID are expected to change when the user attaches a different display to the system, a different display is a new endpoint with new user settings associated to it. However, changing these values when there is no corresponding change to attached display will be perceived as a loss of user settings. The sink ID and terminal type must remain constant for the attached display.
From: Default Audio Endpoint Selection - Windows drivers | Microsoft Learn
The last 2 bullets, and especially the last one seem like they may be a clue here. Specifically, I am wondering if, expanding on my theory above about some kind of timing issue between when devices power on and handshakes occur, whether the AVR identifies itself one way to the HTPC before the display comes on and that then changes to something viewed as “new” when the display comes up. I would have expected that to only result in maybe 4 different combinations of possible values (display on/off * AVR on/off) and then everything would fit into one of those “recognized” situations, but maybe Windows and/or the AVR just go with “something is new, so let’s give it a new name”.
I don’t know if it’s helpful or a red herring, but it seemed potentially relevant to my rather-tired mind…
The app gets the list of devices from MPV including the name and description. The app thes does the audio device selection and tells MPV which to use.
It’s in the plex.ini file. There are two relevant keys here: QtAudioDevicePreferredOrder and QtAudioDevices.
My Denon AVR, Samsung TV, HTPC setup has been in place for a few years. In that time I estimate that I have had to reconfigure the audio settings in Windows desktop Plex app more than 1,000 times. Wrench → Player → I find a combination of Exclusive unchecked Audio device reset to Auto → re-select my Denon AVR, re-select HDMI, recheck all the audio formats → SAVE. This is daily, sometimes multiple times per day.
I always suspected it was power down sequence related. My TV has a power save feature set to 2 hours of inactivity, and sometimes turns itself off. I get why that would change the audio settings in Plex. What I don’t get is why once all the components are back on, Plex doesn’t return to the audio settings that were in place the last time everything was powered on. While this may sound trivial it’s actually had a big impact in how I perceive Plex in general. It is mentally exhausting to have to constantly baby-sit the audio configuration. I ****ing hate it. With a passion.
I feel better now having vented LOL. Please just create an option to hardcode audio settings. If that creates situations where I get no audio for example, when my AVR is off, so be it. At that point I would be more than happy to adjust the audio settings at that time. Please just give me a check box that promises no changes to audio. I want, need and deserve this check box. Thank you in advance Plex engineers. You will have done a good thing.
Suggest you provide logs as this is not happening to everyone.
I have never had to do what you have done.
I can power off my gear and Plex HTPC remembers my audio settings. Every time.
The only time it resets to default is when I update my GPU/audio drivers and that is to be expected.
Edit - oh and I’d suggest looking at your HTPC, not your AVR or TV. Plex HTPC selects audio devices through Windows (or MACOS etc).
The device is typically your built in PC audio/GPU device or add on card.,
In my case it is my AMD RX580X with HDMI audio and my BT headphones that connect to my HTPC.
The AVR and TV are down the chain after the event.
I was on Win 7 originally with no issues. Went to Win 10 Pro with no issues and have been on Win 11 Pro for a year or so now with no issues.
HTPC (2700X/RX580X) ------->Denon X1500H-------->NU80000
I have guests over using the rooms where my HTPC is located, but will take a look at my wasapi device info early next week.
@JohnAlex I have no doubt that your setup works fine. As I’m sure most people’s setups do, otherwise the forums would be filled with reports like this one. But so far 3 people have an identical issue on pretty vanilla setups of Plex. So it’s not a non-existent problem. And even has a proposed solution from @alphafoxtrot
My plan (when I can access the computer again) is to try to duplicate what @alphafoxtrot saw with wasapi device values changing. Then see if putting the computer to sleep is sufficient to make that happen.
Absolutely, I just replied to a person who suggested it was widespread.
I also identified it more likely as an issue with sleep/hibernate at the start of this thread.
It is almost certainly related to the machine hosting Plex HTPC, not Plex HTPC itself and not devices down the chain.
An OS issue, I agree. Are all three of you running Windows as an OS ?
Hell, sleep, hibernate and even fast startup are well known to do all sorts of crazy things to drivers.
Windows can and does overwrite drivers, especially GPU/audio drivers if you let it. I’ve disabled that capability on my own machines using Group Policy. I don’t think this is the cause but something to be wary of.
Good luck with it.
I’m on Windows 11. Does indeed seem like an OS issue, since Plex is just getting device ids from the OS. But I liked @alphafoxtrot idea of falling back to matching the description if no matching device id can be found.
If a user has existing settings and suddenly a device appears that has a different id but exactly the same description, what is the chance that it’s actually a different device? And even if it is a physically different device, if it has exactly the same description(which in my case includes a detailed model number), then it probably has very similar or identical audio parameters.
This info was really helpful, thank you @gbooker02. I got a chance to do some more poking around in my setup and I believe I have started to narrow in on what is going on.
I checked the plex.ini file and, conveniently, the QtAudioDevices key was near the top (so was QtAudioDevicePreferredOrder, but I don’t think it is particularly relevant here). It confirmed what I suspected, which is that the unique identifier for the name of the device has changed numerous times (as there were quite a few entries all with the same description and different names) and all of those appear to be recorded in the QtAudioDevices, with the most recent current/working version at the end of the list. I know that is the case because when I went into Plex HTPC, the Audio settings had reset, so I reconfigured it, exited Plex, and looked in the plex.ini file. The newest entry corresponded to the first entry in the QtAudioDevicePreferredOrder and also had some kind of timestamp in it that matched up.
I think we can definitively say that the changing unique identifier on the device name is the cause of the unwanted behavior in Plex.
As to why the unique identifier keeps changing, I continued digging First, I looked for anything that had updated recently, but there have been no Plex HTPC updates or driver updates that I could identify. (as an aside, I’m still on the 1.38 version of Plex HTPC and have not been prompted to auto-update; is that always done when you start Plex HTPC or is it somewhat spread out to reduce update load on servers?) Next, I rebooted, I put the HTPC to sleep, and I used the Suspend option in the Plex HTPC menu. In every instance the unique identifier stayed the same.
I tend to think that the issue @jcorn, @TheTrunkMonkey, and I are seeing is not related to Plex updates, driver updates, or simply sleep, suspend, or reboot. I’m not willing to say it is definitive, but I do not think those power-related actions alone cause the problem (I’m willing to take as a given that driver updates might cause it, but it does happen in the absence of such updates). I think the power-related actions in combination with the HDMI events (devices turning on/off in different orders and handshakes happening and re-happening) is the most likely cause. That is not easily tested as far as I can figure.
Next, it occurred to me that the audio device is provided via the HDMI port on the graphics card and thus is likely at least partially the responsibility of the NVIDIA GPU driver (which would make sense, because the description includes something like “NVIDIA High Definition Audio Device”; sorry, don’t have it in front of me, going from memory).
My GPU is an EVGA GeForce GTX 960. @JohnAlex indicated they are using an AMD GPU. @jcorn and @TheTrunkMonkey, why kind of GPUs are you using?
My current theory is that NVIDIA’s drivers during the HDMI handshake/update stuff are generating the new unique identifiers for the devices and providing those to the OS. I could find no settings that might allow for controlling that behavior (but I may have looked in the wrong place). Regardless, it strikes me (1) as unlikely that NVIDIA will change anything (and may well have good reasons for why they do it that way) and (2) other applications (and Windows itself) seem to cope with the unique identifiers changing just fine, given that NVIDIA is like 75%+ of the GPU market.
To @TheTrunkMonkey’s suggestion of just allowing for hardcoding of the device, I do not think that will work. MPV takes the name of the device from Plex, so Plex has to pass it that. But if the name has changed, hardcoding will not solve the problem be cause the hardcoded name being passed won’t exist.
Instead, if Plex were to use the description to identify the correct name from the list provided by MPV, this would almost certainly result in Plex behaving as everyone wants (as @jcorn articulated above). Additionally, as far as I can see, there really is no reason for Plex to be so beholden to the name of the device. It uses the description in the UI, so there’s no reason it couldn’t likewise identify the name by description in the list provided from MPV. Within Plex itself, it could store the description of the preferred device. Perhaps even just an additional setting to tell Plex to use description or name to identify preferred audio device would make everyone happy?
@gbooker02 what do you think?
I finally got a chance to look at the logs and plex.ini file. Things on my side look the same as @alphafoxtrot. I’m attaching the ini file and logs here. The .log.txt file is from 5/21, while the .2.log.txt file is from 5/14. You’ll see that they each reference different wasapi device names with identical wasapi device descriptions. @gbooker02 Hopefully the logs and .ini files will be helpful in troubleshooting?
My settings are still intact from the last time I changed them, even though the computer has slept in the meantime. So not just sleep and not just having the TV/soundbar turned off.
Plex HTPC.log.txt (167.0 KB)
plex.ini.txt (45.7 KB)
Plex HTPC.2.log.txt (1.9 MB)
This is likely in the NVIDIA driver but this is very much atypical behavior. I use a 2060 and the only times I recall seeing the identifier change is when I uninstalled the driver and installed anew (usually when downgrading the driver to try and fix some other NVIDIA driver issue).
Maybe you should try using DDU to uninstall the driver and install it fresh to see if that resolve the issue.
I will give the clean install a try, but I’m skeptical it will make any difference because the drivers I’m using were installed on a clean install of Windows very recently. Although the problem is atypical, it is not non-existent (or even unique)–besides this thread, there are numerous threads littering reddit describing the same problem over the years as well. Further, I believe the behavior is more widespread and people simply don’t notice it because rather than fail, the Plex client helpfully converts the audio stream to PCM and sends it on, so people with less complex setups never notice.
Why is there resistance to making a very straightforward change to Plex’s behavior to actually do what Plex’s own UI says it is doing: selecting the Audio Device based on description?
I hadn’t thought to check Reddit. Wow, this does seem to affect more than a few people, and has been going on for at least a year.
here are the Reddit thread links so you can easily see
https://www.reddit.com/r/PleX/comments/qwuskj/plex_htpc_loosing_audio_device_settings/
https://www.reddit.com/r/PleX/comments/vb5b67/why_does_the_audio_device_setting_keep_resetting/
https://www.reddit.com/r/PleX/comments/uxw4z6/plex_desktop_app_losing_audio_device_settings/
1.39.2.3822 Just got pushed to our Plex HTPC.
Didn’t see anything about this in announcements.
What are the changes ?
I had auto update disabled ?
Came through as a power shell update ?
It was a minor release with a very small fix for something internal., there are no public-facing release notes. If you had auto-update disabled then your installation shouldn’t have updated, we can’t override that.
That’s the wrong thing to do. A device which has the name continually changing is fundamentally broken behavior and that is what needs to be fixed.
I agree on a dogmatic level. But on a practical level, this is maddening behavior by Plex. And potentially affects many more people than realize it, since Plex silently falls back to PCM. Especially maddening because other AV apps (eg VLC) do not have the same behavior when installed side by side with Plex. Given that it’s Plex only exhibiting the behavior, I hope that Plex devs might investigate a solution.
It does not seem correct to me that the name changing is indicative of “fundamentally broken” behavior. If the name is so sacrosanct that it changing is “broken”, then why does everyone accept such a change occurring when the driver (often a GPU driver) updates (also effectively wiping out a Plex user’s audio configuration)? The only difference is the frequency of the change, and GPU drivers get updated all the time. Why is it acceptable for a driver update that probably changed absolutely nothing about the functionality of the audio device itself to break the Plex configuration but not acceptable when the change is due to internal driver (or Windows) behavior? Either way, a user’s Plex configuration gets broken–why would Plex not want to make the user’s experience as smooth and easy as possible, regardless of how often it might be needed?
Setting aside the fact that I could find no documentation that Windows views changing the unique identifier for the audio endpoint device as prohibited/broken, mpv is able to accommodate more-desirable behavior itself by taking the description as the audio-device–they don’t seem to think it’s “wrong” and I don’t think Plex should view it that way either.
Thanks for that.
Audio settings were kept intact as expected post-update.
Cheers
