Subtitle offset not saved when stopping video and resuming

[As777 22]

On my Android TV v2.0.09g the subtitle offset is not saved when resuming a video. It resets back to 0. It also resets to 0 if you change to another subtitle and then put it back again.

[GrimReaper 3330]

 

[As777 22]

Have added my support.  I know Emby does a lot and I am a new user but this kind of stuff is fundamental to a working environment.

[Carlo 4331]

Hi, The best way to handle this is to change the timing of the actual subtitle file so this way it works for everyone and all software.

[GrimReaper 3330]

31 minutes ago, cayars said:

Hi, The best way to handle this is to change the timing of the actual subtitle file so this way it works for everyone and all software.

While that may work for some (or most) of the well-known languages (English, French, Spanish...) where the available subtitle pool is large by default, with high chance of finding exact subtitles and only occassionally having to adjust timings, for more obscure languages (like my own), where one's lucky if a single subtitle is found, regardless of version, that really ain't practical (and that's an understatement), as adjusting timing for practically every other movie or episode is simply not feasible. Besides, I don't need that offset for anything else but Emby. 

Edited August 4, 2021 by GrimReaper76
Typos

[As777 22]

36 minutes ago, cayars said:

Hi, The best way to handle this is to change the timing of the actual subtitle file so this way it works for everyone and all software.

Audio/Video/Subtitle sync are problems that have existed as long as digitised video has been around. To still be having this kind of problem in 2021 isn't really fun but the solutions have been know for a long time.

Subtitle offset is critical to adjust even small sync issues, nevermind large ones. While it would be nice that everything just works all of the time, it's not the case. It's surely trivial to add a new database field and the offset position and save this value so that it can be recalled.

I am also surprised there is no audio/video +- offset in the players either. It's the thing that stops me dumping the computer and Kodi altogether because there's a small percentage of the time I need to adjust audio/video sync. Same when using bluetooth headphones. The TV just does not handle the sync properly...both TVs i own only allow you to delay the audio further for receiver sync issues but they  don't allow "audio ahead".

Edited August 4, 2021 by askog666

[rbjtech 4333]

I'm on the 'fix the source' side of the fence - relying on the server to do this for you is much more complex than 'just save the offset' as it may be correct for that user on that device at that time, but next time they play it on a different device, they may inherit the incorrect offset (as an example).

I do agree it's hassle - but preparing the media to make it play correctly without server intervention (be it transcoding, stripping incompatible streams, syncing the subs or whatever) is something that pays dividends later as 99.9% of the time it 'just works' for the life of that media.

 

[As777 22]

9 minutes ago, rbjtech said:

I'm on the 'fix the source' side of the fence - relying on the server to do this for you is much more complex than 'just save the offset' as it may be correct for that user on that device at that time, but next time they play it on a different device, they may inherit the incorrect offset (as an example).

I do agree it's hassle - but preparing the media to make it play correctly without server intervention (be it transcoding, stripping incompatible streams, syncing the subs or whatever) is something that pays dividends later as 99.9% of the time it 'just works' for the life of that media.

 

Fix the source is easier said than done. Many times you cannot find a subtitle that is specific to the exact container your movie/show is in. The solution to anyone non technical is to just give up ...or go back using the computer and Kodi and just fix it there. We can't always build solutions for best case scenario only.

We have all this great technology but none of it works properly without fixes, workarounds, backup systems, etc. (I dont mean just Emby here, the entire eco system of smart tvs, wireless headphones etc....always some kind of problems the manufacturers are too lazy to help fix).

The point of things like Emby is that anyone can use them without any technical know how. I want to open up my library to household members and allow them to enjoy it on the TV just using a point and click solution but I can't do that because there's too many issues that I have to play IT support for.
 

Edited August 4, 2021 by askog666

[As777 22]

11 minutes ago, rbjtech said:

I'm on the 'fix the source' side of the fence - relying on the server to do this for you is much more complex than 'just save the offset' as it may be correct for that user on that device at that time, but next time they play it on a different device, they may inherit the incorrect offset (as an example).

 

 

I do understand the implications , I myself am a system designer and programmer and these problems are things I deal with all the time.

These are client side settings though and should be saved by the client. I don't go to a website and login only to have everything reset because I have changed browser and then have someone argue that i changed browser so the settings I have no arent relevant anymore.

[rbjtech 4333]

Wouldn't that be great for it to all magically work haha..

I'm agreeing with you to a certain point - but there has to be a point where the Admin of the system is responsible for the quality of the content they are showing.

If you have taken the trouble to find a subtitle track, then (imho) the very least you can do is to make sure it's in sync.  There are many (free) tools to help you do this, some even sync the audio to the sub.

The area where things go a little grey, is when external influences impact a properly synced source - such as AVR's and Bluetooth headsets, where delay is introduced - but fixing this 'once' for your setup should be all that is needed - you should not have to do this for each media item.

 

 

[As777 22]

Honestly you are playing devils advocate here. I have better things to do with my time then create perfect subtitle files for a 5 season series with 13 eps each. I am not selling Netflix type subscriptions to family members where i have a responsibility of quality lol

The offset is already there and implemented. It just doesn't save the position when you stop a video and return to it. The server saves and retains information about the current status of the video...it should retain the subtitle offset once manually adjusted as well.  It's a simple fix.

Edited August 4, 2021 by askog666

[Carlo 4331]

There will likely always be two schools of thought on this type of thing. Neither is right or wrong as it's just two ways to look at it. @rbjtech and I both handle our media in a similar way so it's no surprise to me his view on this which is similar to my own.  We both reprocess our media before adding it to our system so it's in the format we want it to be in.

I know I remove audio and internal sub titles tracks from media that aren't needed. I make sure to have a 2 channel AAC audio track as well as any better audio tracks.  I then convert video to HEVC.  If there is an internal sub rip it's pulled and made an SRT sub, etc  If it's a recording, then other steps are applied such as cutting of the pre & post padding as well as commercial removal.  Then converting closed captioning (USA) to external SRTs, etc Then packaging all this into specific containers and support files.

So when you do things like this via a pre-processing pipeline it's natural to want to do subtitle offset before adding media to Emby as well to keep your media nearly "perfect".

The extreme opposite school might never touch the media at all and doesn't even know the format of the media added or even what media has been added as they use programs that download stuff off the Internet.

There of course is likely a large group that fall somewhere between the two as well.

One thing however to keep in mind is that a simple offset can not always be used to "fix" timing.  It can be more complex because of fps where the timing offset slowly changes during the course of the media and the only way to fix this is to rewrite/adjust the timing outside of Emby with many adjustment/sync points.

[GrimReaper 3330]

As you've said it yourself, there will always be (at least) two groups/views on the matter, as with just about any topic. I reckon Emby's goal should be to provide for both, without favoring any in particular, else they'll be severely limiting their userbase. As long as certain feature doesn't come on the expense of one or other group (and it is not like that this particular one requires some fundamental changes in logic or behaviour nor does it negatively affect anyone), I don't quite understand the reluctance here. Not everyone has the urge to meticulously curate one's collection. Not everyone has the will to do it. Not everyone has time for it. But surely all want to enjoy it. And yeah, not ALL sync issues could be solved by offset saving - however majority would, and that's good enough, as it would drastically reduce the need for manual intervention.

[As777 22]

I am not really sure why there is so much discussion about "what school of thought" is correct regarding if Emby should use a subtitle offset or not.

The subtitle offset exists in all the players (albeit inconsistently...the Android surf app uses milliseconds while the TV app uses seconds). My problem is that the client is not remembering the offset if you stop the video and resume. Why we need a discussion about the rights and wrongs of subtitle displacement is outwith he scope of my topic.

Edited August 6, 2021 by askog666
grammar

[As777 22]

removed

Edited August 6, 2021 by askog666
removed

[ebr 14959]

9 minutes ago, askog666 said:

I want to use merge fs as a convenient overview and a single map in Emby but I want to decide where the actual data is written to. If I write to mergefs it decides where the content will go.

I think the problem is that I am sending content not to the actual mergefs folder but directly to the local storage folder and that writing to the local folder does not trigger any event that Emby reacts to when pointing to the mergefs folder, thus does not "detect" any changes.

I am in the process of restructuring my server right now and converting to ext4 as I have other issues I need to sort and will report back.

Hi.  That's unrelated to subtitle offsets, correct?

[As777 22]

1 minute ago, ebr said:

Hi.  That's unrelated to subtitle offsets, correct?

Yes, why would this have anything to do with my subtitle offset problem?

[As777 22]

15 minutes ago, ebr said:

Hi.  That's unrelated to subtitle offsets, correct?

I think i understood now what you really meant with that question.

Yes my "other problems" are with my Raspberry Pi 4 and the fact I am trying to set up a couple of servers and other services with Docker. Something, somewhere is consuming too many resources and causing massive issues with performance.

 

[ebr 14959]

26 minutes ago, askog666 said:

Yes, why would this have anything to do with my subtitle offset problem?

Because you posted it in this thread about subtitle offsets.  For help on a different issue, be sure to bring that up in a separate thread.

Thanks.

[As777 22]

2 minutes ago, ebr said:

Because you posted it in this thread about subtitle offsets.  For help on a different issue, be sure to bring that up in a separate thread.

Thanks.

I have obviously posted in the wrong thread by mistake and not done that on purpose. I will repost it in the right place.