Non-UTF-8 (ANSI) subtitles don't work

[brothom 177]

I just encountered a strange issue where my Samsung TV nor the Emby web app couldn't play an `.srt` file. 

After searching and searching I finally noticed that the subtitle was saved as CRLF instead of UTF-8.
Quickly opening the file in notepad and saving it with UTF-8 encoding did the trick.

My question is: is there a way to fix this or at least give mention of the subtitle not being able to be parsed?

Edited October 2, 2025 by brothom

[Luke 42077]

Hi, couldn't play how?

[brothom 177]

2 minutes ago, Luke said:

Hi, couldn't play how?

Well I could select the subs themselves, but they just wouldn't "show up" during actual playback eventhough that sub was clearly selected within the player via the dropdown and via the media detail page. 

For whatever reason it just wouldn't display the CLRF encoded file, but displays UTF-8 just fine.

[Luke 42077]

When they are not utf8 the server will try and detect the encoding.

[brothom 177]

7 minutes ago, Luke said:

When they are not utf8 the server will try and detect the encoding.

That's strange because the CLRF encoded subs were found, and I could select them, but they just wouldn't show up in my Emby web app or on my Samsung Smart TV until I encoded it to UTF-8.

[Lessaj 467]

There isn't really a relation between the line break types and the encoding in the way that you're implying it, or at least based on my understanding of them it should not really impact ffmpeg from reading/display them properly (or direct play for that matter) due to way an SRT is laid out, however there could be some display issues with them between operating systems especially in command line editors like vi. Changing between the line break types mostly impacts the data at the hex level for how it tells the text processor to display it, in the case of Windows (mostly Notepad since it's a pretty basic editor) it uses carriage return line feed (0x0D followed by 0x0A).

UTF-8 is a character encoding standard which has variable byte sizes depending on the character, and covers a very large range of characters from multiple alphabets down to symbols and emojis.

Are you sure they weren't encoded in another format, like ANSI? Or UTF-8 BOM? I have seen issues with scripts not working or running properly, and even being unable to read a file because it was encoded with UTF-8 BOM which added some extra characters at the very beginning that you can only see with a hex dump.

I suppose it's possible if it was LF or CR instead of CRLF that the end device would have trouble displaying it, but again it's still separate from the encoding.

[brothom 177]

11 minutes ago, Lessaj said:

I suppose it's possible if it was LF or CR instead of CRLF that the end device would have trouble displaying it, but again it's still separate from the encoding.

Ah poopie I think you're right. The file was encoded as ANSI. They're all CLRF. @Lukeapoligies for the confusion.

I encoded the srt back to ANSI and now it's no longer being display as before.
I'll change the title of this thread. Sorry guys.

So there's an issue with .srt's, when they're encoded as ANSI instead of UTF-8.

Edited October 2, 2025 by brothom

[Luke 42077]

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

[brothom 177]

8 hours ago, Luke said:

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

I'll add these steps to reproduce:

1. Find a piece of media within your Emby installation that has an existing SRT file
2. Open the SRT file with your text-editor (Notepad)
3. Save the SRT file with encoding ANSI

4. Go to Emby
5. Look up the media from step 1 play it by selecting the ANSI-subtitles
No subtitles are shown, despite they're selected.

I've added two subtitle files in the attachments.
One SRT is ANSI and the other SRT is UTF-8.
On my system, when ANSI is selected, it's never displayed.
The UTF-8 variant works flawlessly.

example-utf8.nl.srt example-ansi.nl.srt

[Luke 42077]

OK we'll take a look at it. Thanks.

[Luke 42077]

This should be resolved on the beta channel.

[brothom 177]

4 hours ago, Luke said:

This should be resolved on the beta channel.

Will check. Thanks for the update.