Custom menu links & caching

[Rezer]

So I went ahead and followed the directions at https://jellyfin.org/docs/general/client...menu-links to add a link to jellyseerr, and while the configuration process was fairly straight forward the link has this annoying habit of not showing up for any browser that has been logged in previously.  It works in an incognito tab well enough, and I can force the links to show up by hitting Ctrl + F5, but if I then refresh normally or close and reopen the site the link disappears again.  The only way I've found to get the link to show up reliably is by opening browser settings and selecting "clear cookies and site data" (clearing cache alone doesn't do the trick).

That's all fine and well for my own browser, but I'd rather not ask everybody that has access to my server to clear all their cookies every time I update some links in jellyfin.  Is there some kind of secret sauce here for getting the config.json changes to take for clients that haven't cleared all their cookies?  I had hoped the caching would sort itself out given enough time, but it's been over 24 hours now and I'm starting to doubt that's going to happen.

Edit: Just in case it matters, I'm running jellyfin in docker and have also remapped /jellyfin/jellyfin-web/config.json within the container to web-config.json on the host.

[LeviSnoot]

I'm not sure what cookies have to do with this tbh, my understanding is that they're mainly used to store things like user sessions and preferences.

I asked ChatGPT to explain the difference between cookies and cache in laymans terms because I was a bit unsure myself, and it provided the following analogy:

Imagine you're at a café (which represents a website) and you order a coffee (which is a web page). Now, here's how the concepts of HTTP cookies and cache work in this context:
HTTP cookies are like the café staff noting down your preferences. Let's say you ordered your coffee with a bit of sugar. The staff remembers this and prepares your coffee with sugar each time you visit. Similarly, when you visit a website, it might give your web browser a cookie, a small piece of data that remembers things like your username, preferences, or items you put in a shopping cart. This helps the website recognize you and provide a personalized experience, like remembering your login details or keeping items in your cart even if you leave the site.
On the other hand, the cache is like a barista keeping a copy of the coffee menu handy. When a lot of people order the same coffee, the barista doesn't have to look at the recipe book every time. They just refer to the handy copy and make the coffee quickly. Similarly, when you visit a website, your browser stores certain parts of the website, like images or files, in its cache. So, if you visit the same website again, your browser can quickly retrieve these stored parts instead of fetching them all over again, making the website load faster.
In short, HTTP cookies remember your preferences and help websites remember you, while cache stores parts of a website to make it load faster when you visit it again.

I verified this information by checking the MDN web docs for caching and cookies.

I am having the same issues as you, OP, and so I wanted to try creating a cache rule for my Nginx reverse proxy virtualhost for Jellyfin. You didn't mention if you're using a reverse proxy at all, but I'll assume you are since you mentioned serving multiple users in your post.

I found this documentation entry for Nginx helpful. It outlines how to define cache headers for your host. Using that information I haphazardly placed the following in the server block for my virtualhost:

Code:

# Set caching headers for the entire server block
    add_header Cache-Control "public, max-age=43200";
    set $expires_time 43200;
    add_header Expires $expires_time;

After clearing the site data for my Jellyfin instance I was able to verify that the new caching headers did appear. The code above basically tells the visitors browser to cache responses for up to 12 hours, and then check if something has changed after that.

I'm hoping this will solve the issue, but I won't know until I've had some of my users verify it, which will take time. I just also want to add the disclaimer that I'm just a beginner at this stuff and I wouldn't recommend people just throw this into their configs without knowing what it does.

I'm also not sure if this happens because Jellyfin caches responses itself. If that's the case it doesn't really matter what I do with Nginx as the root cause of the problem would be with Jellyfin itself. Hopefully this helps though.

[Rezer]

I am running nginx proxy manager to handle reverse proxying, but I don't have additional caching turned on there.

I went ahead and tried your suggestion with updating the caching policy, and I even tried setting it to an obscenely short amount of time (5 seconds) just to see if it made a difference. I seem to have it configured properly as the headers are coming through as expected according to the developer console, but there's been no change in the behavior. I really wanted it to work, but it makes sense that it didn't...I've tried clearing the cache manually several times, and it made no difference. Perhaps when clearing "cookies and site data" it's not the cookies that matter, but the site data? Unsure what's even saved locally and how to force that to update via the site configs.

In any event, this problem has persisted up til now, 2 weeks after I've added the sidebar links. Any browser that's accessed the site before config.js was updated still fails to show the links unless a full refresh is forced using ctrl + F5, and then they disappear again the next time the page is refreshed normally. It's very strange...

Oh, and definitely thanks for posting what you've tried, at least now I know it's not just me.

[Rezer]

Well I don't have a resolution but I do have more information about the root cause of this one and a workaround.

It seems this is indeed coming from items stored under "Cache Storage" as identified in the firefox developer console.  Despite this name, clearing the cache leaves all the items intact here...the following screenshot was taken immediately after clearing the cache storage and before reloading the page (You'll have to forgive me for removing my server's domain name):

   

Right clicking workbox-precache-v2-https://domain.name/web/ and deleting it that way immediately resolves the issue without having to clear all site data from the browser, and it does not appear to come back after further edits to the config.json file.  I have not yet figured out under what circumstances workbox-precache-v2 gets created, but as of yet after loading the site multiple times, closing and reopening the browser, logging out and logging back in, watching several videos and so on, the only thing under "Cache Storage" is "embydata" which consists of a single url.  It seems as long as workbox-precache-v2 does not exist, then there's no issue...if it does, the sidebar links will remain cached indefinitely.

Note that while I did the above tests in firefox, the same issue was present while using Chrome.  I should also note that the changes I made previously to the cache expiry headers has already been removed as it did not seem to change the behavior of this issue.

[LeviSnoot]

This is really valuable info Rezer, I'm now led to believe the root cause of this issue is a Jellyfins service workers. I found a Github issue that appears to corroborate this: https://github.com/jellyfin/jellyfin-web/issues/4549

So what happens is, this service worker puts the entire /web/ directory in the visitors browser cache, and this directory includes among other files related to serving the web client to users, config.json.

There's a PR that is trying to mitigate this: https://github.com/jellyfin/jellyfin-web/pull/4885

Looks like we're not alone in finding this behaviour odd, and hopefully the PR gets merged so future versions of JF won't have this issue. For the time being though, I'm not sure how to work around it, but if I think of something, I'll update the thread!

[LeviSnoot]

Update: The PR has been merged and is on track to be included in Jellyfin v10.9.0!