Server Version#: 1.43.2.10687
Player Version#: 5.94.1
Hello,
I have a problem with audio track selection. This problem occurs only on WebOs, when I use iPad app, all works perfectly.
I have a file with French audio track and English audio track. When I select French the audio I hear is English and vice versa.
Is there anything I can do to have correct audio track selection?
Thx in advance
Hello,
Iâm having exactly the same problem on WebOS as well.
Best regards
Iâm having the exact same issue since a few days.
I found that by disabling the support of EAC3 in the settings of Plex kind-of fix it, but it force the Plex server to transcode the EAC3 to AAC, which is not ideal.
I donât know how you have find this, but thx, itâs working before eventually a patch.
Thanks for reply 
Well.. the latest version for Plex on my TV is from 2024, I donât expect a patch anytime soon, unless it can be fix server-side.
I found this by trying everything. I found that AC3 doesnât have this issue, only EAC3
Edit : But it seems to break AAC audio. With that tricks, when there is an AAC and EAC3 audio, it will only plays the EAC3, French/English will both play English
Edit 2 : Disabling âallow direct playâ in the settings seems to fix it more. I had issues qui some type of audio that would any play 1 language
I instrumented this endâtoâend and found the actual root cause â in the webOS appâs own trackâselection code, down to the exact function. Sharing the full chain because it explains every symptom in this thread, including why it looks random across files.
Setup: rooted LG (2019, webOS 4.5). I attached Chrome DevTools to the live Plex app (itâs the app.plex.tv/tv-v5-webos web build running in webOS Chromium) and simultaneously tailed LGâs mediaâpipeline log (starfish-media-pipeline), so I can see the exact track each layer selects.
Repro file: 2 audio tracks â #1 Russian AC3 5.1, #2 English EâAC3 5.1 (Atmos) (an Amazon WEBâDL). Direct Play. Selecting English plays Russian and viceâversa.
LGâs pipeline maps track index â audio faithfully (Atmos flag as ground truth, since only the English track is Atmos):
SELECT_TRACK audio index 0 â audio path: NONE (Russian)
SELECT_TRACK audio index 1 â audio path: ATMOS (English)
The HTML audioTracks list is also correctly ordered: idx0 {language:"ru"}, idx1 {language:"en"}.
But with English selected in Plexâs menu, the app enables audioTracks[0] (Russian). Forceâenabling audioTracks[1] from the DevTools console makes the pipeline switch instantly (SELECT_TRACK index 1) and the correct language plays. So the player is innocent â the app hands it the wrong index.
HTMLPlayer._selectAudioTrack (in packages_app_components_player_HTMLPlayer_tsx.js) delegates to a webOSâspecific helper injected from getAppConfig_ts.js. Deobfuscated:
function getSelectedAudioStreamIndex(serverStreams, elementTracks) {
// (filters truehd/dca/pcm when list lengths differ â not relevant here)
const r = serverStreams.findIndex(s => s.selected);
// sanity check: per-position language match, EXACT string equality
const ok = serverStreams.every((s, i) => {
const elemLang = elementTracks[i].language;
if (!(s.languageCode || (elemLang && elemLang !== "und"))) return true;
return s.languageCode === elemLang
|| (!!s.languageCode && (s.languageTag || isoMap[s.languageCode]) === elemLang);
});
return ok ? r : elementTracks.length - r - 1; // â check fails â MIRROR the index
}
If any position fails the language comparison, the app assumes the elementâs track list is reversed (presumably a workaround for some old webOS firmware) and enables the mirrored entry.
My fileâs English track carries the Matroska LanguageIETF tag en-US (typical of Amazon WEBâDLs), so PMS reports languageTag: "en-US" â but the webOS media element normalizes audioTracks[i].language to "en". The exactâequality check fails on that position, the helper takes the âreversedâ branch, and with English selected (r = 1) it returns 2 â 1 â 1 = 0 â Russian. Selecting Russian returns 1 â English. A perfect swap, both ways.
I replayed this exact logic in the live page against the real server metadata: langCheckPassed: false, indexAppWouldEnable: 0. Matches the observed behavior bitâforâbit. (The helper even logs "Unexpected number of audio tracks available on media element" in a related path â searchable in the source.)
It is not about codecs. I tested three multiâtrack files, all Direct Play:
| File | Audio | Language tags (PMS languageTag vs element) |
Result |
|---|---|---|---|
| AC3 rus + EâAC3 eng (Atmos) | mixed | ru/ru â, en-US/en â |
swapped |
| AC3 rus + EâAC3 eng (Atmos), different release | mixed | ru/ru â, en/en â |
correct |
| AC3 rus + AC3 rus + EâAC3 eng | mixed | all â | correct |
Same codec mix, opposite outcomes â the only difference is the containerâs IETF language tag. The trigger is: any DirectâPlayed multiâtrack file where one streamâs BCPâ47 tag doesnât exactly equal the elementâs normalized language (en-US vs en, regional variants, missing/und mismatches). Thatâs why this bug looks fileâdependent and random across release groups, and why it survives reinstalls and different PMS versions.
tracks[0].enabled = true unconditionally). Same reason the desktop web client is unaffected.mkvpropedit file.mkv --edit track:a2 --set language-ietf=en (seconds, no remux) makes the check pass and the correct track play.The fix is one line in the webOS client: compare primary subtags (languageTag.split("-")[0]) instead of exact strings â or better, drop the guessâreversal heuristic and match element tracks by language directly. The audioStreamID sent to the server is already correct; only the local audioTracks.enabled mapping is mirrored. Relevant because the webOS app has been frozen for many of us, and en-USâtagged WEBâDLs are extremely common.
Happy to share the DevTools dumps, pipeline SELECT_TRACK logs, and PMS stream JSON if it helps repro.
Nice find! Letâs hope something from Plex staff can read that and fix it for the LG WebOS Plex Client!
Because the allow direct play is starting to create some otheer issues, like some Plex buffering and then crashing
With your investigation, do you know if the .js you deobfuscated is âbuilt-inâ the WebOS Plex client or is it downloaded from a remote server?
This could explain as to why, since the last update is from 2024, the behavior changed recently.
Ok, itâs the upgrade from 1.43.1.10611-1e34174b1 to 1.43.2.10687-563d026ea that break it.
Here is the test I made, I create a new Plex installation (new account, everything brand new), from 1.43.1
services:
plex:
image: plexinc/pms-docker:1.43.1.10611-1e34174b1
container_name: plex
network_mode: host
pull_policy: if_not_present
environment:
- PLEX_UID=1000
- PLEX_GID=1000
- VERSION=latest
- TZ=America/Montreal
- PLEX_CLAIM="THE_CLAIN"
- HOME=/config
- CHANGE_CONFIG_DIR_OWNERSHIP=true
- ADVERTISE_IP="http://192.168.1.xxx:32400/"
volumes:
- "/app/plex/config:/config"
- "/app/plex/data:/data"
tmpfs:
- /transcode:size=8G,mode=1777,uid=1000,gid=1000
restart: unless-stopped
I added one problematic TV Show.
Connected the same LG TV to that new Plex server. The audio was fine, it played in french, no issue.
I exited from the TV the Plex Application. Stopped Plex server, upgraded to 1.43.2.10687-563d026ea.
Relaunched the application on the LG, now the audio is in english instead of french.
I tried rollbacking that new installation to 1.43.1 and the issue remains. So itâs an update to the data in the database the cause the issue.
Ok I found it, the data is updated in the database from âfrâ to âfr-FRâ.
The data in 1.43.1 :
The data in 1.43.2 :
So the WebOS is unable to found the right audio track.
From what I found, the WebOS Plex client is mostly not a fully native app. On LG WebOS, itâs essentially a web app running inside WebOSâs built-in browser runtime, which is basically an older Chromium-based environment.
The native part is fairly limited and mainly handles playback through LGâs native video player. The rest of the UI logic is basically the Plex web app, which can be loaded and updated remotely.
So yes, the deobfuscated JavaScript appears to be part of that web layer rather than something permanently baked into the native client binary. That would absolutely explain why the behavior changed recently even though the last store update was back in 2024.
In fact, you can open it from anywhere: https://app.plex.tv/tv-v5-webos#/
I hope so too. I tried to show them the exact place where it needs to be fixed, so it should really be just a couple of lines of code.
Ok so if itâs only a webview for an app, it should be pretty simple for them to fix that since it wouldnât required updating the app itself
Same problem here! When I play a mkv with a TrueHD with Atmos track, Plex got all the audio tracks wrong, a strange thing for me it play the stereo from the French track (AAC) and the surround sound from the English track (TrueHD) very strange behaviour!
Really hope there will be a fix soon!
