Android 2026.15.0: Record button does nothing

Live TV & DVR
1

[Bug] Android 2026.15.0: Record button does nothing on programme details page — /grandchildren 404s in a loop

Server Version#: 1.43.3.10828
Player Version#: 2026.15.0
Tuner Make/Model: n/a
Guide/Lineup name: n/a
Using XMLTV?: n/a
Channel number/Name: all channels tested

On Android 2026.15.0, tapping Record on a programme’s details page does nothing at all — no dialog, no scheduled recording, no error message.

Recording from the Live TV section on the same app and device works fine, so it’s specific to the details-page route. The same recording also schedules normally from Plex Web, and from a phone still on the legacy app 10.26.1.123.

This isn’t device-specific. I have two handsets and 2026.15.0 fails identically on both. One of them is only usable for recording because I’ve kept it on the legacy app.

  • Moto G 5G Plus, Android [version] — 2026.15.0, broken
  • Moto G75 5G, Android [version] — 2026.15.0 broken, now rolled back to 10.26.1.123, works

What the logs show

I pulled app logs from the affected phone. The details page loads its metadata fine, then immediately 404s on the episode-list call:

20:20:18:523  GET 200  .../tv.plex.providers.epg.cloud:8/metadata/plex%3A%2F%2Fshow%2F69cf281d2656628eff7fa6f9?includeExtras=1&includeOnDeck=1&...
20:20:18:580  GET 404  .../tv.plex.providers.epg.cloud:8/metadata/plex%3A%2F%2Fshow%2F69cf281d2656628eff7fa6f9%2Fgrandchildren   26ms

Same on a second show:

20:21:18:472  GET 200  .../metadata/plex%3A%2F%2Fshow%2F6a7231c1f6c3f21361d2a573?includeExtras=1&...
20:21:18:544  GET 404  .../metadata/plex%3A%2F%2Fshow%2F6a7231c1f6c3f21361d2a573%2Fgrandchildren   38ms

The app then retries that 404 roughly every 1–2 seconds for as long as the page stays open, with no backoff and nothing shown to the user:

  • Show 69cf281d… — 27 consecutive 404s over about a minute
  • Show 6a7231c1… — 14 consecutive 404s over about 30 seconds

No recording request is ever sent. Across the full log set (three files, going back to 25 June) there is no POST to any recording or subscription endpoint. The only writes anywhere are home/users/…/switch, user/settings, users/anonymous, pins and updater/check. So the record action dies client-side before it reaches the server.

Server connectivity is healthy throughout — guide data, channel lineups and hub content all return 200 from the same provider in the same session:

20:20:28:371  GET 200  .../media/providers   56ms
20:20:28:372  Current best connection to <server> is https://<server-lan-address>:32400

My reading of it

The details page seems to depend on /metadata/<item>/grandchildren to populate the record options. The EPG provider doesn’t serve that endpoint for these items, so the sheet never becomes actionable and the button is inert.

Plex Web and 10.26.1.123 both schedule recordings against the identical server, provider and account, and the Live TV path inside 2026.15.0 works too — so this looks like a regression in the details-page code in the rewritten client, not a server or guide-data problem.

Two things that would help even if the 404 itself is expected:

  1. The record action should surface an error rather than silently doing nothing.
  2. The retry loop should back off. Forty-one identical 404s in three minutes is a lot of pointless traffic.

Secondary, lower priority

The app tests four connection addresses for my server on every refresh cycle. Three of them are virtual interfaces on the NAS and time out after a full 10 seconds, every single cycle, throughout the entire log:

[Connections] Fetch timeout GET https://<virtual-iface-1>:32400/media/providers  10309ms
[Connections] Fetch timeout GET https://<virtual-iface-2>:32400/media/providers  10309ms
[Connections] Fetch timeout GET https://<virtual-iface-3>:32400/media/providers  10309ms

I can fix my end by restricting the advertised addresses, but the client could also remember which ones have failed repeatedly instead of re-testing all four every time. It causes a visible stall on each refresh.

Also worth mentioning: [Metrics] Failed to flush events: … ERR_CONNECTION_REFUSED fires several times a second for the whole session. Unrelated to the recording issue, but it’s a lot of wasted work.

Happy to supply the full logs or test anything on either handset.

Server hostnames, addresses and identifiers redacted throughout.

2

This is a known issue. Thanks for reporting.

3

Good to know. Is there a release it’s expected in?

5

A future release :sweat_smile:. We don’t usually provide ETAs unless it’s known in the next release.