The word "run" in the Kometa context can be used in two ways; you "run" the Kometa Python script itself, using a Python or docker command, and then that script behaves in one of two ways:
1. It sits and waits until a particular time, wakes up and processes the config file, then goes back to sleep until that same time the next day. Kometa does this unless you [specifically tell it to do otherwise](#run).
2. It processes the config file right away and then exits.
"Processes the config file" means that it will go through all the collections, metadata, overlays, playlists, and libraries that you have defined in your config file and do what you have told it to do with them.
That's kind of a mouthful, though, so we typically use "run" to describe that bit of the process.
In these docs, and in the discord when providing support, we'll use "run" to describe the "process the config file" bit.
The basic command to execute Kometa is as follows:
If you want to modify the way Kometa behaves when it runs, you can use the commands on this page. None of these are *required* to run Kometa. They are all optional and can be used to customize the way Kometa runs to suit your needs.
Many of these override settings in the config file, so you can use them to change the way Kometa behaves without having to edit the config file.
On all platforms, "environment variables" are a way to set variables that are available to all programs running on the system. You can set these variables in your shell, in a script, or in a Docker container.
You might think of this as a note on your desk that tells you Sue likes a skim latte when you go to the coffee shop. You can use that note to remember what Sue likes when she asks "please get me a coffee".
Runtime flags are command line arguments that you can pass to Kometa when you run it to change the way it behaves.
You might think of this as a directive Bob adds when he asks "please get me a coffee, a **flat white**". At "runtime", Bob is adding a "flag" to his request to indicate the type of coffee.
All these settings have defaults, which you can think of as the "standard coffee" that you get if someone doesn't specify anything. If Chris doesn't specify a type of coffee, and you have no note about Chris, Chris gets the **default**, a **plain black coffee**.
If you don't specify a runtime flag or environment variable, you get the standard/default behavior.
## Runtime Flags vs Environment Variables; who wins?
The ridiculous example above notwithstanding, in Kometa, environment variables take precedence over runtime flags.
For example, and it's not important what this does, but if you were to use the following script:
```shell
export KOMETA_CONFIG=/path/to/environment/config.yml # this sets an environment variable
python kometa.py --config /path/to/runtime-var/config.yml # runtime flag for the same setting
```
Kometa would use the config file at `/path/to/environment/config.yml` because the environment variable takes precedence over the runtime flag.
Please note that these instructions assume that you have a basic understanding of command line and Docker concepts. If you need to familiarize yourself with Docker, you can check out the official tutorial.
## I want to set a lot of these things, what's the best way?
One way to specify environmental variables is by adding them to a .env file located in your config folder.
That file would contain something like:
```env
KOMETA_CONFIG=/path/to/your-config-file.yml
KOMETA_TIMES=06:00,18:00
KOMETA_TRACE=true
KOMETA_LOG_REQUESTS=true
KOMETA_TIMEOUT=360
KOMETA_NO_VERIFY_SSL=true
KOMETA_COLLECTIONS_ONLY=true
```
Kometa will load those environment variables when it starts up, and you don't have to remember to set them every time you run Kometa.
Some Commands or Variables can be combined in a single run, this is mainly beneficial when you want to run a specific command and have it run immediately rather than waiting until the next scheduled run.
For example, if I want to run [Collections Only](#collections-only) to only run Collection Files, and [Run Immediately](#run) to skip waiting until my next scheduled run, I can use both commands at the same time:
<divid="config"/>Kometa looks for its config file at `config/config.yml`. If you want to change that, perhaps to use a special-purpose `config.yml` or the like, you can use this flag to specify the location of the configuration YAML file.
<divid="times"/>Kometa wakes up at 5:00 AM to process the config file. If you want to change that time, or tell Kometa to wake up at multiple times, use this flag.
<divid="log-requests"/>If you enable this, every external network request made by Kometa will be logged, along with the data that is returned. This will add a lot of data to the logs, and will probably contain things like tokens, since the auto-redaction of such things is not generalized enough to catch any token that may be in any URL.
**This can potentially have personal information in it.**
<divid="timeout"/>Change the timeout in seconds for all non-Plex services (such as TMDb, Radarr, and Trakt). This will default to `180` when not specified and is overwritten by any timeouts mentioned for specific services in the Configuration File.
**Accepted Values:** Pipe-separated list of Collection, Metadata or Playlist Filenames to run; the "pipe" character is "|" as shown in the examples below.
<divid="ignore-ghost"/>Kometa prints some things to the log that don't actually go into the log file on disk. Typically these are things like status messages while loading and/or filtering. If you want to hide all ghost logging for the run, use this flag.
??? blank "No Countdown `-nc`/`--no-countdown` `KOMETA_NO_COUNTDOWN`<aclass="headerlink"href="#no-countdown"title="Permanent link">¶</a>"
<divid="no-countdown"/>Typically, when **not** doing an [immediate run](#run), Kometa displays a countdown in the terminal where it's running. If you want to hide this countdown, use this flag.
??? blank "No Missing `-nm`/`--no-missing` `KOMETA_NO_MISSING`<aclass="headerlink"href="#no-missing"title="Permanent link">¶</a>"
<divid="no-missing"/>Kometa can take various actions on missing items, such as sending them to Radarr, listing them in the log, or saving a report. If you want to disable all of these actions, use this flag.
??? blank "No Report `-nr`/`--no-report` `KOMETA_NO_REPORT`<aclass="headerlink"href="#no-report"title="Permanent link">¶</a>"
<divid="no-report"/>Kometa can produce a report of missing items, collections, and other information. If you have this report enabled but want to disable it for a specific run, use this flag.
<divid="read-only-config"/>Kometa reads in and then writes out a properly formatted version of your `config.yml` on each run; this makes the formatting consistent and ensures that you have visibility into new settings that get added. If you want to disable this behavior and tell Kometa to leave your `config.yml` as-is, use this flag.
<divid="divider"/>The log is split into sections with lines of `=`. If you wish to change that character to a different one, you can do that with this flag.
<divid="width"/>The log is formatted to fit within a certain width. If you wish to change that width, you can do that with this flag. Not that long lines are not wrapped or truncated to this width; this controls the minimum width of the log.
