Fast forward, seek bar not working on web player

[devil202 4]

Hello,

I am facing a weird issue recently. Higher bitrate media (≈ > 1000 kbps) are having trouble while fast forwarding 10 sec for seeking with the progress bar. The media plays fine but it starts from the beginning if forwarded or seeked. This is occurring on web browser player only. I have tried emby server v4.5 and latest v4.6.4.0 on different Linux servers. 

All files are direct playing and are in mp4 format. I have emby premier on both servers. There is no error on browser console. Media with lower  (< ≈ 1000 kbps) works fine. In android app it seems fine. Also media control works fine on browser with Substital extension. Media files are mounted with rclone on the servers. 

[Abobader 3290]

Hello devil202,

** 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

[Luke 39294]

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

[devil202 4]

30 minutes ago, Luke said:

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

So i need to provide the embyserver.txt log file?

[tomnjerry74 96]

Same thing has started happening for me recently. If you force transcoding it should let you seek and skip in the meantime.

[devil202 4]

Upon more investigating it looks like cloudflare is causing the issue. I am using cloudflare pro plan.

[devil202 4]

13 hours ago, tomnjerry74 said:

Same thing has started happening for me recently. If you force transcoding it should let you seek and skip in the meantime.

Are you using cloudflare too?

 

[tomnjerry74 96]

5 hours ago, devil202 said:

Are you using cloudflare too?

 

Interesting, yes I do use cloudflare.

[devil202 4]

3 hours ago, tomnjerry74 said:

Interesting, yes I do use cloudflare.

. Can you check if it works without cloudflare??? I have tested on everything almost. Jellyfin has the same problem with firefox but runs on chrome.

[Luke 39294]

Seeking uses http range requests. Most likely something is interfering with that.

[devil202 4]

mydomain {
tls /path/to/cert /path/to/key
reverse_proxy localhost:8096
log {
        output file /opt/caddy/logs/emby.log
        format single_field common_log
	}
}

This is my caddy config sir. This was working fine. Note that seeking issue is occurring with ≈ > 1000 kbps bitrate files only with direct play. All my media are in direct play friendly format. Same media plays without cloudflare fine. Plays with cloudflare if only transcoded. Can you kindly look into this ?

 

[tomnjerry74 96]

1 hour ago, devil202 said:

. Can you check if it works without cloudflare??? I have tested on everything almost. Jellyfin has the same problem with firefox but runs on chrome.

Going to do some testing when I get the chance.

[Jinhjy 2]

I have been facing the same issue. Issue only occurs with x264 mp4 files and have not noticed any other file type with this issue. Not sure if maybe re-adjusting my reverse proxy settings will help. Kind of stumped.

[tomnjerry74 96]

It seems to be a caching issue. When I turn on developer mode and purge all cache the issue goes away.

[tomnjerry74 96]

@devil202 @Jinhjy

Try changing your caching level from standard to "No query string", wait a minute or so and then see if the issue is gone. It worked for me.

Edited September 7, 2021 by tomnjerry74

[CarlosLima 150]

+1 with Cloudflare. 

[CarlosLima 150]

SOLVED.
Today I had 4 people who reported this error and now the same 4 have confirmed that the problem no longer exists.

Edited September 8, 2021 by CarlosLima

[Luke 39294]

Thanks for the feedback !

[Jinhjy 2]

@tomnjerry74 @CarlosLima @devil202
That fixed it. Interestingly I had initially had the setting for that already set as "No query string" from a while back. Seems something caused it to change. Thanks for the help guys!

Edited September 8, 2021 by Jinhjy
added tags

[devil202 4]

Thank you all for the help and feedback. I am no longer facing this issue after changing the cache setting. 

[Luke 39294]

Thanks for the update.

[vaise 324]

Hijacking this thread as I had a different issue posted in the beta forums where direct play file would take up to 50 seconds to start.  Another CF user in Australia confirmed the same thing.  Proved that developer mode fixes the issue, so something on cloudflare.

The same fix that you all put in also fixed that.  However - @pir8radiostated this is an incorrect setting as he posted the below - have you guys with this issue seen issues with no query string since you made the change ?  Have CF made a change that stuffed up the caching in some way ?It seems that according to @pir8radio, this change may just be a band aid over an undelying issue many of us are having with CF on emby.....

@pir8radio wrote this :

'you want query string, (STANDARD SETTING)   otherwise cloudflare will cache images and video file chunks that the first person started, and feed them to all users..  for example if size my browser window to really small,  all of images will be cached, then I resize my window to full screen, cloudflare will serve me the same smaller images that were cahced, now all pixelated.  But with query string it will cache different versions of the same image in the various sizes.    For example if you dont cache based on query string and i load the page with a small screen size Cloudflare will take this:  "/emby/Items/12737212/Images/Thumb?maxWidth=150&tag=69b098b0bc99197f41817f4298a5de63&quality=90"     and ignore the query string and just cached that 150px image as "/emby/Items/12737212/Images/Thumb"        then when someone with a big screen size comes along instead of getting this image: "/emby/Items/12737212/Images/Thumb?maxHeight=169&maxWidth=300&tag=69b098b0bc99197f41817f4298a5de63&quality=90"      so now that user will get a 150px image instead of a 300px image.' 

[pir8radio 1304]

16 minutes ago, vaise said:

Hijacking this thread as I had a different issue posted in the beta forums where direct play file would take up to 50 seconds to start.  Another CF user in Australia confirmed the same thing.  Proved that developer mode fixes the issue, so something on cloudflare.

The same fix that you all put in also fixed that.  However - @pir8radiostated this is an incorrect setting as he posted the below - have you guys with this issue seen issues with no query string since you made the change ?  Have CF made a change that stuffed up the caching in some way ?It seems that according to @pir8radio, this change may just be a band aid over an undelying issue many of us are having with CF on emby.....

@pir8radio wrote this :

'you want query string, (STANDARD SETTING)   otherwise cloudflare will cache images and video file chunks that the first person started, and feed them to all users..  for example if size my browser window to really small,  all of images will be cached, then I resize my window to full screen, cloudflare will serve me the same smaller images that were cahced, now all pixelated.  But with query string it will cache different versions of the same image in the various sizes.    For example if you dont cache based on query string and i load the page with a small screen size Cloudflare will take this:  "/emby/Items/12737212/Images/Thumb?maxWidth=150&tag=69b098b0bc99197f41817f4298a5de63&quality=90"     and ignore the query string and just cached that 150px image as "/emby/Items/12737212/Images/Thumb"        then when someone with a big screen size comes along instead of getting this image: "/emby/Items/12737212/Images/Thumb?maxHeight=169&maxWidth=300&tag=69b098b0bc99197f41817f4298a5de63&quality=90"      so now that user will get a 150px image instead of a 300px image.' 

it just basically means you are not caching anything that has a query string.. which is like everything in emby.. lol   those of you that changed this value I bet if you load up your emby server in chrome, bring up developer mode, and on the network tab right click the header go down to "response headers" then "manage response headers"   then finally the button "Add custom header"    add in   cf-cache-status     this will show you what cloud fare is caching from your emby, bet those of you that made this change have almost no hits. 

Should look similar to this:

  

 

You probably see lots of "MISS" if I am correct.    but if you are ok with nothing getting cached, no need to worry..  you will just loose out on the speed of serving images from the server closer to the user (speed), and also means more bandwidth from your emby server vs only going out from cloudflare. 

 

Here is me testing with my "Standard Cache" CF settings:   Unless I am misunderstanding the issue....  we may want to look at a rule to not cache any .ts files.

Edited September 20, 2021 by pir8radio

[tomnjerry74 96]

1 minute ago, pir8radio said:

it just basically means you are not caching anything that has a query string.. which is like everything in emby.. lol   those of you that changed this value I bet if you load up your emby server in chrome, bring up developer mode, and on the network tab right click the header go down to "response headers" then "manage response headers"   then finally the button "Add custom header"    add in   cf-cache-status     this will show you what cloud fare is caching from your emby, bet those of you that made this change have almost no hits. 

Should look similar to this:

  

 

You probably see lots of "MISS" if I am correct.    but if you are ok with nothing getting cached, no need to worry..  you will just loose out on the speed of serving images from the server closer to the user (speed), and also means more bandwidth from your emby server vs only going out from cloudflare. 

Thanks for the info. For now I don't really see much of a choice unless we sacrifice the main functions of the server. Loading speed is moot when you can't even play content .

[vaise 324]

I will wait and see what all the others that made this change are getting/seeing.

From my experience, the remote complaints I had are now gone.

I don't know how much the actual caching was doing for the end users.  I only have one remote user on a browser, the rest are on apps of one sort or another.