Your server's own settings

Almost everything about your Navarre server is set from the apps. A few things live in one file on the server itself, beside its database, and this page is that file's guide: where it is, the lines a household may want to change, and how to restart your server so a change takes. Changing it needs two things: access to the server's data folder, and the ability to restart the server.

On this page: where the file is, restarting your server, Quick Connect, a lost password, finding the server by itself, the graphics chip, the nightly copy, and the compose file.

Try the apps first. On your TV or in Navarre for Windows, the owner's Settings → Server settings page switches the nightly copy, and letting devices find the server by themselves, on and off without touching this file, on a server that has those switches. This page is for the rest.

Where the file is

It is called navarre-server.json, and it sits in your server's data folder, beside navarre-server.db. The data folder is the one you named for the server's own data when you set it up:

On a NAS: the data folder you gave Navarre during the NAS setup (the example file there calls it /volume1/navarre-data). Your NAS's own file manager can open the file and edit it in place.
On a Linux box: the data folder you gave Navarre during the Linux setup (the example there is /srv/navarre-data).
On a Windows PC: C:\NavarreServer\data, the folder the Windows app made for it.

If you are not sure which folder it is, your compose file says: it is the left-hand side of the volume line that ends in :/config.

Edit that one, and only that one. If your server was ever started from a separate first-boot settings file, in a seed folder, that copy was read once, on the first boot of an empty data folder, and changing it now changes nothing at all.
Keep a copy of the file before you change it, and keep it valid JSON. A file that is not valid JSON stops your server from starting, and its log says so.
Where this page shows a line or a block, change it if your file already has it. If it does not, add it on lines of its own just after the file's opening {, which is where the comma that ends it belongs.
A change takes when your server next starts. Save the file, then restart your server.

How to restart your server

Pick a quiet moment: a restart interrupts anybody who is watching.

On a NAS: open your NAS's Docker app (Docker Manager, Container Manager, or Container Station, depending on the box), stop the project you made for Navarre, and start it again.
On a Linux box or a Windows PC: run this in a terminal (on Windows, in PowerShell):
```
docker restart navarre-server
```

It comes back on its own and looks through your folders again in the background while the apps carry on. On a small library that takes seconds, and on a large one a few minutes.

Reading the log

When your server starts, its log says what it took - which way the nightly copy is set, for example - so the log is how you see that a change landed.

On a NAS: your Docker app shows each container's log on that container's own page.
In a terminal: docker logs --tail 40 navarre-server shows the last forty lines.
In the data folder: a rolling copy lives under logs, kept for fourteen days.

To send it with a support request, save the last day of it to a file and attach that file to your email to support@navarre.tv:

docker logs --since 24h navarre-server > navarre-log.txt

The settings worth knowing

Each one is shown the way it is written in the file. Change it, save, and restart.

Quick Connect

Quick Connect lets a television or a phone that cannot easily type a password sign in with a six-digit code instead. Somebody on a device that is already signed in opens Settings → Quick Connect in Navarre and approves the code, and the new device is signed in as them.

Your server ships with it off. This is the line that turns it on:

"QuickConnectEnabled": true,

Change false to true on that line, or add the line if your file does not have it, then restart your server. Setting it back to false and restarting turns it off again.

If the owner's password is lost

There is no way to reset a password over the network, and that is on purpose: anybody who could would only need to be on your home network. Getting back in needs somebody who can open the data folder and restart your server, and it takes about two minutes.

Open the file in your server's data folder, and keep a copy of it first.
Add this block, with one entry per account:
```
"RecoverPasswords": [
  { "Name": "the account name", "NewPassword": "the new password" }
],
```
If your file already holds an example of this block, under a key that begins // RecoverPasswords - EXAMPLE, rename that key to RecoverPasswords and fill it in instead.
Save, and restart your server.
Sign in with the new password, from any Navarre app.

The file forgets the password for you. On that start your server sets it, then empties the block and leaves the note // PASSWORDS RECOVERED AND THE BLOCK CLEARED beside it, so there is nothing to remember to delete. The log names each account it changed, and never the password.

Any account, not only the owner's. The same block sets a new password for a household member who has forgotten theirs.
It never creates an account. It changes the password of one that already exists. A name that matches no account is a warning in the log and nothing else.
Two passwords are refused, and your server will not start until the file is fixed: an empty one, because no account may be left without a password, and the placeholder SET-THIS-BEFORE-FIRST-BOOT. The log names the account and which of the two it was. Fix the value, or delete the block, and start your server again.
Nothing else about the account changes - not its role, not which libraries it can see, and not its watch history - and devices already signed in as that account stay signed in.

Two things that are not a forgotten password. "Too many tries just now" is the sign-in limit: it clears by itself after a short wait, and at once when your server restarts. And one device refused while the others work is that device's own sign-in gone stale, not the password: sign that device in again.

Finding the server by itself

This is what lets the apps find your server on your home network by themselves, so a television can sign in without anybody typing an address:

"Discovery": { "Enabled": true },

It also needs your server to share the machine's own network. On a NAS or a Linux box, the file Navarre writes already does that with its network_mode: "host" line. On a Windows PC, Docker Desktop has no such mode, so the apps cannot find the server by themselves there: type its address once instead, as the PC setup explains.

If a television cannot find a server that runs on a NAS or a Linux box, check both: this line, and that one in your compose file. On your TV and in Navarre for Windows, the owner's Settings → Server settings page can switch this on and off too, on a server that has that switch.

Converting video on the graphics chip

Your server converts video on its processor unless it is told otherwise, and that always works. On a NAS or a Linux box with an Intel graphics chip, it can use the chip instead, which is faster and costs the machine less. It takes a check, two changes, and a fresh start.

Check that the machine can do it, in a terminal on that machine:
```
docker exec navarre-server /opt/navarre/qsv-smoke.sh
```
Go by the number it exits with - echo $?, typed straight after it, prints that number: 0 means the chip really converted video; 4 means it skipped and printed why - a machine with no such chip is only one of the reasons; 1 means something that had to work did not, so leave this setting alone.
In the file, name the chip in the Transcoding block, and keep anything else already in that block beside these two:
```
"Transcoding": { "HardwareAccel": "qsv", "QsvDevice": "/dev/dri/renderD128" },
```
In your compose file (on a NAS, the project's file in your Docker app), pass the chip through to the server with this line under navarre-server:
```
    devices: ["/dev/dri:/dev/dri"]
```
The file Navarre writes leaves it out on purpose: on a machine without the chip, that line stops the server from starting at all.
Start the project again from its compose file, as the compose file section says. The log then reads transcoding Qsv on /dev/dri/renderD128.

A misspelled value is not a fault: the log says the server does not know it, and it carries on converting on the processor. To go back, delete those two keys and restart. The apps cannot read this setting back yet, so the log line is how you know it took. On a Windows PC, through Docker Desktop, there is no graphics-chip conversion at all.

The nightly copy

Your server can take a copy of its own database on a schedule: every library, every account, and everything everybody has watched and where they got to. Your films are not in it - they are already on your own drive, and your server has never been able to write to them - so a copy is small, and it is the one thing here that cannot be rebuilt.

It ships off. On your TV or in Navarre for Windows, the owner's Settings → Server settings page turns it on with no restart, on a server that has that switch. Otherwise it is this block in the file, then a restart:

"Backup": { "Enabled": true, "KeepLast": 7, "IntervalHours": 24,
            "QuietWindow": { "Start": "01:00", "End": "06:00" } },

Everything except Enabled may be left out. The log then says which way it took, in one line:

backup on | every 24.0 h | window 01:00-06:00 | keep 7 | /config/backups

Where the copies land: in your server's data folder, under backups, one folder per copy, named for the moment it was taken (backups/<time>Z/). Every copy is checked and re-opened before it is kept, and one that fails is thrown away rather than left under a name you would reach for later.
The window runs on your server's clock, which is the time zone on the TZ line of its compose file. Left at UTC, a window meant for the small hours runs in somebody's evening.
Take one by hand after turning it on, with Take a copy now in the same place in the apps, rather than waiting for the night. You find out whether the disk can be written to at a time of day when you can still do something about it.

Putting a copy back

A restore is a file copy, and it happens before your server starts, which is why no screen can do it.

Stop your server: in your NAS's Docker app, or with docker stop navarre-server in a terminal. Putting files back under a server that is holding them open is the one way to make this worse.
Move the data folder aside rather than deleting it - rename it, for example from data to data.before-restore - and make a new, empty folder under the old name.
Take the four files of the copy you want out of its backups/<time>Z/ folder (inside the one you moved aside), and put them in that empty folder: navarre-server.db, server-id, navarre-server.json, and setup-state.json. Leave manifest.json behind: it describes the copy and is not part of a data folder.
Start your server again.

server-id is the one that matters most. It is your household's pairing identity: a restore without it would come up looking perfect, libraries and films and all, and every television and phone in the house would have to be paired again. Artwork and subtitles fill back in by themselves, because they are made from your own files; the first few posters are slower, and nothing else is different.

The compose file

The compose file is the recipe your server starts from: the one you pasted into your NAS's Docker app or saved on a Linux box, or C:\NavarreServer\docker-compose.yml, which the Windows app wrote. The NAS page explains it line by line. Three of its lines are worth knowing:

The image line names your server's exact version, the number after the colon in ghcr.io/navarredr/navarre-server:<version>. It is never latest: a version you cannot name is a version you cannot go back to. Changing it is how you update, and changing it back is how you go back - Updating has the steps.
The data folder's line, under volumes, ends in :/config. Its left-hand side is the folder this page is about.
The TZ line is your time zone, so the nightly copy's window and the nightly look through your folders happen in your night rather than somebody else's.

A change to the compose file itself takes when the project is started again from it, not on a plain restart: in your NAS's Docker app, stop the project and start it; on a Linux box, run docker compose up -d in the folder that holds the file; on a Windows PC, run docker compose -p navarre-server up -d in C:\NavarreServer.

↑ back to the top

Stuck anywhere? The Help & FAQ covers the questions people actually hit, and support@navarre.tv reaches a human. Keeping your server up to date is one line and two commands.