External SRT→WebVTT conversion omits hour component below 60 minutes, breaks native iOS subtitle rendering

[jpercam 0]

Emby Server version: 4.9.5.0 (stable)

Client: Emby for iOS 2.2.56 (iPhone, iOS 26.5)

Description: When playing a video with an external .srt subtitle file via HLS (SubtitleMethod=Hls), the server-generated WebVTT omits the hour component for any timestamp under 60 minutes, using MM:SS.mmm instead of HH:MM:SS.mmm. Once the timestamp crosses the 60-minute mark, the server correctly switches to the full HH:MM:SS.mmm format. This inconsistent formatting appears to break subtitle rendering on Emby for iOS (native AVPlayer-based renderer), which requires the hour component to always be present, even when zero. Steps to reproduce: 1. Add an external .srt subtitle next to a video in a movies_vo-style library (e.g. Movie (Year).spa.srt). 2. Play the video in Emby for iOS with that external subtitle track selected. 3. Subtitles fail to render for the entire first hour of the video; they start appearing correctly only after the 01:00:00 mark. 4. Fetch the generated VTT directly to confirm the format switch: curl "http://SERVER:8096/emby/Videos/{itemId}/{mediaSourceId}/Subtitles/{index}/Stream.vtt?api_key=API_KEY" Timestamps before 60 minutes: 00:01.523 --> 00:05.005 Timestamps after 60 minutes: 01:00:00.248 --> 01:00:02.686

 

Additional notes:

- The same video's embedded SDH subtitle track (also SubRip) renders correctly in the same app/session — the issue is specific to the external-subtitle-to-VTT conversion path, not to iOS's WebVTT support in general. - Source .srt file uses standard HH:MM:SS,mmm format throughout (verified before upload); the server discards the hour component during its own conversion, so the issue is not caused by malformed source timestamps. - Playing the same file/subtitle in a desktop browser (Emby Web 4.9.5.0) works correctly, since the browser's own subtitle renderer is presumably more lenient about the WebVTT timestamp format than AVPlayer. Happy to provide the full ffmpeg transcode log or additional test files if useful.

Attaching the full ffmpeg transcode log for this session, as requested in the reporting guidelines. Let me know if any additional information would help.

ffmpeg-transcode-race-glory.txt

Edited 48 minutes ago by jpercam

[Abobader 3515]

Hello jpercam,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team