Research Summary

The likely failure is not missing audio in the file. It is an E-AC-3 compatibility or transcode-path problem in the LG playback chain.

Bottom line

The file at /mnt/atlas/TV/The Boys/Season 5/The.Boys.S05E01.REPACK.1080p.WEB.h264-ETHEL.mkv contains exactly one default audio track, and that track is eac3 5.1 at 48000 Hz. My local probe found no AAC stereo fallback and no AC3 fallback. I also decoded the first 15 seconds of that audio track locally with ffmpeg and got no errors, so this does not look like a silent or corrupt MKV.

The most likely explanation for "video plays but there is no audio on the LG OLED" is that your LG playback path cannot actually use that eac3 track in the way this title is being delivered. On LG/Plex setups, that usually means one of three things:

the TV app or the attached sound system cannot really handle eac3 for this playback path even if the UI suggests it can,
Plex is trying to transcode the unsupported audio and that transcode path is failing,
the LG audio output mode or ARC/eARC chain only works for AC3 on this setup, leaving an eac3-only file silent.

What I verified locally

The file probe shows:

video: h264 High, 1920x800
audio: eac3 (ATSC A/52B (AC-3, E-AC-3)), 6 channels, default track
container: matroska
size: 4500809272 bytes
duration: 3823.648 seconds

Local evidence source: file:///home/brian/code/pi-mono-bg-task/worktrees/bg-glacial-onyxhound-research-task-deep-tier-topic/.research-runs/please-investigate-why-season-5-episode-1-of-the/ffprobe.json

I also ran a local decode test of the first 15 seconds of the audio stream with ffmpeg and it completed without errors.

That matters because it narrows the problem from "bad file" to "bad playback compatibility or bad transcode path".

Why the LG/Plex path is the main suspect

Plex's own Smart TV support page says: "Unsupported audio formats in video will have the audio automatically transcoded to either AAC or AC3 (Dolby Digital) as appropriate by the Plex Media Server" and also warns: "If you enable one of these settings but your device/setup doesn't actually support it, you'll typically experience silence or strange audio playback."

Source URL: https://support.plex.tv/articles/203810286-what-media-formats-are-supported/

That warning lines up almost exactly with your symptom: picture is present, but the audio path is not actually working for the codec the file provides.

The file has only one shot at audio, and it is E-AC-3

Because this MKV has one default audio stream and it is eac3 5.1, there is no simple stereo fallback inside the file. If the LG app, ARC chain, or soundbar cannot decode or accept that stream, the player must transcode it correctly. If it does not, you get silent playback.

Your machine already has E-AC-3 transcode failures in Plex logs

The strongest environment-specific clue is in the Plex logs available on this machine. In Plex Transcoder Statistics.4.log, Plex recorded sourceAudioCodec="eac3" and audioDecision="transcode". In Plex Media Server.3.log, the matching transcode path failed with could not set input type (MF_E_INVALIDMEDIATYPE) and then Failed to transcode file (1) on an E-AC-3 title.

Local evidence source: file:///home/brian/media-server/plex-config/Logs/Plex Transcoder Statistics.4.log Local evidence source: file:///home/brian/media-server/plex-config/Logs/Plex Media Server.3.log

That does not prove the same failure occurred on this exact episode, but it does prove your environment has a real history of Plex failing while trying to transcode eac3 audio. If The.Boys.S05E01...mkv needs audio transcoding on the LG path, that existing weakness is a very plausible reason you get video with no sound.

The web evidence matches that pattern

In a Plex forum report for LG WebOS 5.93.2, one user wrote: "I have an older soundbar only supporting Dolby Digital (AC3) and DTS connected with ARC" and "Movies with Dolby Digital start without any problem." Non-AC3 content failed in that setup.

Source URL: https://forums.plex.tv/t/plex-for-lg-does-not-transcode-non-supported-audio-format-exits-with-unexpected-error-message/932782

In another LG webOS Plex thread, the report says the TV had been able to direct play files "as long as the audio codecs have been AAC/AC3/E-AC3" and then started failing in certain MKV/direct play situations.

Source URL: https://forums.plex.tv/t/lg-webos-direct-play-issues-mkv-containers-converting-while-video-and-audio-direct-stream/932665

Those two reports matter together:

they show LG webOS playback is very sensitive to the exact audio codec and delivery path,
they show eac3 can be fine in some chains and broken in others,
they show that when the fallback transcode path breaks, users end up with the kind of failure you are seeing.

This is not just a Plex quirk; the client codec path has to match the file

Jellyfin's codec support docs summarize the same underlying rule: "The goal is to Direct Play all media. This means the container, video, audio and subtitles are all compatible with the client." They also say: "If the media is incompatible for any reason, Jellyfin will use FFmpeg to convert the media to a format that the client can process."

Source URL: https://jellyfin.org/docs/general/clients/codec-support/

That statement is generic but important. Your file is only safe if the client can truly consume eac3, or if the server can successfully convert it. Right now the local evidence points to a chain where one of those two requirements is not being met.

Another LG app report shows silent audio can happen even when the app thinks the file is compatible

A Jellyfin webOS issue on an LG CX OLED with a Sonos ARC reports audio being "inaudible" for certain codecs even while the server says the file is "entirely compatible with this client" and "receiving the file without modifications."

Source URL: https://github.com/jellyfin/jellyfin-webos/issues/129

That is useful because it shows the failure mode is not theoretical: the smart-TV app can believe compatibility is fine while the real output path is still silent.

Most likely root cause ranking

eac3 is the only audio track in the file, and your LG plus sound-output path does not actually handle that stream end-to-end.
Plex is attempting to transcode unsupported eac3 audio for the LG client and that transcode path is failing, which matches the local MF_E_INVALIDMEDIATYPE evidence.
Less likely: the file itself is broken. The local decode test argues against this.

Fastest ways to confirm

In the LG Plex app, check whether this title is Direct Play, Direct Stream, or Transcode during playback. If audio is being transcoded, that strongly supports the local Plex-log theory.
Temporarily switch the TV audio output from ARC/eARC passthrough to TV speakers or PCM. If audio suddenly appears, the blocker is the external audio chain, not the MKV.
Play the same file on a non-LG Plex client that is known to decode E-AC-3 reliably. If audio works there, the file is fine and the LG path is the issue.
Add or generate an AC3 or AAC fallback track for this episode. If the LG then plays sound immediately, the diagnosis is confirmed.

Practical fix

The most robust fix is to give this file a more compatible audio path:

remux or transcode the eac3 track to ac3 5.1 or aac stereo,
keep the existing video untouched,
optionally keep the original eac3 track too, but add an AC3 or AAC fallback and make the fallback selectable on the LG.

If you want the least fragile setup for LG smart-TV playback, AC3 and AAC are safer than relying on an eac3-only track with no fallback.