Jump to content

Fast forward, seek bar not working on web player


devil202
Go to solution Solved by tomnjerry74,

Recommended Posts

devil202

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. 

image.png

image.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

tomnjerry74

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

Link to comment
Share on other sites

devil202
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?

 

Link to comment
Share on other sites

devil202
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.

Link to comment
Share on other sites

devil202
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 ?

 

  • Agree 2
Link to comment
Share on other sites

tomnjerry74
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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

tomnjerry74

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

  • Like 1
  • Agree 1
Link to comment
Share on other sites

  • Solution
tomnjerry74

@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.

image.thumb.png.1cd77f7c90af4a9adffe5900c91f4e21.png

Edited by tomnjerry74
  • Like 3
  • Agree 1
Link to comment
Share on other sites

CarlosLima

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

download.png

Edited by CarlosLima
  • Like 2
  • Agree 1
Link to comment
Share on other sites

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.' 

  • Agree 1
Link to comment
Share on other sites

pir8radio
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:

 image.png.d961b1eaad3e3ff121585e25c538274f.png 

 

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. 

image.png.23c47edc5666d460c6bd0852abf80e1c.png

 

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 by pir8radio
  • Like 1
Link to comment
Share on other sites

tomnjerry74
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:

 image.png.d961b1eaad3e3ff121585e25c538274f.png 

 

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. 

image.png.23c47edc5666d460c6bd0852abf80e1c.png

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 😭.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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