Ok. So in essence, the Fire Stick’s main audio settings are only useful when passthrough is off, correct? If passthrough is enabled, the “codec capability” that PMS checks lies on the TV/receiver wherever the Fire Stick is connected to. I hope I got that right.
If I got what I stated above correctly, why then did you suggest earlier in this thread to disable EAC3/DD+ in the Fire Stick’s main audio settings to get around the EAC3 transcode problem. What would’ve that accomplished? If he disabled DD+, it will just tell PMS to transcode TrueHD to EAC3 anyway which was already what’s happening when he had DD+ enabled in the Fire Stick main audio settings.
Not quite. The Plex app checks both the device it’s running (Fire TV) on and what it’s connected to (TV/AVR), I forget what you had. So in your case, both indicated EAC3 was supported, so the app used EAC3. This is breaking somewhere. Not sure if it’s the Fire TV or the TV/AVR. When you play some other multi-channel codec like TrueHD, which isn’t supported by the Fire TV, PMS will then transcode the audio to a supported one EAC3, which again is causing issues.
By turning off EAC3 support in the Fire TV, this tells the Plex app, don’t use EAC3. So the app will then pick another multi-channel format that is support by both and use that (AC3 or AAC).
I have a TV (at least for now until I get a receiver soon). So what will PMS do in these different scenarios? Does the codec need to be supported by both device and TV/receiver for it to be “compatible” end-to-end?
FireStick EAC3 = off, TV EAC3 supported
FireStick EAC3 = on, TV EAC3 supported
FireStick EAC3 = off, TV EAC3 not supported
FireStick EAC3 = on, TV EAC3 not supported
What do you mean it’s breaking somewhere? Are you pertaining to the EAC3 issue I had on the other thread which was already fixed by recreating the Codecs folder? Isn’t that the root cause of the issue?
That’s what I thought. By turning off EAC3 in the FireTV, my expectation is for the Plex app to pick a compatible audio stream that’s available in the media file. This did not happen. No matter what setting I choose in the Fire Stick’s main audio settings, the Plex app always chooses audio stream #1 which is usually the TrueHD stream.
Scenarios
1 - No EAC3, PMS will try to transcode to another supported codec
2 - direct play, this is what’s happening now and not working
3 - same as 1
4 - same as 1
Oh sorry. I did get your issues mixed up. You kept asking about EAC3, which was mainly for your other issue.
Here, the file wasn’t working correctly. I couldn’t tell what’s wrong with the file, but something was not right. Your second sample doesn’t help since it was processed and not the original file. This could hide the underlying issue.
Another possibility might just be the size of your files. Your Amazing Spiderman file is 67 Mbps. The WiFi on the Fire TV devices are not great and your file just might be too much for it to handle.
Plex will only choose another audio track if can be direct played. If something has to be done like a transcode, it will typically pick the first track.
Are those all true whether audio passthrough is enabled or not? All along, my understanding for passthrough is that with it disabled it makes the playback device (Fire Stick) responsible for all codec support matching/decoding. And with it enabled, it passes that responsibility to either the TV or receiver.
Yeah, sorry for the mix up. There are two main issues in this thread:
Media that are not playing at all (stuck at loading when you play them) when the TrueHD stream is used. Ref: your pots here. This is the one I think is related to my other EAC3 thread as the EAC3 transcoder was failing due to a corrupted Codecs folder after I migrated from a docker container to a native Linux PMS install.
Buffering when playing media files. This one is when you were checking those Ad Astra samples I was uploading here. I’m still not sure if this is caused by the Ad Astra file itself but like I said I can play the whole video just fine when it is direct playing with my Nvidia Shield. I don’t think it’s a corrupted file.
The reason why upgraded to using a Fire Stick 4K device as compared to just using the Plex app from the LG TV content store is that the wifi chip in the Fire Stick is way better than what we have with modern TV’s nowadays even though they’re both 802.11ac. I did an iperf test for the Fire Stick device connected to my Ubiquiti AC AP’s and the reach the 250Mbps down/up mark which is what I was expecting. The TV wifi module can only reach around 120Mbps or so. So I know it’s not because of bandwidth. With the EAC3 Codecs folder issue fixed, I can play the Amazing Spiderman without any issues now.
This is still what’s happening and I would really like this to be fixed. If this was really the case, then Plex shouldn’t be picking the TrueHD tracks in media files, right? My FireStick and my TV both support EAC3 but not TrueHD. So shouldn’t Plex pick the EAC3 or even just AC3 track? I never saw that happen for all my TrueHD files.
Passthrough means is this device allowed to send the audio as-is. Enabling passthrough then allows the supported codecs to flow to the next device. The codecs listed by the manufacturer as being support often do not indicate if it is for passthrough, on device, or both. The Fire TV devices only support AC3, EAC3, and PCM for passthrough. The Fire TV can decode some codecs itself into PCM and pass that through. It cannot output any other type of codec. So if you want anything other than PCM, the Plex app has to transcode unsupported codecs to AC3 or EAC3.
Ok, that was the codec issue.
That’s the thing about corrupted files, they don’t always cause problems.
True, but keep in mind that the device sits behind your TV, near a bunch of electronic stuff. There is a high chance for interference. That’s why they come with that little extension. I wish they would have provided a longer one.
The Plex app does not have a concept of a preferred audio codec, but more of a best compatible.
In your example of TrueHD 7.1 to EAC3, the Fire TV supports 7.1 audio so the Plexapp choose the 7.1 track to give you the most channels. So it’s transcoding to EAC3 7.1.
True, but keep in mind that the device sits behind your TV, near a bunch of electronic stuff. There is a high chance for interference. That’s why they come with that little extension. I wish they would have provided a longer one.
You’re absolutely right. The included extender in the Fire Stick is very short indeed. That’s why I already ordered a longer extender for this very purpose. Then again, I have Ubiquiti AP’s per room so signal strength is really strong with 5GHZ AC.
If the Nvidia Shield isn’t expensive, I would be more than happy to use them on all my TV’s. All media players should have at a least a Gigabit ethernet interface nowadays.
Is this true for when I set the Fire Stick to “only stereo” too? With this setting, the Fire TV reports to Plex that it only supports Stereo. If the media doesn’t have a stereo stream, will Plex still choose the first track? If it does, should it choose the stereo track by default? I can try to find a media with both TrueHD and Stereo streams to test.
Setting the audio for the Fire TV to stereo means that the device will only output stereo to what it is connected to. It can still accept some multi-channel codecs as input and will then decode it locally to output stereo PCM.
Ok. So if I disable EAC3 in the Fire TV by selecting “always dolby digital”, will Plex still choose the TrueHD stream because the best match is still any 7-channel stream?
It depends on what the app has detected as being supported by your system. By setting the output to Dolby Digital, this indicates the maximum channels as 5.1. If your TrueHD has a 5.1 AC3 core, then the app will likely choose the TrueHD track and just use the 5.1 core.
No. TrueHd is basically AC3 with extra info. Since the Fire TV supports AC3, there is a high chance it will get picked. It may be possible if you set the Fire Stick to only use stereo, then it may pick a stereo track or something else easier to transcode. But the Fire Stick supports decoding only the stereo portion of AC3 so it may still pick that. Not using AC3 and a Fire Stick isn’t really a good option.
So basically, between 1/12/2021 12:25PM to 12:33PM I played this media file:
This Is Us (2016) - S01E02 - The Big Three [WEBRip-1080p][8bit][x264][EAC3 5.1]-KiNGS.mkv
This is a simple 1080p mkv file but the first time it gets played it gets hw transcoded to a 1080p file too. If I remember correctly, Tautulli showed MPEG4 -> MKV conversion or somewhere along those lines. But then if you stop the file, wait for a few seconds and replay it, it direct plays just fine. So obviously, direct play is supported but why doesn’t it happen the first time around?
I actually played this file a couple of times too last night (1/11/2021 around 9PM or so IIRC) and the same behavior happened. I thought it was a one-off issue but it looks like it is reproducible.
Also, given that it is hw transcoding why was it buffering? A 1080p to 1080p transcode is very easy to do, no? And I mean it’s even hw transcoding so why can’t it handle that very easy transcode? I have subtitles enabled, yes, but still that’s still very easy to transcode. No HDR to SDR conversion or anything. No 4K involved.
Does your drive with the media go to sleep? I’ve seen it where if the drive is asleep, the app can’t identify the codecs quick enough so it has PMS transcode to be safe. The second time, the drive is available, so it can identify the codecs and playback correctly.
No, they don’t. I make sure that my NAS drives don’t do this because it’s detrimental to the drive’s health. Also, this problem goes away if I choose to use a different SRT subtitle or use the PGS subtitle for the same media files. So I know it’s a subtitle problem. I also see in the debug logs where it says “subtitle is not supported, so transcoding is needed” or somewhere along those lines.
False alarm. Removing the tags on the “external SRT” files did not fix the issue. This is what I see in the logs:
[Transcode] MDE: Selected protocol hls; container: mpegts
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: analyzing media item 11592
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: E8 - Pilgrim Rick: Direct Play is disabled
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: E8 - Pilgrim Rick: media must be transcoded in order to use the hls protocol
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: E8 - Pilgrim Rick: selected subtitle cannot be converted to a compatible format, burning into video stream
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: E8 - Pilgrim Rick: avoiding video remux due to burned subtitle stream
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: E8 - Pilgrim Rick: no remuxable profile found, so video stream will be transcoded
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] MDE: Cannot direct stream video stream due to profile or setting limitations
Jan 14, 2021 22:35:47.462 [0x7f1e07fff700] DEBUG - [Transcode] Codecs: testing h264 (decoder) with hwdevice vaapi
Jan 14, 2021 22:35:47.463 [0x7f1e07fff700] DEBUG - [Transcode] Codecs: hardware transcoding: testing API vaapi
Then if I stop the playback and change the subtitles to the “SRT” option or “PGS” option, it fixes the problem. What is going on here? I really don’t have a clue.
