When you’re personally confident that you won’t be rolling back.
I tend to keep the previous backup as each version is successfully updated.

ie I was running 10.10.7, I still had 10.10.6 sitting there, but I deleted it after successfully upgrading to 10.11.0.

Several people have experienced this error: https://github.com/jellyfin/jellyfin/issues/15058

It appears to be when the config of jellyfin lists the cache and the transcode in the same path (or if the transcode directory is within the cache directory).
My understanding is that as the image starts, it writes these hidden dot files (.jellyfin-cache and .jellyfin-transcode) and checks for their existence before it will continue with the next load step.
Hence why they keep coming back when you delete them.
Complicating this is that if you are running jellyfin inside docker, the external mounts can confuse the internal mounts.
(ie INSIDE the docker image you have them in /cache and /transcode, but OUTSIDE you have transcode and cache both mounted in /home/untouchedwagons/jellyfinstuff/)

Within your running instance of 10.11.0, make sure the configuration for cache and transcode are in complete different directories (ie /cache and /config/transcoding-temp/), then shutdown the server (to save that configuration change).

If that’s not clear, a little more info will be useful for diagnosing this.

If you can log into the site, it’s done.
If you try to access the site and you get a “startup log” page, it’s still ongoing (and it will show you there what it’s doing).
https://jellyfin.org/posts/jellyfin-release-10.11.0/#startup-ui-and-log-viewer

Yes, the update should only affect the Jellyfin specific things (databases, configs, metadata). Your media itself is only deleted/modified under very limited and specific circumstances, and you can (and many people do) choose to mount the media read only.

I think the feel from the Devs is that there isn’t enough new functionality to justify the major version bump, this primarily being a reimplementation of existing features.

BUT, I agree with you, it should definitely be V11 under the semantic versioning scheme.
Whilst there is a migration path here, the database changes under the hood alone are likely to break backwards compatibility with all plugins (with in-house plugins being upgraded in sync).
Such breakage is kind of the defining characteristic of a MAJOR version.

Backup of the jellyfin cache, Configs and database.
Your media should be outside of all that. Exactly where those things are depends on your exact install method (native/docker/Linux/windows). https://jellyfin.org/docs/general/administration/backup-and-restore/

Looks like this is it: https://github.com/jellyfin/jellyfin/pull/13451 Also looks like the intention is to stabilise the new data layer before adding extra backends to avoid rework.

Finamp beta works with android auto (although I’ve experienced a bug when starting finamp from the android auto screen).

Hopefully the current Hackathon makes it even better: https://github.com/users/jmshrv/projects/5/views/1

The OTHER thing that could cause stuttering is if it needs to be transcoding and that transcode is happening slower than realtime (unlikely to be happening here).

You’d look in the logs for a transcode log for this sort of thing:

frame=  408 fps= 82 q=37.0 size=N/A time=00:00:15.51 bitrate=N/A speed= 3.1x  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c875.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c876.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c877.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c878.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c879.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c8710.mp4' for writing  
frame=  796 fps=145 q=30.0 size=N/A time=00:00:31.65 bitrate=N/A speed=5.75x  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c8711.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c8712.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c8713.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c8714.mp4' for writing  
[hls @ 0x5c9ae0dde940] Opening '/config/transcoding-temp/transcodes/2d181c04b2b6d7ab2bdc2405c6ae5c8715.mp4' for writing  
frame= 1189 fps=198 q=20.0 size=N/A time=00:00:48.04 bitrate=N/A speed=8.01x

if the speed drops below 1.0x, you’ll stutter.

Not a fix to a known issue, but sometimes cache problems can cause this, so it’s worth clearing the storage and cache on the android app.

After you log in again and can reproduce the problem, then a bug report is in order :-)

Jellyfin Server 10.10.3
General Changes

• Exclude file system based library playlists from migration [PR #13059], by @Shadowghost  
  

• Downgrade minimum sdk version [PR #13063], by @crobibero  
  

Jellyfin Web 10.10.3
General Changes

• Backport translations for 10.10.3 [PR #6326], by @thornbill
  

Have you told the library to rescan after making the change?