Samsung QN55Q80DAFXZC not able to seek in videos

[Pitchblack 36]

Hi, I'll put the tv info first.

Model: Samsung QN55Q80DAFXZC

Tv software version: 1310

App: Emby for Samsung 1.9.0

Server: 4.9.0.48 beta

 

The TV works great with Emby, happy to play AV1 videos natively amongst other things.

The problem is whenever I try to rewind or fast forward a video using the seek bar, I'm instantly met with a spinning loading wheel of death and then nothing ever plays after that until I back out of the video and resume it.

Also, sometimes when I pause a video and then resume the video without leaving the video.. emby goes back in time a bit and replays a part of the video prior to when it was stopped.

I tried with H264 and H265 videos, small and big, subtitles or not... It's all the same. This doesn't happen on my very old LG TV, on the web client or my Pixel 7 phone.. only this specific TV.

 

I will add logs shortly.

 

Regards,

Pitchblack

embyserver.txt

Edited April 20 by Pitchblack
Added embyserver logs

[Luke 39843]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[Pitchblack 36]

Hi, I added embyserver full logs.

 

I also want to add that the videos used for testing were all "direct play" for both video and audio... No transcoding.

[FrostByte 5229]

Are you able to update to the latest version to see if it helps?

[Pitchblack 36]

Updated server to 4.9.0.50 beta though I doubted it would have changed anything and there's no update available on the client side, so emby client for samsung 1.9.0.

 

Same issue happens

Edited April 21 by Pitchblack

[Pitchblack 36]

Also adding that this issue has been happening ever since I got this tv, so it never worked. It's been a few beta versions since.

[FrostByte 5229]

Actually, you are several versions behind on the client.  Current version is 2.0.3.   If you don't see it in the store, then you may have to load it via usb.  You can always go back to the store version if you wish.

[Pitchblack 36]

I updated the emby client to v2.0.3 and tested again. I resumed a video and I was able to seek but when starting new videos i had the exact same issue as before.

@SamES

Will update with new server logs Done

embyserver.txt

[SamES 996]

1 hour ago, Pitchblack said:

I updated the emby client to v2.0.3 and tested again. I resumed a video and I was able to seek but when starting new videos i had the exact same issue as before.

@SamES

Will update with new server logs Done

embyserver.txt 209.55 kB · 0 downloads

Has this always been a problem, or did it start recently or with a specific update?

Can you please test a simple file, h264, AC3 audio, no subtitles and see how that goes?  Please post the media info and logs (please take note of the test time) for that sample so we can be sure of what you are testing.  Is the server local or remote?

[Pitchblack 36]

Hi,
This has always been an issue ever since I started using Emby with that specific TV. The behaviour was the same with any version of emby server I tried and samsung client version.

I just tested a new video (H264 video codec and AC3 audio codec and no subtitles), I got the same issue.

 

Here's the media info:


I'm also attaching the logs to the post.
I have tested from 20:29 eastern time (01:29 UTC) to 20:32 eastern time (01:32 UTC).

And for the last question, for this TV, the server is Remote, but there's no remote issues for my Phone or from the Web Client, only this TV.

 

Regards,

Pitchblack

embyserver.txt

[SamES 996]

I'm a little bit suspicious that the remote connection might be part of the issue, particularly if there is network high latency, or if it's behind a reverse proxy.

The Samsung player is a little less tolerant of a poor network connections compared to LG TV's and your browser.

You could try fully uninstalling the app (don't just remove it from the Home screen), unplug the TV from mains power for a few minutes, then reinstall the latest version and try again.

 

[Pitchblack 36]

The remote server is only 40km (~25 miles) away from this location.

 

The remote server is also behind a reverse proxy (HAProxy) and hosted on a docker container.

 

What I find weird is that I can launch the playback of any video, it starts rapidly and plays all the way to the end without any issue if I don't touch the seek bar during playback.

 

Nonetheless, I will try what you suggested.

 

Regards,

Pitchblack

[SamES 996]

4 minutes ago, Pitchblack said:

The remote server is only 40km (~25 miles) away from this location.

 

The remote server is also behind a reverse proxy (HAProxy) and hosted on a docker container.

 

What I find weird is that I can launch the playback of any video, it starts rapidly and plays all the way to the end without any issue if I don't touch the seek bar during playback.

 

Nonetheless, I will try what you suggested.

 

Regards,

Pitchblack

I agree it's a bit weird, but no one else is reporting this issue, so I expect it is something between your server and TV.  I just don't know what.  

[visproduction 265]

Suspect your media has issues and / or the video bitrate combined with the AC3 audio and possible VBR video encoding (not advised) causing buffering on fast forward.

Try a demo video 20 MB 720P from this page and see if it works.
https://sample-videos.com/
  Direct link: https://sample-videos.com/video321/mp4/720/big_buck_bunny_720p_20mb.mp4

Edited April 22 by visproduction

[Pitchblack 36]

Hi,
So I added the file visproduction linked and played it on the TV and the TV returned a playback error but according to "Now Playing" in the admin dashboard, the TV recovered from the error and was playing the file.

It was as follows:


Seems to recover but not sure how you can both direct play and transcode (Orange bar) at the same time?

Strangely enough (or not), after recovering from that playback error and in that state, seeking forward and backward works... I assume that the client requested the server to transcode the file into a native video for the TV and that's why it works well like that.. but still not clear to me why it wouldn't work on previous tests if file were Direct Playing... doesn't "Direct Play" mean that the client's hardware has native support for what the server is sending?

Media Info of the example file


I'm also adding the emby server logs again and the ffmpeg logs (transcode logs I guess).

The test was done at 10:34 eastern time or 15:34 UTC.

Regards,
Pitchblack

embyserver.txt ffmpeg-directstream-7b7f93b6-f301-4c7b-859c-c49e60696d5f_1.txt

[visproduction 265]

PB,
Not sure what happened.  Perhaps someone can read the embyserver.txt log better.  Since you said Forward works on the demo, I think the combo of the TV playback plus the encoded Video and audio bitrates and whatever issues the earlier larger media had, was perhaps the problem.  With a high bitrate on the video and possibly VBR (Variable bit rate) encoding, the TV just doesn't want to handle this higher res and heavily encoded video to let you use fast forward.  I really don't think this is very surprising.  Media that is encoded by someone using some automated software / hardware that tries to compress and may have some other issues, is just not a proper media version that can be used on all gear. Encoding for streaming playback on TV apps or browsers is very tricky to get everything correct.  If you start with a media file that has issues, it might play back fine on a 3rd party player which allows timeline problems or VBR issues, but TV Apps and browsers are much more limiting.

Then you have a situation when the playback has a problem and emby senses it and triggers a transcoding to make a copy that the TV app can like.  That might work, but as soon as you run into a timeline metadata glitch or a very high bitrate and AC3 audio encoding for surround, which has many versions of EC3 and Dolby that don't always appear labled correctly and need to be encoded or cause a direct playback issue, or has to be cached and handled by the TV App.  It can easily be a mess and the media file looks OK and plays back elsewhere, so everyone thinks it's fine, when it isn't.

If your large media files are properly encoded without errors and kept below whatever bitrate your system can handle, they will probably play back fine and everything will work.  I pre encode everything to h.264 MPEG-4 AVC (part 10) avc1 and Audio AAC mp4a run it through mp4box to clean up any issues and everything I have in 1080P or 4K plays on several TV types with fast forward options, play pause and everything in sync.  I think your original source media is probably the issue.  That is my guess.

Let's see if anyone else can break down something that will work based on the test.

[Pitchblack 36]

To me it seems very unlikely to be about the files... My LG TV at my other place is much much older and plays eveything I throw at it just fine and can seek forward and backward h264 or hevc on main or high profile and many different levels, with subtitles or not... VBR or CBR... 

 

My files are not especially weird, they direct play just fine.

 

This Samsung TV is a much newer model and even natively supports AV1 playback... It's modern. I can't believe it could perform worse than my 2015 LG TV.

 

I have literally not playback issue whatsoever with any platforms, including web browser, except for this specific TV... For the same videos and many other videos and this is the only device which can't seek without transcoding...

 

I don't think we should assume all my files are encoded incorrectly since they work perfectly on any device except this one... What should I look for on a file to see if they are encoded "correctly"...? This sounds much more like a Samsung issue.

 

A 720p/1080p H264 video file encoded at 2mbps should be easily played and seeked through by anything in the last 15 years or so...

 

Regards,

Pitchblack

[Pitchblack 36]

And I also know someone else who uses a similarly old LG TV remotely to my server and they never had a seeking issue... It really seem central to this Samsung TV or at least this model, idk...

[SamES 996]

7 hours ago, visproduction said:

Suspect your media has issues and / or the video bitrate combined with the AC3 audio and possible VRB video encoding (not advised) causing buffering on fast forward.

Try a demo video 20 MB 720P from this page and see if it works.
https://sample-videos.com/
  Direct link: https://sample-videos.com/video321/mp4/720/big_buck_bunny_720p_20mb.mp4

This is a good test, but we really need to use something in mkv that won't require transcoding.

Did you try to uninstall/poweroff/reinstall, just to be sure?

Can you send me a PM with a link to download one of your files that you know you have a problem with, thanks.

[Pitchblack 36]

Hi,

I completely uninstalled Emby from the TV, then unplugged the TV for a few minutes, then reinstalled Emby using the USB key (v2.0.3) and then tested again with the same issue.

 

Most of my files are actually MKV files with either H264, HEVC or AV1 video codecs and most have AAC, AC3 or OPUS audio... which are pretty ?much all don't require transcoding since they direct play... but what's the difference from MP4 there? I've seen that issue on a MKV file as well when watching anime.

 

Not sure how you want me to DM you the files as they're pretty big... I guess I could 7zip them in multiple parts and send links to you.

 

[FrostByte 5229]

SamES may not need the whole file.  Split your mkv using mkvtoolnix.  If you can reproduce the problem with a small (maybe 5 min or less chunk) then that should be fine for testing.

[SamES 996]

11 hours ago, Pitchblack said:

Hi,

I completely uninstalled Emby from the TV, then unplugged the TV for a few minutes, then reinstalled Emby using the USB key (v2.0.3) and then tested again with the same issue.

 

Most of my files are actually MKV files with either H264, HEVC or AV1 video codecs and most have AAC, AC3 or OPUS audio... which are pretty ?much all don't require transcoding since they direct play... but what's the difference from MP4 there? I've seen that issue on a MKV file as well when watching anime.

 

Not sure how you want me to DM you the files as they're pretty big... I guess I could 7zip them in multiple parts and send links to you.

 

Definitely no issues playing the one mkv file on my older Samsung TV, I will try and test on my other TV tomorrow, but I expect it will be fine.

Are you using the original Samsung remote control or are you using a generic or programable remote?

[Pitchblack 36]

Hi,

I did some more tests and these are the behaviours I noticed:

 

Any MKV file starts immediately when pressing the "play" button and they play natively "Direct Play"... but I'm unable to seek anywhere in the video... loading wheel of death.
If I go to the video menu and press the "attempt playback correction", the video starts being transcoded (although the transcoding orange bar is immediately entirely filled up like it's already fully transcoded) and the file plays nicely and even the seeking works correctly... weird..

Even weirder, when I actually play a MP4 file... the most basic H264 video and AAC or AC3 audio... it takes an eternity for the file to load and when it starts playing it either gives a playback error message or not and in either case it starts transcoding... and since it's transcoding, the playback and seeking works... it is so weird...

I'm going to send a MP4 file Ii tested to SamES... I've tested the shortened and full length version.

I've shortened it using this basic ffmpeg command:

 

ffmpeg -hide_banner -y -i "Y:\path\filename.mp4" -to 00:13:00.000 -c:v copy -c:a copy "new_filename.mp4";

Something totally bizarre is going on with this TV...

Pitchblack

[SamES 996]

I think there is something not correct in the server reverse proxy.  The Samsung Emby app users the TV's native player which works a little differently to some other apps that use a generic html video player, which is why you might be having issues on this TV.

Can you install a local server, you can use the portable version (https://emby.media/windows-server.html) as a quick test?.  Add a few of your files to a library and see whether they play correctly

[Pitchblack 36]

Hi,

When I saw the reply I thought it had great potential and in fact, when connecting directly to the local server in LAN without a proxy, everything works perfectly... MKV, MP4, H264, HEVC, AAC, AC3... forward and backward too, basically as it should.

If that suggest an issue with the reverse proxy, then I wonder why when the TV requests transcoding after a failed playback everything starts working again (seeking backward and forward)..

Do you have an idea of what kind of configuration the reverse proxy requires for the TV to be happy with?

 

Pitchblack