Samsung TV: seeking doesn't always work
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Re: Samsung TV: seeking doesn't always work
I'm not sure we can fix it then. As said before, I wasn't quite sure of the cause, but the way it works when streaming subtitles is basically that UMS offers two files to the renderer. One is the transcode output, the other is the subtitles file. The subtitles file has its timestamps set relative to the beginning of the file. My guess is that after seeking/jumping in the transcoded file, your renderer assumes that the timestamps in the subtitles file are relative to the point where playback started.
There's nothing much we can do about that unless we were to generate a new subtitles file on-the fly with adjusted timestamps. That isn't really a viable option, and I would say that this falls under the responsibility of the renderer to figure out. After all, it requests a position to play from and should be able to understand that the subtitles timestamps still relate to the start of the file.
There's nothing much we can do about that unless we were to generate a new subtitles file on-the fly with adjusted timestamps. That isn't really a viable option, and I would say that this falls under the responsibility of the renderer to figure out. After all, it requests a position to play from and should be able to understand that the subtitles timestamps still relate to the start of the file.
Re: Samsung TV: seeking doesn't always work
Well, if the renderer does it wrong, it's not your fault. I'll just have to use hardcoded subs for transcoded videos (my TV supports pretty much all video types without transcoding anyway). Thanks for trying!Nadahar wrote: ↑Sun Jan 28, 2018 3:13 am I'm not sure we can fix it then. As said before, I wasn't quite sure of the cause, but the way it works when streaming subtitles is basically that UMS offers two files to the renderer. One is the transcode output, the other is the subtitles file. The subtitles file has its timestamps set relative to the beginning of the file. My guess is that after seeking/jumping in the transcoded file, your renderer assumes that the timestamps in the subtitles file are relative to the point where playback started.
There's nothing much we can do about that unless we were to generate a new subtitles file on-the fly with adjusted timestamps. That isn't really a viable option, and I would say that this falls under the responsibility of the renderer to figure out. After all, it requests a position to play from and should be able to understand that the subtitles timestamps still relate to the start of the file.
Re: Samsung TV: seeking doesn't always work
The problem is that subtitle support isn't precisely defined as it's outside the DLNA standard. DLNA doesn't have support for subtitles at all, so Samsung and Panasonic have both come up with their own, undocumented solutions. Others have also started to use one of those "unofficial extensions" for subtitles, but in the end there's no clear definition of the rules.
That said, I don't think it's reasonable that the server would have to regenerate the subtitles file with modified timestamps instead of the renderer simply being able to do some basic math. My point is simply that I can't absolutely assert that "this is the renderer's responsibility", although I absolutely believe it should be.
That said, I don't think it's reasonable that the server would have to regenerate the subtitles file with modified timestamps instead of the renderer simply being able to do some basic math. My point is simply that I can't absolutely assert that "this is the renderer's responsibility", although I absolutely believe it should be.
Re: Samsung TV: seeking doesn't always work
I agree with you. They should get their stuff together.Nadahar wrote: ↑Sun Jan 28, 2018 5:15 am The problem is that subtitle support isn't precisely defined as it's outside the DLNA standard. DLNA doesn't have support for subtitles at all, so Samsung and Panasonic have both come up with their own, undocumented solutions. Others have also started to use one of those "unofficial extensions" for subtitles, but in the end there's no clear definition of the rules.
That said, I don't think it's reasonable that the server would have to regenerate the subtitles file with modified timestamps instead of the renderer simply being able to do some basic math. My point is simply that I can't absolutely assert that "this is the renderer's responsibility", although I absolutely believe it should be.
Edit: I'm currently creating a proper renderer conf for my TV, what's the difference between SupportedExternalSubtitlesFormats and SupportedInternalSubtitlesFormats?
Re: Samsung TV: seeking doesn't always work
@abcd I have the same experience with my Panasonic TV. Seeking doesn't work. The SupportedInternalSubtitlesFormats means embedded subs formats (e.g. in MKV video) which can renderer play when video is streamed (supported by renderer). When this is not set and there are embedded subtitles in the video it will be transcoded not streamed.
@Nadahar I think that we should add to the description of the StreamSubsForTranscodedVideo that this is an experimental setting and it could not work properly for seeking.
@Nadahar I think that we should add to the description of the StreamSubsForTranscodedVideo that this is an experimental setting and it could not work properly for seeking.
Re: Samsung TV: seeking doesn't always work
@valib Streaming subtitles while transcoding works fine for me with Kodi even when seeking. I can't see how would could do it differently, so I really think this must be a problem with the renderer.
Re: Samsung TV: seeking doesn't always work
@Nadaher I know that this is the renderer problem so we should stated that it couldn't work on some renderers.
Re: Samsung TV: seeking doesn't always work
@Nadahar: in the other thread you asked me to create a pull request with my renderer conf. I don't really feel like going through the hassle of GitHub, so I'll just post it here. I think it should work with all of Samsung's 2017 UHD models.
- Attachments
-
Samsung-MU.conf
- (5.91 KiB) Downloaded 743 times
Re: Samsung TV: seeking doesn't always work
@abcd Ok - let's hope some other eager soul will take care of the hazzle and create a pull request with it then 
