Pim Zandbergen [Sun, 14 Jun 2026 13:42:55 +0000 (15:42 +0200)]
ratinglabels: document why enabled_notify is intentionally empty
The notify callback for the enabled property is a registered no-op.
Add a comment explaining the empty body rather than removing the
function, addressing review feedback.
GCC 16's stricter checks turn two issues into -Werror build failures:
* satip_rtsp.c: the fixed 16-byte _w buffer cannot hold "&tvhweight=%d"
for the full range of int weight (worst case 23 bytes incl. NUL),
flagged as -Werror=format-truncation. Enlarge _w to 24 bytes. While
here, size the buf VLA from the floor-clamped max_pids_len (so a small
or negative caller value cannot under-size or invalidate it) and enlarge
buf (max_pids_len + 32 -> + 64) so the combined "delpids=%s&addpids=%s%s"
formatting (del+add up to max_pids_len, plus the larger _w) cannot
silently truncate.
* ratinglabels.c: remove the dead body of ratinglabel_class_enabled_notify
(a set-but-unused local plus an unused obj), which GCC 16 rejects.
Note: the buf resize and floor-clamped sizing reach slightly beyond the
original -Werror fix. They were added while iterating on this PR's Gemini
Code Assist review, which flagged those adjacent latent truncation /
VLA-sizing issues in the lines being touched.
Pim Zandbergen [Sun, 14 Jun 2026 14:28:19 +0000 (16:28 +0200)]
build: never reuse a stale .config.mk from a failed configure
write_config() is the sole writer of .config.mk and only runs after every
dependency check has passed. If configure instead dies on a missing
dependency (any of the ~40 `check_* || die` gates) - or is interrupted by a
signal - it returned without touching .config.mk, leaving the previous run's
file in place. The Makefile unconditionally `include`s that file, so make
would silently build against a stale configuration. In practice this could
link the wrong ffmpeg: e.g. a re-configure that died because libtheora-dev
was missing left behind a .config.mk from an earlier system-libav run,
pulling in the distro's ffmpeg instead of the bundled static one.
Establish the invariant "the .config.mk exists only if a configure run
completed":
- Remove any .config.mk up-front, right after argument parsing and before
the checks, so that whatever ends the run early (die or signal) leaves no
stale file and make fails loudly instead of using the wrong config. Placed
after parsing so --help, which exits earlier, never deletes a valid config.
- Write .config.mk to a temp file in write_config() and rename it into place
atomically at the very end, so it is never observed half-written.
Sam Nazarko [Sat, 13 Jun 2026 07:11:50 +0000 (08:11 +0100)]
access: store the superuser password obfuscated like normal accounts
The debian postinst wrote the superuser password to the superuser file
in cleartext, whereas normal user accounts are stored using the reversible
"TVHeadend-Hide-" base64 obfuscation. Write the superuser password the
same way (a new "password2" field) and teach access_init() to decode it,
falling back to the plaintext "password" field so existing superuser
files keep working.
If base64/tr are not available on the host (e.g. a stripped-down busybox
system), the postinst falls back to writing the cleartext "password"
field, so the superuser file is always valid regardless of userland.
This is obfuscation for consistency, not encryption: HTTP Digest auth
requires a recoverable password, so a one-way hash is not possible here.
The superuser file is still created mode 0600.
Sam Nazarko [Sat, 13 Jun 2026 07:07:43 +0000 (08:07 +0100)]
debian: fix superuser file location and config directory ownership
The postinst wrote the superuser account into $HOME (/var/lib/tvheadend),
but Tvheadend resolves its configuration directory via config_get_dir(),
which only uses /var/lib/tvheadend when that directory is owned by the
service user. On a stock package install /var/lib/tvheadend is owned by
root (adduser does not chown a pre-existing home directory), so the daemon
falls back to ~hts/.config/hts and never reads a superuser file placed in
the parent - the initial login then fails with "403 Forbidden".
- Take ownership of /var/lib/tvheadend so config_get_dir() uses it as the
canonical configuration directory. This is skipped when an earlier
install already has configuration under a fallback location, so existing
settings are never stranded.
- Resolve the configuration directory in the postinst the same way
config_get_dir() does (using "stat -L" to match the daemon's symlink
dereferencing) and write the superuser file there.
- Document the ownership requirement of the /var/lib/tvheadend shortcut in
config_get_dir().
maedula [Fri, 5 Jun 2026 19:19:24 +0000 (21:19 +0200)]
satip: expose DVB-S frequency override and fix matching priority
Expose the existing but hidden mm_dvb_satip_dvbs_freq field in the
DVB-S mux editor UI as an advanced property. This allows SAT>IP clients
to address DVB-S2X MIS muxes that share the same physical frequency but
have different ISI values, by assigning each mux a unique virtual
frequency within the Ku-band range.
Also move the SAT>IP frequency override matching (for DVB-S/C/T) to run
before normal dvb_network_find_mux() matching. This ensures virtual
frequency overrides always take priority, preventing accidental matches
against real transponder frequencies.
Guard the override match against unconfigured (zero) values using a
switch statement, so deltaU32(freq, 0) cannot produce false matches
when no override is configured.
Background: SAT>IP RTSP does not pass ISI (dmc_fe_stream_id), so
dvb_network_find_mux() can never match MIS muxes from SAT>IP clients.
The frequency override is the only path to reach MIS streams via SAT>IP.
Oliver Sluke [Thu, 21 May 2026 22:04:08 +0000 (00:04 +0200)]
epggrab: per-service EIT processing policy with global default
DVB EIT comes in two forms. Actual transport stream tables (table_id
0x4e present/following, 0x50-0x5f schedule) describe the multiplex
that carries them. Other transport stream tables (0x4f, 0x60-0x6f)
describe services on a different multiplex. The OTA grabber tunes
every multiplex, so when one multiplex carries other-TS EIT for a
service whose own multiplex is also grabbed, both descriptions reach
the EPG store and the last writer wins. A coarse other-TS placeholder
from a neighbouring multiplex can then overwrite a service's own
detailed schedule, and vice versa, so the EPG flips between the two
on successive grabs.
Replace the per-service "Ignore EPG (EIT)" boolean with an "EIT
processing" enum, and add a matching "EIT processing (default)"
global setting. Per-service values:
Default Defer to the global default
None Ignore EIT for this service
Actual only Accept only actual-TS sub-tables (0x4e, 0x50-0x5f)
Other only Accept only other-TS sub-tables (0x4f, 0x60-0x6f)
Either Accept both (today's behaviour, no precedence)
Adaptive Accept both, but once the service's own actual-TS
schedule has been seen, drop further other-TS for
it so a neighbour's coarse description cannot
overwrite the detailed schedule
The global default exposes the same enum minus Default. New installs
get Either, which matches today's behaviour with no surprise
migrations.
The legacy "dvb_ignore_eit" key is read on first load: true migrates
to None (same observable behaviour), false to Default (defers to the
global, also same observable behaviour while global stays at Either).
The old key disappears from the config on next save.
The EIT handler resolves the effective policy per call (per-service
unless Default, in which case the global applies) and filters tableid
acceptance accordingly. Adaptive tracks per-service "actual-TS
schedule seen" at runtime; the flag is not persisted, so it is
relearned each session. P/F (0x4e / 0x4f) is only two events per
service and is not used as the seen trigger.
Full per-value help text lives in docs/property/eit_processing.md and
docs/property/eit_processing_default.md, wired in via the PROP_DOC
macro; the in-form ".desc" tooltips are short pointers to the Help
icon, matching the existing pattern (e.g. PROP_DOC(cron),
PROP_DOC(ota_genre_translation)).
Signed-off-by: Oliver Sluke <22557015+oliversluke@users.noreply.github.com>
Oliver Sluke [Mon, 25 May 2026 11:46:16 +0000 (13:46 +0200)]
dvr: size subscription-title buffer to the title length
`dvr_rec_subscribe` formatted the subscription title into a fixed
100-byte buffer via snprintf. snprintf truncates byte-wise, so a
long multibyte title (CJK at 3 bytes/char, or 4-byte emoji) could
leave a dangling partial UTF-8 sequence at the end. That title
flowed into the comet/ws JSON feed; the invalid byte made the
browser drop the frame, and the web UI stayed silent until the
recording ended.
Size the buffer to the actual title via alloca() so the title
isn't truncated at all. On the common case of short ASCII titles
the buffer is smaller than the previous fixed 100 bytes; on long
multibyte titles it grows just enough. Matches the existing
alloca pattern used elsewhere in the tree (cron.c, http.c,
string_list.c, rtsp.c, htsmsg_xml.c).
Fixes: #2121 Signed-off-by: Oliver Sluke <22557015+oliversluke@users.noreply.github.com>
src/epg.c:2607-2610 — `_epg_sort_channel_descending` delegates to
`_epg_sort_description_ascending` and negates, so a request for
channel-name DESC returns events ordered by reverse description
text instead of reverse channel name. Rows cluster by adjacent
description prose, not by channel.
The sibling `_epg_sort_channel_ascending` (lines 2598-2605) uses
`channel_get_name` correctly, and every other `_descending`
variant in the file delegates to its own `_ascending` (title,
subtitle, summary, description, extratext, genre). Channel is
the only outlier — a copy-paste typo.
Oliver Sluke [Sat, 9 May 2026 06:01:58 +0000 (08:01 +0200)]
mpegts: align DVB delivery-system and modulation defaults with the enum
Several mux classes in mpegts_mux_dvb.c declare a default value
that the corresponding *_enum callback never emits. Each enum
function iterates a small list of DVB_* constants and emits the
canonical string returned by the matching dvb_*2str helper —
which scans the relevant strtab in dvb_support.c and returns
the first matching row.
Two distinct mismatches:
1. Delivery-system defaults
Three classes used the unhyphenated spelling and one carried
the wrong constant entirely (copy-pasted from the dvbt class
above):
delsystab carries both spellings on the same DVB_SYS_*
constant, so configs persisted with the legacy form continue
to load unchanged.
2. QAM constellation / modulation defaults
qamtab carries TWO entries for "auto" — { "AUTO", DVB_MOD_AUTO }
and { "QAM/AUTO", DVB_MOD_QAM_AUTO }. The enum arrays for the
QAM-based modulation classes pass DVB_MOD_QAM_AUTO, so the
dropdown publishes "QAM/AUTO" — but each class declared the
default as "AUTO", which parses to a different constant and
isn't a member of the published enum.
The other DVB tables (modetab, guardtab, hiertab) only carry
a single AUTO entry, and bw / fec fall through to
dvb_common2str which canonicalises value 1 to "AUTO" — so the
remaining 22 MUX_PROP_STR(..., N_("AUTO")) declarations are
already in alignment.
Effect: clients that validate enum membership on submit refuse
to send the default — the user has to manually re-pick the
canonical value before the form will save. The ExtJS combobox
doesn't enforce membership on submit, so the bug went unnoticed
there.
Migration: the delsys side has no on-disk impact (legacy and
canonical strings map to the same constant). For the QAM cases
"AUTO" parses to DVB_MOD_AUTO and "QAM/AUTO" parses to
DVB_MOD_QAM_AUTO — different constants. Existing configs
persisted with the legacy "AUTO" continue to load and tune
correctly (both signal "let the driver decide"); the dropdown
synthesises a current-value option so the form remains editable
until the user re-saves with the canonical choice.
Signed-off-by: Oliver Sluke <22557015+oliversluke@users.noreply.github.com>
Oliver Sluke [Wed, 13 May 2026 21:37:28 +0000 (23:37 +0200)]
intl: include docs translations in the runtime catalog
Makefile line 668 references $(LANGUAGES-DOC) — a variable that
is never defined anywhere in the repository. GNU Make expands
undefined variables to empty, so the docs catalog
(intl/docs/tvheadend.doc.<lang>.po) never reaches PO-FILES, the
poc.py generator, or src/tvh_locale_inc.c. Every msgid sourced
from docs/class/*.md, docs/property/*.md, and docs/wizard/*.md
falls back to English on every language at runtime via
tvh_gettext_lang(), even when the matching translation exists.
User-visible surfaces affected: the setup wizard's per-step
description paragraphs, every per-class help page served via
/markdown/<class>, and every per-property help text.
Repro: build with LANGUAGES=pl, then
grep -c "Welcome to Tvheadend" src/tvh_locale_inc.c
returns 0, even though intl/docs/tvheadend.doc.pl.po carries
the Polish translation
"__Witamy w Tvheadend – Twoim serwerze do transmisji
strumieniowej TV i rejestratorze wideo__"
for the wizard's hello-step headline. After this fix the count
is non-zero and the Polish wizard renders its description in
Polish instead of English.
Coverage today (filled msgstr entries): Polish 100%, French
95.5%, English en_GB / en_US ~100%, Estonian 41.8%, Korean
33.5%, Spanish 20.7%, plus partial work in Norwegian, German,
Danish, Dutch, Swedish, and Bulgarian.
Origin: introduced in commit 7ec64dd70d ("intl: fix the broken
build", 2016-04-13), which added $(wildcard ...) to both
PO-FILES lines but also renamed the docs-line variable from
$(LANGUAGES) to $(LANGUAGES-DOC) without adding a definition.
No prior pull request or GitHub issue has tracked the bug — the
docs catalog has been silently absent from the runtime since.
Two coordinated changes:
1. Makefile — use $(LANGUAGES) on the docs line, matching the
main-catalog line directly above. The existing
`make LANGUAGES="..."` override now affects both catalogs
consistently.
2. support/poc.py — rewrite cstr() to emit every non-ASCII
byte as an octal \NNN escape, producing an ASCII-only
src/tvh_locale_inc.c. The compiled binary contains the
same UTF-8 byte sequence as before (octal escapes resolve
to single bytes at compile time). This avoids tripping
GCC's -Wbidi-chars Trojan-Source check on any
translator-introduced bidi control character — concrete
case: intl/docs/tvheadend.doc.pl.po:6935 translates "The"
as a lone U+202E, almost certainly a stray keystroke.
Octal escapes are bounded to exactly 3 digits by the C
standard, so they don't suffer the greedy-consumption
pitfall of \xHH hex escapes. The rewrite also correctly
escapes literal backslashes, which the previous cstr()
silently passed through.
Catalog ordering: PO-FILES lists the main catalog first and the
docs catalog second; poc.py's load() merges via dict.update(),
so on overlapping msgids the docs translation wins. For Polish
244 msgids overlap (227 identical, 17 different); for French
244 overlap (229 identical, 14 different); for en_GB 244 overlap
(243 identical, 0 different). The differing entries are minor
translator variants — accent / spelling / article-elision tweaks
— not semantic regressions. Examples:
- French "Status": main "Etat" → docs "État"
(accent fix — docs likely more correct)
- French "Channel name": main "Nom de la chaine" → docs
"Nom de chaine" (article dropped, stylistic)
- Polish "Timeshift": main "Funkcja Timeshift" → docs
"Timeshift" (shorter, stylistic)
- Polish "Map unnamed channels":
main "Mapuj nienazwane kanały" → docs
"Mapuj nie nazwane kanały" (spelling variant)
Signed-off-by: Oliver Sluke <22557015+oliversluke@users.noreply.github.com>
Oliver Sluke [Sat, 2 May 2026 20:59:15 +0000 (22:59 +0200)]
htsbuf: escape all JSON control bytes per RFC 8259 §7
`htsbuf_append_and_escape_jsonstr` is the single function every
JSON-emitting code path in tvheadend funnels through (see
`src/htsmsg_json.c:53,67,72,76` — every htsmsg_t serialised to
JSON, which covers every `api/...` REST response and the Comet
bus). Today it escapes only `"`, `\`, `\n`, `\r`, `\t`. The
other 27 ASCII control bytes (0x00–0x1F minus those three) are
appended verbatim.
This violates RFC 8259 §7 / ECMA-404, which both require all
characters in U+0000–U+001F to be escaped. The output is
rejected by every standards-compliant JSON parser (browser
JSON.parse, Python json.loads, jq, Go encoding/json, jansson,
serde_json). The bug surfaces whenever a stored string ever
contained one of those bytes — broadcaster EPG data is a
frequent source (DVB-EIT and XMLTV feeds occasionally carry
stray BEL / SOH / etc.), and any user-editable string field
can pick them up via API clients or paste-from-terminal.
Reproduction (verified on HEAD before this change): set any
DVR entry's `comment` field to a string containing `\a`
via `api/idnode/save`, fetch the entry back via the
corresponding grid endpoint, observe `Invalid control character
at: line 1 column N` from `python3 -c 'import json;
json.load(...)'`. Hex-dump confirms a literal 0x07 byte sits
unescaped inside the JSON string.
Fix: extend the trigger condition to `c < 0x20`, add `\b` and
`\f` shortform escapes (RFC 8259 §7 recognises them; matches
what every standard JSON serialiser emits), fall back to
`\uXXXX` for the remaining ~24 control bytes. Cast to
`unsigned char` so the comparison is well-defined on platforms
where plain `char` is signed. Switch statement replaces the
if-else cascade — same emitted code, easier to read.
Behaviour delta: zero for any string that didn't already
contain a control byte. Only previously-malformed JSON output
becomes well-formed. UTF-8 multi-byte sequences pass through
unchanged (continuation 0x80–0xBF and lead 0xC0–0xFF don't
trigger c < 0x20).
Verified via a small standalone test that links against the
patched htsbuf.o, exercises the function over every byte
0x01–0x1F, and round-trips the output through Python's strict
parser. Output for byte 0x07: `"x\ay"` (escaped). For 0x0C:
`"x\fy"` (named shortform). Etc. All 31 round-trips succeed.
Independent of PR #2034 (cJSON replacement), which explicitly
retains this function.
Signed-off-by: Oliver Sluke <22557015+oliversluke@users.noreply.github.com>
Oliver Sluke [Thu, 23 Apr 2026 21:12:49 +0000 (23:12 +0200)]
channels: fix reentrancy guard in channel_class_changed()
atomic_dec(&ch->ch_changed_ref, 0) subtracts 0 instead of 1, so
the reentrancy counter never resets after the first call. All
subsequent calls see atomic_add() > 0 and return early, permanently
suppressing HTSP channelUpdate notifications, bouquet propagation,
and tag updates for that channel.
Fix by decrementing by 1 so the guard properly resets to 0.
Oliver Sluke [Fri, 24 Apr 2026 13:41:44 +0000 (15:41 +0200)]
htsp: add absolute signal fields for DVBv5 decibel-scale hardware
The signalStatus message only sends feSNR/feSignal for
SIGNAL_STATUS_SCALE_RELATIVE drivers, silently dropping values from
modern DVBv5 hardware that reports in SIGNAL_STATUS_SCALE_DECIBEL.
Add feAbsoluteSNR (s64, dB x 1000) and feAbsoluteSignal (s64,
dBm x 1000) fields for SCALE_DECIBEL drivers, carrying the raw
kernel values with no conversion. Clients check which field is
present to determine the value type.
Pim Zandbergen [Tue, 3 Mar 2026 16:34:24 +0000 (17:34 +0100)]
channels: fix sort order in channel dropdown lists
Channel dropdowns such as "Reuse EPG from" in channel configuration,
and the channel selectors in DVR, autorec, timerec and service mapper,
all use channel_class_get_list() to build their property descriptor.
The descriptor lacked an stype field, causing the ExtJS data store in
idnode.js to re-sort the server-provided list alphabetically by the
displayed string after loading, regardless of the order delivered by
the API.
Fix by adding stype=none to the descriptor to preserve server sort
order, and explicitly requesting the appropriate sort from the API
based on the channel display configuration:
- With channel numbers enabled (chname_num): request sort=numname so
channels are ordered numerically, matching the visible number prefix.
Previously the ExtJS re-sort would produce alphabetical ordering on
the prefixed strings, e.g. "1 ...", "10 ...", "2 ..." instead of
"1 ...", "2 ...", "10 ...".
- With channel numbers disabled: request sort=name to preserve the
existing alphabetical-by-name ordering that users without channel
numbers would expect. This is a pure bug fix with no behaviour
change for this configuration.
Ukn Unknown [Sat, 17 Jan 2026 02:49:30 +0000 (18:49 -0800)]
fix profile when overwritten by user with the wrong value
- fix profile when overwritten by user with the wrong value
- related to the problem : https://github.com/tvheadend/tvheadend/pull/1933#issuecomment-3392478998
- before transferring the profile to ffmpeg we confirm that profile is available.
Ukn Unknown [Sun, 18 Jan 2026 00:44:32 +0000 (16:44 -0800)]
fixes crash when user is forcing pix_fmt or when codec is not available
- fixes https://github.com/tvheadend/tvheadend/issues/1980
- in context.c I added two checks to ensure we don't search for a helper if codec is not available and is not trying to open (tvh_codec_profile_open()) --> this will create a panic.
- in order to avoid getting to that 'late point decision'; at am also checking if pix_fmt is available in ffmpeg before calling.
- if the user will try to force (from web interface) a different pix_fmt some warnings will be printed and video will not open.
projects / thirdparty / tvheadend.git / log
