Jump to content

SRT subtitles lag by a few seconds in LG TV app nd Web player compared to iOS and tvOS


ChrisJ60

Recommended Posts

ChrisJ60

We are running Emby Server 4.5.4.0 and the latest version of the Emby apps on iOS, tvOS and LG Smart TV. Our primary viewing device is the LG Smart TV. We have several titles that use SRT subtitles and we have observed that while the sub-titles are in sync when viewed via the iOS and tvOS apps, they lag by a few seconds when using the LG Smart TV app (and in the Emby Web Player via a browser on a Mac). I assume this is not expected behaviour? Surely Emby should present the sub-titles the same across all devices?

 

Edited by ChrisJ60
Typo
Link to comment
Share on other sites

rbjtech

Is it just a few titles or all of them ? Are these internal or externals SRT's ?  Do these files have other subtitles available as it may be that the clients are using different subtitle streams ?

I use the LG App pretty often and have not witnessed this using external Subs.

Do you have any logs and media file info from each playback session ?

Link to comment
Share on other sites

ChrisJ60

The problem occurs with all the files that I have so far examined. These are M4V (MP4) files (no embedded subtitles) with a single external SRT subtitle file. When viewed via VLC the subtitle timing matches that when viewed via the Emby app on iOS/tvOS devices. So it seems the 'problem' is somehow related to the Emby LG TV app and the Emby WebPlayer.

Emby server log covering all of the experiments is attached.

 

embyserver.txt

Link to comment
Share on other sites

rbjtech

It looks like these are being streamed, not direct played - so there should be an ffmpeg log that goes with the playback ?  Could you attach that also.

Link to comment
Share on other sites

ChrisJ60

I'd be surprised if the media itself is being transcoded since transcoding is disabled. Do you mean that the subtitles are being somehow transcoded? Where would I find the ffmpeg log? It isn't listed in the Emby web console under logs.

Link to comment
Share on other sites

rbjtech

If the delay is happening on the normal web player as well - is there a possibility some sort of Subtitle offset has been set ?

Capture.PNG.b4f7313bd9334518fe98787fa8a79aea.PNG

I'm really not sure on this one - with external SRT, there really is not a lot to go wrong.

I don't see any other reports of this, so I believe it's something on your system .. 

Maybe worth installing a 2nd portable version of emby on a different port with a test library ? 

  • Like 1
Link to comment
Share on other sites

SamES

With Apple TV and iPad they're being streamed as srt files, but on the LG and Safari they are being converted by the server and streamed as vtt files.  Now why vtt is causing a delay, that's a question I don't have an answer for. 

The subtitle delay feature hasn't been implemented on LG yet (next release), so that shouldn't be causing any issues.  A few seconds delay does sound like a lot though.

Can you try this?  Put this url into a browser to download the vtt file.  Save the contents into a text file.  Then find the matching srt  and movie file

http://10.0.200.20:8096/emby/Videos/104596/112ec636bd1d464ea1877f3cafab5ddd/Subtitles/3/0/Stream.vtt

Please upload the text file with the vtt, the srt and the MediaInfo.  Ideally I would like to see the full media info extracted with MediaInfo - Download (mediaarea.net)

I'm not entirely sure what this will tell us, but something might jump out 

  • Like 1
Link to comment
Share on other sites

rbjtech

Thanks @SamES - that's useful info.

If I play a SRT on a chrome web browser - I get an ffmpeg conversion in the log from srt to vtt as you say - under 'Info SubtitleEncoder' - but I see no such entries on the OP's log file.

I did the same with all transcoding permissions removed (same as OP) - but I still see the ffmpeg command run in my logs.

@ChrisJ60The temp vtt file is created when the file is first played - and it doesn't appear to be removed - ie it is re-used when you play the file again.    So there is a possibility that the LG and Safari are simply re-using these temp .vtt files that are incorrectly timed.

They live in <emby-server>\programdata\cache\subtitles\

I would suggest deleting them all - and watch that directory when you play an item with external subs - it should create the temp vtt file - and you should be able to compare it to the original .srt (use an text editor).  You should also see the creation of it in the log file.

Edited by rbjtech
  • Like 1
Link to comment
Share on other sites

SamES
2 hours ago, rbjtech said:

If I play a SRT on a chrome web browser - I get an ffmpeg conversion in the log from srt to vtt as you say - under 'Info SubtitleEncoder' - but I see no such entries on the OP's log file.

Probably because the conversion only happens once, then it's cached.  If you play the same item again do you see the same info message?  I just noted the .vtt stream in the OP's log which is how I knew what it was calling for.

  • Agree 1
Link to comment
Share on other sites

rbjtech

Agreed - I think we are on the correct path here - we just need to see the vtt and srt - if they don't match then we have found the issue - probably solved by just deleting the vtt and then play again to re-create it.

Link to comment
Share on other sites

ChrisJ60

Hi guys, thank you so much for the very useful information / explanations. I have been experimenting with this again today, observing what appears in the Emby cache etc. etc. In typical fashion, now I cannot re-create the issue. I started with a fresh SRT subtitle file that is in sync with the video file when viewed using VLC and I put that file (as the only subtitle file) in the folder with the video file. I removed all the cached subtitles from the Emby cache and viewed the video via Emby, with subtitles enabled, on Apple TV and on my iPad. The subtitles appeared exactly as they did in VLC (i.e. the timings were correct). Nothing appeared in the Emby subtitle cache (as expected). I checked the generated .vtt file and, no surprise, the timings there were the same as in the SRT file.

Next I played the video, via Emby, using Safari on my Mac. Again the subtitles appeared correctly. This time there was a .vtt file created in the cache (as expected). Then I viewed the video via Emby on my LG TV and again everything was fine. No new files appeared in the subtitle cache (as expected). I then tried replacing the .SRT file with one which had bad timings. Viewing this via Apple TV and iPad now showed the incorrect timings. I then viewed the file using TV and also via the Web browser. Emby generated a *new* .vtt (presumably as it knew that the SRT file had changed - newer timestamp) and this file had, as expected, the incorrect timings. The video also showed the incorrect timings as well when viewed. I checked the newly generated .vtt file and of course the timings there were the same as in the (new) SRT file.

So everything appears to be working correctly / as expected. So I am baffled as to why previously we were seeing a few seconds discrepancy. It wasn't just me, my wife first brought it to my attention!

I'm not sure where to go from here. The good news is that things now seem to be working as they should, but the reason for the original problem is unexplained, and I don't like those kind of mysteries. Thank you both for all your help; much appreciated. I learnt a few new things, which is nice.

In case it is of interest, here is the MediaInfo output for the video file...

General
Complete name                            : /Users/chris/Desktop/Subtitles/Babylon Berlin - s03e04.m4v
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (isom/iso2/avc1/mp41)
File size                                : 1.51 GiB
Duration                                 : 45 min 46 s
Overall bit rate                         : 4 735 kb/s
Collection                               : Babylon Berlin
Season                                   : 3
Part                                     : 4
Track name                               : Episode 4
Director                                 : Achim von Borries / Henk Handloegten / Tom Tykwer
Actor                                    : Anton Rattinger / Arno Frisch / Benno Fürmann / Caro Cult / Christian Friedel / Christian Sengewald / Detlef Gode Benedix / Friedrich Küppersbusch / Fritz Roth / Fritzi Haberlandt / Hannah Herzsprung / Hanno Koffler / Inga Birkenfeld / Irene Böhm / Jacob Matschenz / Jan Georg Schütte / Jens Harzer / Johann Jürgens / Jördis Triebel / Julius Feldmeier / Karl Markovics / Katja Hiller / Lars Eidinger / Laura Kiehne / Leonie Benesch / Liv Lisa Fries / Lola Witzmann / Luc Feit / Meret Becker / Mišel Matičević / Rike Eckermann / Ronald Zehrfeld / Rüdiger Klink / Sabin Tambrea / Sabrina Strehl / Saskia Rosendahl / Thimo Meitner / Thomas Thieme / Thorsten Merten / Tim Fischer / Trystan Pütter / Udo Samel / Volker Bruch / Zeljka Preksavec
Screenplay by                            : Achim von Borries / Henk Handloegten / Tom Tykwer
Producer                                 : Michael Polle / Stefan Arndt / Uwe Schott
Production studio                        : Beta Film
Genre                                    : Drama;Crime;History
ContentType                              : TV Show
Description                              : Colognian commissioner Gereon Rath moves to Berlin, the epicenter of political and social changes in the Golden Twenties.
Recorded date                            : 2020-01-31
Encoded date                             : UTC 2020-03-21 18:48:36
Tagged date                              : UTC 2020-08-12 18:01:41
Writing application                      : HandBrake 1.3.1 2020010400
Cover                                    : Yes
Rating                                   : None
MEDIA                                    : TV Show
LABEL                                    : Beta Film
PRODUCER                                 : Michael Polle,Stefan Arndt,Uwe Schott
INVOLVEDPEOPLE                           : Director;;;Achim von Borries,Henk Handloegten,Tom Tykwer;;;Screenwriter;;;Achim von Borries,Henk Handloegten,Tom Tykwer
MUSICIANCREDITS                          : Actor;;;Anton Rattinger,Arno Frisch,Benno Fürmann,Caro Cult,Christian Friedel,Christian Sengewald,Detlef Gode Benedix,Friedrich Küppersbusch,Fritz Roth,Fritzi Haberlandt,Hannah Herzsprung,Hanno Koffler,Inga Birkenfeld,Irene Böhm,Jacob Matschenz,Jan Georg Schütte,Jens Harzer,Johann Jürgens,Jördis Triebel,Julius Feldmeier,Karl Markovics,Katja Hiller,Lars Eidinger,Laura Kiehne,Leonie Benesch,Liv Lisa Fries,Lola Witzmann,Luc Feit,Meret Becker,Mišel Matičević,Rike Eckermann,Ronald Zehrfeld,Rüdiger Klink,Sabin Tambrea,Sabrina Strehl,Saskia Rosendahl,Thimo Meitner,Thomas Thieme,Thorsten Merten,Tim Fischer,Trystan Pütter,Udo Samel,Volker Bruch,Zeljka Preksavec
LongDescription                          : Evidence from Krempin's home reveals his and Rot's interest. A neighbour gives Charlotte something her mother left. Gräf accesses the Benda case file.
TVNetworkName                            : Sky Deutschland
ContentRating                            : uk-movie|15|350|
GenreID                                  : 4406

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 45 min 46 s
Bit rate                                 : 4 441 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.086
Stream size                              : 1.42 GiB (94%)
Writing library                          : x264 core 157 r2935 545de2f
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date                             : UTC 2020-03-21 18:48:36
Tagged date                              : UTC 2020-03-21 18:48:36
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 45 min 46 s
Bit rate mode                            : Constant
Bit rate                                 : 265 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 88.0 MiB (6%)
Title                                    : Stereo
Language                                 : German
Default                                  : Yes
Alternate group                          : 1
Encoded date                             : UTC 2020-03-21 18:48:36
Tagged date                              : UTC 2020-03-21 18:48:36

 

 

  • Like 1
Link to comment
Share on other sites

SamES

Perfect.  Did you swap srt files at some stage, or has it always been the same srt with the same timings?  If you update/replace the an srt file, I'm not sure how (or if) it knows to recreate the vtt 

Link to comment
Share on other sites

rbjtech

@ChrisJ60 Good to know it is now working as expected - Agreed on needing to know what happened - very odd ?!

@SamES Anytime that SRT changes, be it a replacement / new file or simply modifying the contents of the existing file, a new vtt is generated and used - I tested that during my initial investigation.  This rules out if the SRT was incorrect in the first place (thus the cached version would also be incorrect) - so it's a bit of a mystery why the generated vtt was out of sync.

I'm questioning why the cached vtt file is kept at all after use - it takes a fraction of a second to create - so personally I would always re-create it each time rather than use an existing file as emby is unlikely to know its history.

An interesting thread. 👍 

Edited by rbjtech
  • Like 1
Link to comment
Share on other sites

ChrisJ60

In my (fairly simple) testing, changing the SRT file resulted in a new VTT file being generated. However the old VTT file is not deleted and the new one is retained. I don't know when/if Emby ever cleans up these cache entries. As @rbjtech said, for something like this where the VTT file can be generated in a fraction of a second I don't really see the point of caching it to be honest and that would avoid any potential issues with using a stale file by accident (i.e. due to some bug).

  • Like 2
Link to comment
Share on other sites

SamES
2 hours ago, rbjtech said:

I'm questioning why the cached vtt file is kept at all after use - it takes a fraction of a second to create - so personally I would always re-create it each time rather than use an existing file as emby is unlikely to know its history.

Yeah, I agree.  I've experienced either empty or partial vtt files on occasion, so it is a pain.  Maybe there should be an easy way to force the vtt to be regenerated. 

I think the reason they are cached is if they are generated from an internal embedded stream (ie: mov_text in mp4) then the extraction process takes longer. 

Link to comment
Share on other sites

  • 7 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...