Files
truecharts/charts/stable/dispatcharr/values.yaml
T
TrueCharts Bot 1fda2be3c4 fix(dispatcharr): update image docker.io/dispatcharr/dispatcharr 0.27.1 → 0.27.2 (#49705)
This PR contains the following updates:

| Package | Update | Change |
|---|---|---|
|
[docker.io/dispatcharr/dispatcharr](https://redirect.github.com/Dispatcharr/Dispatcharr)
| patch | `f5cbc82` → `f2b5ea3` |

---

> [!WARNING]
> Some dependencies could not be looked up. Check the [Dependency
Dashboard](../issues/18710) for more information.

Add the preset `:preserveSemverRanges` to your config if you don't want
to pin your dependencies.

---

### Release Notes

<details>
<summary>Dispatcharr/Dispatcharr
(docker.io/dispatcharr/dispatcharr)</summary>

###
[`v0.27.2`](https://redirect.github.com/Dispatcharr/Dispatcharr/blob/HEAD/CHANGELOG.md#0272---2026-06-30)

[Compare
Source](https://redirect.github.com/Dispatcharr/Dispatcharr/compare/v0.27.1...v0.27.2)

##### Added

- **New proxy setting: Client Connect Grace Period
(`channel_client_wait_period`, default 5s).** Adds a dedicated timeout
for channels that have filled their buffer but still have no viewers
(`waiting_for_clients`). Previously that window reused
`channel_shutdown_delay` (default 0s), so those channels were torn down
almost immediately.

##### Changed

- **Proxy grace-period settings are now split into three distinct
timeouts.** The cleanup watchdog already applied
`channel_init_grace_period` while a channel was still connecting (buffer
not ready) and reused `channel_shutdown_delay` once
`connection_ready_time` was set, including for `waiting_for_clients`
with zero viewers. With the default `channel_shutdown_delay` of 0s, a
buffered channel waiting for its first viewer was stopped almost
immediately; raising shutdown delay was the only workaround, but that
also delayed teardown after real disconnects. Behaviour is now:
- **`channel_init_grace_period` (default 60s, max 300s):** how long the
proxy may spend connecting and cycling failover streams before giving up
on startup.
- **`channel_client_wait_period` (default 5s):** how long a ready
channel with no viewers stays up waiting for the first client (the
original grace-period use case).
- **`channel_shutdown_delay` (default 0s):** delay after the last client
disconnects only; no longer applies when the buffer is ready but no
viewer has connected yet.
- **Migration 0026 bumps `channel_init_grace_period` to 60s when the
stored value is below 60.** Existing installs on the old 5s default (or
any custom value under 60) are raised automatically. Values already at
60s or higher are unchanged. If you previously raised
`channel_shutdown_delay` to keep buffered channels alive with no
viewers, set `channel_client_wait_period` instead (Settings → Proxy →
Advanced).
- **Proxy settings UI: less-used options moved under Advanced.**
Settings → Proxy now shows the day-to-day tuning fields by default
(`buffering_timeout`, `buffering_speed`, `channel_shutdown_delay`,
`new_client_behind_seconds`). **Buffer Chunk TTL**, **Channel
Initialization Timeout**, and **Client Connect Grace Period** are tucked
under **Show Advanced Settings**.

</details>

---

### Configuration

📅 **Schedule**: (UTC)

- Branch creation
  - At any time (no schedule defined)
- Automerge
  - At any time (no schedule defined)

🚦 **Automerge**: Enabled.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR has been generated by [Renovate
Bot](https://redirect.github.com/renovatebot/renovate).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMzAuMSIsInVwZGF0ZWRJblZlciI6IjQzLjEzMC4xIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbImFwcC9kaXNwYXRjaGFyciIsImF1dG9tZXJnZSIsInJlbm92YXRlL2NvbnRhaW5lciIsInR5cGUvcGF0Y2giXX0=-->
2026-06-30 21:15:26 +02:00

81 lines
2.7 KiB
YAML

# yaml-language-server: $schema=./values.schema.json
image:
pullPolicy: IfNotPresent
repository: docker.io/dispatcharr/dispatcharr
tag: 0.27.2@sha256:f2b5ea3128b0513feb07efee7539ad546f3ba3a9095f19936f446f75b8baa894
securityContext:
container:
readOnlyRootFilesystem: false
runAsUser: 0
runAsGroup: 0
service:
main:
ports:
main:
protocol: http
targetPort: 9191
port: 9191
workload:
main:
podSpec:
initContainers:
setup-postgres-dirs:
enabled: true
type: init
name: setup-postgres-dirs
image: alpine:3.24@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
command:
- /bin/sh
- -c
- |
echo "Setting up PostgreSQL directories..."
# Create and set permissions for /var/run/postgresql
mkdir -p /var/run/postgresql
chown 999:999 /var/run/postgresql
chmod 2775 /var/run/postgresql
echo "✓ /var/run/postgresql created (999:999, 2775)"
# Fix permissions for /data/db (restored from backup)
if [ -d /data/db ]; then
echo "Found existing /data/db, fixing permissions..."
# Recursively fix ownership of ALL files inside /data/db
chown -R 999:999 /data/db
# Set directory permissions to 0700
chmod 0700 /data/db
# Fix permissions on all subdirectories and files
find /data/db -type d -exec chmod 0700 {} \;
find /data/db -type f -exec chmod 0600 {} \;
echo "✓ /data/db permissions fixed recursively (999:999, 0700)"
else
echo "Creating /data/db..."
mkdir -p /data/db
chown 999:999 /data/db
chmod 0700 /data/db
echo "✓ /data/db created (999:999, 0700)"
fi
# Verify permissions
echo "Checking /data/db permissions:"
ls -la /data/db | head -10
ls -la /var/run/ | grep postgresql || echo "Warning: postgres dir not found"
echo "Setup complete."
containers:
main:
env:
DISPATCHARR_ENV: aio # Set to 'aio' for all-in-one mode with embedded PostgreSQL. Currently, only 'aio' is supported.
# DISPATCHARR_LOG_LEVEL: info
persistence:
data:
enabled: true
mountPath: /data
targetSelector:
main:
main:
mountPath: /data
setup-postgres-dirs:
mountPath: /data
postgres-run:
enabled: true
mountPath: /var/run/postgresql