Emby Live-TV possible bug report: XMLTV: programme-level <icon>, <category>, <new>, and <previously-shown>

[FlameRed 3]

In another post I mentioned I attempted to write an XML script for Emby Live-TV in an attempt to give me finer control over the EGS feeds I am using, populate program ICONs and control new programs are recorded but reruns not recorded. I am not sure if what I discovered are true bugs, or if Emby just handles them differently. I hope it is just me not having the proper understanding of how Emby Live-TV handle EPG XML and I can be educated on where I went wrong.

Live TV / XMLTV: programme-level <icon>, <category>, <new>, and <previously-shown> are ingested but appear to have no effect

Summary

When using a third-party XMLTV guide source (merged from an XMLTV backend, not Emby's own Guide Data service), Emby's Live TV importer appears to read <title>, <desc>, and <start>/<stop> from <programme> elements, but does not appear to act on several other standard/documented elements:

• <icon src="..."> on <programme> never populates artwork for the corresponding Live TV "Shows" item, even though channel-level <icon> (on <channel>) works correctly and displays channel logos as expected.
• <category>movie</category> — using the exact, case-sensitive value configured in Dashboard → Live TV → Setup → XmlTV → Movie categories — does not appear to trigger the movie classification/internet-lookup behavior implied by that settings page, and does not affect artwork population either.
• <new/> and <previously-shown start="..."> do not appear to affect DVR "record new episodes only" behavior. Reruns are still scheduled for recording even when the programme is correctly tagged <previously-shown start="..."> referencing an earlier, correct original air date, and the true first airing is correctly tagged <new/>.
• Tested both self-closing (<new/>) and explicit open/close (<new></new>) syntax for all of the above elements, in case a non-standard internal parser was missing self-closing tags specifically. No difference in behavior was observed between the two forms.

Environment

• Emby Server version: 4.10.0.17 (beta)
• Platform: Docker on QNAP NAS Running QuTS Hero.
• Guide Data Source: XmlTV (Dashboard → Live TV → Setup → Guide Data Sources), pointed at a self-hosted, merged XMLTV URL (not "Emby Guide Data")
• TV Source: M3U, pointed at a self-hosted M3U URL
• Both served by a self-hosted playlist/EPG manager (Stationarr) that merges multiple upstream XMLTV sources with one custom enrichment source layered on top

What's confirmed working correctly

To rule out the source data as the problem, the following were independently verified before filing this report:

• The XML is well-formed and successfully parses in Python's xml.etree.ElementTree (a strict parser) with no errors.
• Emby is downloading and parsing the file successfully — confirmed via Emby's own server log during a manual "Refresh Guide Data" run: the file downloads (200 OK), and programme counts are correctly saved per channel, with no errors or warnings logged.
• Channel-level <icon> works perfectly — channel logos display correctly throughout the Guide, Channels, and On Now views, confirming Emby's XMLTV parser does read <icon> in at least one context.
• The <category> value exactly matches Emby's own configuration — copied verbatim from the "Movie categories" field on the XmlTV source's settings page (see screenshot reference in "Additional context" below).
• The programme-level <icon> URL is independently reachable — confirmed via curl -I directly from the Emby server's host machine, returning HTTP/1.1 200 OK with a valid image/jpeg content type.
• Confirmed via direct API inspection (browser DevTools → Network → the Items?... request backing the Live TV "Shows" row) that the returned JSON shows "ImageTags":{} (empty) for programme items that have a valid, correctly-formatted <icon> in the source XML — ruling out a UI-only rendering bug and confirming the image reference is not being stored server-side at all.

Steps to reproduce

• Configure a TV Source of type M3U pointed at any valid M3U playlist.
• Configure a Guide Data Source of type XmlTV pointed at a URL serving XMLTV where at least one <programme> element includes:

  <programme start="20260701210000 +0000" stop="20260702000000 +0000" channel="EXAMPLE.us">  <title>Example Movie Title</title>  <desc>A description of the movie.</desc>  <new></new>  <icon src="https://image.tmdb.org/t/p/w500/examplePosterPath.jpg"></icon>  <category>movie</category></programme>
  

• On the XmlTV source's settings page, set Movie categories to movie (or confirm the <category> value above matches whatever is already configured there).
• Run Refresh Guide Data (Dashboard → Live TV → Setup, or via Scheduled Tasks).
• Navigate to Live TV → Programs → Shows, and locate the item corresponding to the programme above.

Expected: Poster artwork appears for the item, matching the <icon> URL provided. Actual: The item displays the default blank clapperboard placeholder icon.

• Inspect the underlying API response (DevTools → Network → the Items?... request that returns this item's JSON) and check the ImageTags field for this item.

Expected: "ImageTags":{"Primary":"<some hash>"} Actual: "ImageTags":{}

• Create a DVR recording rule for the series/movie above with "Record new episodes only" (or equivalent) enabled, across a guide window containing both the <new/>-tagged airing and a later <previously-shown start="...">-tagged rerun of the same content.

Expected: Only the <new/>-tagged airing is scheduled to record. Actual: Both the new airing and the <previously-shown> rerun are scheduled to record.

Sample real-world data

The following is representative real output from the pipeline used to test this (channel names/IDs anonymized where not relevant), showing a movie with three airings — the first correctly tagged <new>, and the two reruns correctly tagged <previously-shown> referencing the original air date:

<programme start="20260701083500 +0000" stop="20260701120000 +0000" channel="ExampleChannel.us">
  <title>Example Movie</title>
  <desc>Example description.</desc>
  <new></new><icon src="https://image.tmdb.org/t/p/w500/exampleHash.jpg"></icon><category>movie</category>
</programme>
<programme start="20260703170000 +0000" stop="20260703202500 +0000" channel="ExampleChannel2.us">
  <title>Example Movie</title>
  <desc>Example description.</desc>
  <previously-shown start="20260701083500 +0000"></previously-shown><icon src="https://image.tmdb.org/t/p/w500/exampleHash.jpg"></icon><category>movie</category>
</programme>

Additional context

• This was tested extensively across multiple variations before concluding it's not a data-quality issue: plain <icon> alone, <icon> + correctly-cased <category>, self-closing vs. explicit open/close tag syntax, and stable vs. unstable programme-identity tracking for the new/rerun logic. None of these variations changed the observed behavior.
• If this is intentional/by-design (e.g., programme artwork and new/rerun detection are only supported when using Emby's own "Emby Guide Data" service, not third-party XMLTV), it would be very helpful to have this documented explicitly on the XmlTV setup page or in the XmlTV documentation, since the "Movie categories" field in particular strongly implies category-based classification has some functional effect for XmlTV sources specifically.
• Happy to provide a full sample XMLTV file, HAR export of the relevant API calls, or server logs on request.