Here is a quick list of things you can try if you encounter trouble.

• There is a "Cookie" Bug in the Jellyfin distribution: you may have to logon twice
• Two playback issues:
  1. An item won't play at all: try the Software Transcoding Server.

  2. The playback stutters

     • Initial Stuttering Playback: the video plays and then stops, plays and then stops repeatedly, but eventually, it streams without interruption.
     • Constant Stuttering Playback: the video plays and then stops, plays and then stops repeatedly.

If you get Initial Stuttering Playback, that is because the server has to deliver a lot of data initially to fill your Player's buffer. A good tip here is: the moment the playback has started, pause it for 30 seconds or so. You can then see the buffer fill up: it's the light gray segment in the timeline of the video, ahead of the blue played section.

If you get a Constant Stuttering Playback then the bit rate that the server is delivering data to you is too high for the player. You need to tell the server you want to use a lower bit rate. And there are two things you can do:

• Change it for the file you are viewing by using the Gear icon at bottom right of the play screen. Use the Quality control and set it to 720 kbps and see if that improves playback.
• If you want to change it permanently for your account, you can do that in your User preferences, see below

And, finally, you are able to download the file. You then receive it in its original format. And you must have software installed locally to play that file. VLC is available for all operating systems mentioned above. You can always try playing the file in your local browser after it has downloaded: use File -> Open or Drag'n'Drop on the desktop to an open browser pane, or you can try giving the file's URL directly in the OmniBox, that's usually the name, prefixed with file:/// or file://C:/.

If you reading this, then you should have already visited the Jellyfin media server. That means, you will have a valid login.

This server is part of a FOKUS project. It provides some digital streaming resources for use by Multi-media Professionals.

As a user, you'll be expected to file activity and bug reports at the project web-site and these should include content and feature requests. The remainder of the documents helps you collect information and to use your account on the server.

The well-known browsers all work with the site. It should appear like the demonstration site provided by Jellyfin. The colours and fonts and layout should be nearly identical.

The first issue is well-known. You may have to login twice. This is an issue with the cookies. If you use a Browser key sequence to refresh, if you have not chosen "Remember Me", you will need to login again.

• Chrome, FireFox, Edge are being tested internally, but your contribution for individual media types is hoped for.
• Safari, Brave, Opera have had testers assigned and you may be one of them.
• Other browsers, such as Chromium, Midori are not currently supported.
• Operating systems: Windows 10 or later, MacOS 14 (Sonoma) or later, ChromeOS 134 or later, Linux Ubuntu, Debian, Mint - LTS or stable releases. ChromeOS also includes its LXC container system.

You should prepare yourself for reporting.

1. Have a backup browser able to access the project site, that is, one that has authorized access.
2. Be able to conduct local diagnostics:
   • ping network connectivity tests
   • time-logged network loading tests

You will need to report your operating environment.

Versions: browser and operating system.

Record version numbers in machine-readable form now.

Hardware: GPU, CPU and RAM

You will need to snapshot the operating condition of your system when faults occur.

Screenshots and videos

You will need to be able: to quickly make screenshots of faults; record sequences of operations that result in faults with videos.

GPU support: you should try and enable your browser to use the GPU. It is usually enabled by default, but it is useful for us to be able to see how the GPU is being used. Chrome gives a very detailed summary in: chrome://gpu/ and other Chrome flags can be found with chrome://chrome-urls/. Other browsers can also provide GPU configuration information.

Web 2.0 and compliant browsers use the H.264 encoding for the standard HTML player. Within Jellyfin, you can see how a media file has been encoded.

Media files have:

• A container: usually given by the filename extension: .mp4 for an MPEG4 container, Motion Pictures Expert Group; .avi for AVI, Audio Visual Interleaving; .mkv for Matroska. Microsoft and Apple have their own containers: MS MP4 and QuickTime. Within Jellyfin this information can be obtained from "Media Info".
• Encoded content: usually H.264 (AVC), but also DiVx or XVid - these are called the MPEG4 encodings because they were, originally, the only encodings that could be placed in MPEG containers. Microsoft and QuickTime have their own content encodings. And there are others: H.265 (HEVC) and X.264 X.265 are other industry standards. See this discussion for more details
• These encodings are then streamed using a transport encoding: the current standard is HEVC - High Efficiency Video Coding (also known as H.265); AV1 (the digit one, 1) - a newer standard. There are others including the format used for Digital TV, MPEG2. This information is only available when the video is streaming. Use the Gear icon on the playback screen and find "Playback Info".

Because of this variety, it can be the case that there is a mismatch in encodings. To recap, within Jellyfin, you can find out the underlying media type with "Media Info" and the transcoding used to deliver it to your browser is available with "Playback Info".

The operation of Jellyfin is to deliver the media content to your browser in a format that can be processed by your browser. It will transcode the media from its original encoding to a standard one: H.265 or HEVC. The H.264 file encoding is a null transcode: the server GPU only has to copy the file into the HEVC streaming format.

.

Transcoding is needed when:

• A non-H.264 file encoding is used.
• There is a bit-rate mismatch.

The "Playback Info" will show you if any transcoding is being done. Mismatched bit-rates can be annoying and we hope you will report this problem when it arises.

Jellyfin and other content streaming systems are not able to match the player's bit-rate with the server's. They rely on buffering at the player to collect and play the content. Usually, this is sufficient, files that have video encoded to SD (Standard Definition) 720p, and HD (High) 1080p can usually be delivered to a player with very little buffering.

But two issues can arise:

• Network Loading
• UHD (Ultra High Definition) files - such as "4K" or even "8K"

Network loading is usually at the Edge. Either the Server cannot send because its local network is congested or the Player cannot receive because its is. And usually the problem is the Player's network. WiFi connections are easily congested. And, at peak times of the day - after 6pm to about 11pm - the uplink from the Player's network to the Internet can be congested. When playing videos, you are downloading, but if you are uploading at the same time, you will degrade your download speed.

If you believe your network is congested, it is possible to adjust the delivery bit rate for a file or for all files.

To adjust it for the file, you must start playing the file and use the Gear icon on the player screen for the media and then adjust the quality. 720 bps gives SD quality playback.

To adjust the bit rate for all files transcoded, you must change the default in the User's settings. Within Jellyfin, the head and shoulders icon is the User Preferences menu and there navigate thus:

User Preferences -> Playback -> Home network quality
                    

It is, by default, "Auto", but this simply means it will use the file's own bit-rate and then rely on buffering to smooth the delivery. The stated maximum for Home network quality is 120 Mbps (mega bits per second).

Most domestic ADSL Internet connections claim to receive 1000 Mbps. 5G standard is 300 Mbps and 600 Mbps for high quality. 4G and LTE (mobile networks) have a maximum of 300 Mbps, but usually only 2 Mbps is feasible in congested areas because 100's of users occupy the "Cell".

Dealing with Ultra-High Definitions files is very much the same. You have to reduce the Quality or your Playback maximum in Preferences.

What happens when you adjust the quality is that you instruct the server to transcode the file at the new lower bit rate. This means the server has to discard its current transcoding and produce a new one - you may get an Initial Stuttering Playback. This process is similar for changing audio tracks or embedded sub-titles. The file must be newly transcoded to carry the new audio track, the new choice of embedded sub-titles or the new bit rate for the client.

There are better streaming protocols, but they are usually proprietary and require licensing.

There is a second server on Rhaenys. This is a software transcoder and should be more robust than the standard server. It has the same content as the standard server. If you do experience fatal playback problems - the file simply won't play - then see if it is possible to play the file with Rhaenys and report that to the project.