Server Version#: 1.32.5.7349
Player Version#: 5.1.2
My Plex app on my LG TV worked fine with Plex running on my NAS up until the server update 1.32.5.7349 (albeit with a subtitle issue that was addressed with the newest update). When I updated to this version, my app on my PC runs fine still, but the one on my TV just constantly buffers. Both are running on the same local network as the server. I reverted back to the previous update, because it was impossible to watch anything. That seemed to work, but the next update (1.32.6.7371) came out and I updated to it and it is back to buffering constantly.
This is unfortunately a media curation problem -AND/OR- subtitle settings in the app (Subtitles set to always burn instead of auto).
The media contains subtitles and the LG cannot render them without burning into the image.
Aug 09, 2023 20:49:46.407 [139631787699000] DEBUG - [Req#14c13/Transcode] [FFMPEG] - Decode context initialised: 0x16/0x10000000.
Aug 09, 2023 20:49:46.407 [139631787699000] DEBUG - [Req#14c13/Transcode] [FFMPEG] - Param buffer (type 0, 604 bytes) is 0.
Aug 09, 2023 20:49:46.407 [139631787699000] DEBUG - [Req#14c13/Transcode] [FFMPEG] - Slice 0 param buffer (264 bytes) is 0x1.
Aug 09, 2023 20:49:46.407 [139631787699000] DEBUG - [Req#14c13/Transcode] [FFMPEG] - Slice 0 data buffer (47 bytes) is 0x2.
Aug 09, 2023 20:49:46.407 [139631787699000] DEBUG - [Req#14c13/Transcode] [FFMPEG] - Decode to surface 0x13.
Aug 09, 2023 20:49:46.408 [139631787699000] DEBUG - [Req#14c13/Transcode] Codecs: dummy-frame test succeeded
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: Selected protocol hls; container: mpegts
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: analyzing media item 849
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: E262 - Episode 262: Direct Play is disabled
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: E262 - Episode 262: media must be transcoded in order to use the hls protocol
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: E262 - Episode 262: selected subtitle cannot be converted to a compatible format, burning into video stream
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: E262 - Episode 262: Direct Streaming is disabled, so video stream will be transcoded
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: E262 - Episode 262: no remuxable profile found, so video stream will be transcoded
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] MDE: Cannot direct stream video stream due to profile or setting limitations
Aug 09, 2023 20:49:46.422 [139631787699000] DEBUG - [Req#14c13/Transcode] Codecs: testing hevc (decoder) with hwdevice vaapi
When invoking subtitle burning on a Synology, the CPU is used.
This is where the Synology fails us.
The sequence we get is:
HW decode
CPU burn subtitle into each frame as it’s decoded
HW encode the resultant frame
Send to LG TV
The J3455 isn’t fast enough to keep up with real-time demand. Sad but true.
Here’s the decision from PMS & LG app negotiating the best way to play (not good)
Thanks for the quick reply. I was able to confirm that subtitles are causing this. When I turned them off, the video played properly. However, I don’t think it is only that the server can’t handle it. My reasoning for saying that is that I’ve been using this for 3 years with no issues until April of this year. Back in April, an update came out that messed up the ability to render ASS subtitles. It would still play anything with subtitles, but the spacing and size would be slightly off. I dealt with that until update 1.32.5.7349. That was when this buffering issue started. At that point, I reverted all the way back to 1.29.2.6364 and everything worked great again. I saw that his newest update fixed the ASS rendering issue so I upgraded to it and that was when the buffer issue started again, so something in these last 2 updates changed it so it can no longer keep up with subtitles that aren’t burnt in.
Between 1.29.2.6364 and now, MANY things have happened.
The transcoder was updated (major update) in 1.32.0
The Intel Media Driver was updated. VaapiDriver="i965" is obsolete for most CPUs (J3xxx and J4xxx) and should be removed.
There was a lot of other regressions on J3xxx and J4xxx CPUs
J3xxx CPUs have been fixed
J4xxx CPUs are being fixed now.
ASS subtitles have always been inefficient and CPU-heavy in PMS.
The transcoder engineer told me that she wanted to take time and rewrite it but never got a chance to.
SRT subtitles have always been the most efficient (most commonly accepted by players too) and work as expected.
Might you, as an experiment, convert the ASS subtitles → SRT to confirm whether or not the problem you’re having is because of the ASS subtitle conversion ?
I see. So I ran a few tests. If the video uses ASS, it buffers unless I turn them off. If it is using SRT, it plays fine with them on. I tested out a mkv file with subs included within it and it buffered, but it is an anime file so theres a good chance that the subs are ASS.
SRT may be the easier one for the hardware to display, but they always display at the bottom of the screen. ASS allows for changing the positioning of the subtitles, so if theres some text, the subs can be displayed over it giving the appearance of it written in English, or even just if there is something going on at the bottom of the screen that the subtitles would block out. For normal movies and TV shows, I just use SRT, but for anime, I always use ASS. I think that is the same for most people based on what I’ve read online.
Is there a way to fix this so that ASS can be processed without burning it in, or should I accept that I’ve had my NAS for 3.5 years and its lived a good life, but now it’s time to upgrade?
ASS subtitles are still text based. SSA, ASS, and SRT are all text based.
The problem in PMS is that they weren’t handled very efficiently and, somewhere along the way, the decision to burn-in was made instead of fixing the subtitle conversion.
I don’t agree with that decision. I have a rather ‘honking big’ Xeon and Nvidia PMS server which is also limited with burning in subtitles.
There are enough limits on subtitles as it is. VOBSUB, DVDRIP, and PGS are 3 image formats which must be burned in period. FFMPEG doesn’t handle those in HW.
I know some folks using PMS 1.25.9 and doing really well with it – no bugs / errors.
They have fewer ‘bells & whistles’ but the core engine works perfect for them.
I will ask the engineering team about this and see what reaction I get.
I might be able to get them to schedule time and correct the ASS and SSA issues.
(I know Anime is a small segment of the video spectrum but it is a popular one with certain age groups so it deserves its due attention to play correctly given ASS subtitles are extremely common with anime
In the interim, will PMS 1.29.2.6364 work for you?
Yeah, any version prior to 1.32 seems to work fine. 1.29.2.6364 just happens to be the one I was able to find so that is the one I have been using. I will roll it back to that version for the time being and keep an eye on the release notes. Thanks for all your help with this.
