I’m encountering an encoding issue with external SRT subtitles when using the new Android Plex app experience
Subtitles encoded with Windows-1252 (ANSI) are not displayed correctly.
Problem Summary:
New Android Plex app → Garbled subtitles with special characters like ç, ã, é.
Old Android Plex app → Subtitles display fine.
Google TV Plex app → Subtitles display fine.
Plex Web (Chrome on Windows) → Subtitles display fine.
Technical Details:
Subtitle file: .srt encoded in Windows-1252 (ANSI).
When wrongly interpreted as UTF-8, characters like ç, ã, é appear as ��.
Convert your external subtitle files to use the utf-8 character encoding.
It was invented specifically to solve all that historical mess with national code pages.
It’s over 20 years old by now. So it’s about time people start using it.
And yes, you can convert all your files at once.
For free. All you need is some time.
And the argument “but it used to work!” is not valid either. It only used to work in certain app types on certain platforms. It never worked universally.
As time goes on, support for the old national code pages will vanish from more and more platforms and apps. Pretty soon-ish you will not be able to use the old subtitles anymore.
After identifying the issue, I converted my subtitle files to UTF-8 — I’m a developer, so that was straightforward. I completely agree: UTF-8 should be the standard everywhere.
In fact, the last time I had to migrate an app and database to UTF-8 was back in 2013, during a legacy project.
That said, product teams still need to consider the UX side of things. In this case, it wasn’t me who noticed the issue — it was my wife, who has no IT background and doesn’t even know what “encoding” means. She just watched an episode with broken subtitles and got confused.
The reality is: there are still thousands of subtitle files on popular sites using legacy encodings, especially for non-English languages.
If the app can automatically detect encoding (as many apps already do, including Plex apps), it would genuinely improve the experience for regular users — those who just want to press “play” and watch.
So yes, UTF-8 is the future — but gracefully handling the present is what makes a product feel polished and user-friendly.
PS: Thank you for sharing Nikse app. I will take a look
Please remember that not all of your users are TECH nerds. It worked. Full Stop.
You decided that it will not work within your new player in order to release some effort to other tasks? Now, you are asking users to do that task.
Why not dropping AVI support? Why not dropping external subtitle support altogether? People could embed their subtitles for free, too.
Why not let Plex the conversion of that external SRT on run-time?
You were not advertising that your future products will only support UTF-8 subtitles only. Please fix documentation accordingly if this would be the case.
My wife would not even know what you are talking about. Not mentioning that she would have stupid symbols in her subtitles, not knowing that the programming department blames her for this as she’s not solving a problem she never had before and that software could (and had) easily solve for her.
I am sorry to say, noone should work in a customer relations department of any company showing this attitude. Remember: this forum is Plex’ official way of communicating with their user base.
Subtitles which are downloaded by Plex’s own subtitle search are automatically converted to UTF-8.
If you do the subtitle acquisition yourself or delegate it to other software, you better make sure it’s suitably converted. Because the process is sometime not fully automated. The source code page can sometimes not be determined automatically. You have to make certain assumptions which code page(s) it likely contains. And that is different depending on where in the world you are and which language(s) you speak.
I hear there are certain apps which specialize in that sort of thing.
But these are not discussed here.
And then there are certain subtitle repository web sites which “expertly” insert advertisements which are encoded in UTF-8 into subtile files which are encoded with one of the national codepages…
Now try to guess what happens if a fully automated converter trips over such a file.
Plex is already converting incompatible/old audio.
Plex is already converting incompatible/old video.
Plex is already accommodating badly configured network setups with it’s relay etc.
Plex is already accommodating incompatible/old devices, and converts things to work on them.
All of those things could be solved with user effort. But Plex takes care of it. One could even say it’s the point of Plex to some extent.
Some extra food for thought:
Converting subtitles locally would cause Plex to completely re analyze the files, and backup programs etc to do the same, causing quite a lot of extra disk reads and CPU time for the user.
I think it’s kind of obvious that Plex needs to do it’s best to help with this problem, and convert them on the fly, even if it will make mistakes sometimes as you point out.
I don’t think so, because the video files themselves are not changed with my proposed procedure. There are only external subtitle files either added or updated.
The most weird thing about this topic is the fact we are trying to defend something to a forum moderator (in theory, not a Plex employee).
When I discovered the issue, I tried to find a Plex support e-mail or a real support ticket system (like Zendesk) to report to the Plex team. I’ve got a bit frustrate with the fact they don’t have and force us to post this kind of report here.
Then I thought: “ok, let’s post it and after a couple of hours/days an employee will be aware of that and will give me an official position”. But no official reply yet.
I won’t discuss whether that’s a bug or not. For me, as demonstrated in my original post, it’s a bug because it is a regression in comparison to all other Plex apps, including the old Android version. Furthermore, Plex documentation does not mention subtitle encoding.
It’s a paid product from a business, not an open-source project from a couple of maintainers. I expect professional support. That’s the reason I have chosen Plex over Jellyfin.
That means nothing here, essentially, so just get used to it. I’m just thankful it’s not worse than that. It could be a lot worse, honestly. Many of the “paying customers” have already gotten all their money’s worth years ago. I think that’s why that phrase doesn’t really carry a lot of weight around here.
Plex is more of a community, rather than a business transaction. That’s why paying money to Plex is usually thought of as “supporting Plex” rather than a “purchase.”
Well obviously that would only work if the subs are external to begin with.
And if you are considering automating it and putting the fixed sub file outside the file (extracting it) without altering the hash of the file itself, then the sub would effectively be duplicated (Plex sees 2 subs, one internal with bad encoding and one fixed) which would also be problematic.
To try to be a bit productive here, could not PMS do the analysis on its side and tell the client what it should do? Isn’t deinterlacing done this way for example? I mean that PMS uses it’s methods to detect if the file is interlaced, marks it as such, and the clients then deinterlace it?
If so, PMS can use some “advanced” methods to detect the subtitle encoding somehow, mark it as such, and the client only needs to read this.
I personally would think that that would be easier than plenty of tasks PMS performs, and if it can not be performed via a quick analysis, make it be performed during the deep analysis. Is this not possible somehow?
It’s also of note that “voice activity” already causes a full read of the entire file for the sole purpose of extracting the audio track for voice detection. For subs. So in that sense, doing some processing on the subtile itself seems only logical.
Plex is preferring external subtiles over embedded ones, if they have the same language and type. (And if the haven’t seen a manual subtitle selection by the user. But that would disable all automatic track selection anyway.) So at least the automatic selection would continue to work.
If you have embedded subtitles in MKV files, these should already be in UTF-8. If they’re not, then the file is violating the MKV spec.
It’s not even detecting German language, so I went to Plex documentation and checked naming conventions for that SRT file. For me, this means, that the content of the SRT file does not even gets analyzed, but for now, that’s okay.
After adding a “.de.forced” tag to the name, here’s what Plex serves:
I just posted another thread regarding the same issue and then found this one.
Manually converting thousands of external subtitles for a not techy person is backpain at the very least.
Plex is breaking a working functionality for years and blame users for their “WRONG” encoding. How pitty is that…
Just fix your sh*t, Plex.
I already dumped the Plex app for Samsung TV and use RBPi with Kodi. What should I do to be able to play my media on my Android devices with somethin that simle like correctly recognized encodings which MANY softwares do!?
Dear @OttoKerner … I’ve seen that you did not respond to my question. Since I am using subtitles regularly, I really would appreciate if you could afford the time to answer my question in the cited post.
This is not about the order in which the subs are listed in the manual selection dropdown.
This is about whether the external or the internal subtitle gets activated automatically, if the user language preferences are set accordingly (and the user has not yet selected a subtitle manually).
Problem Summary:
Technical Details:
Attached Evidence:
Subtitle File for Reproduction
Expected Behavior:
Additional Info:
