Emby silently fails to index shows when season.nfo or tvshow.nfo has truncated XML

[nopenope12345 5]

When a season.nfo or tvshow.nfo file contains truncated XML (missing closing tag etc), Emby silently fails to index the affected show entirely. No error is logged, no unmatched item appears in the UI, and the show is completely invisible in the library. 

I am running lscr.io/linuxserver/emby version 4.9.3.0 but on my test Emby server running 4.9.4.1, it also never indexed or repaired the .nfo files.

I have a well organized media library with a standard naming convention such as: /tv/Show Name [imdbid=tt123456]/Season */Episode title.mp4.

Emby should either log a specific error about the malformed NFO, surface the item as unmatched so the user can interact with it, or fall back to scraping metadata from TVDB/TMDB rather than silently dropping the item.

The show folder is completely absent from the library with no indication of why. Artwork is downloaded and saved to the folder (visible in logs via ProviderManager), confirming Emby can see the folder, but the show never appears in the UI.

The truncated NFOs were originally created by Emby itself. Emby should handle incomplete writes to its own NFO files more gracefully.

The only workaround was to manually repair the truncated NFO file and rescan.

I also noticed that letting JF scan this library seems to have fixed the truncated .nfo files for me. I fixed one manually and then on a hunch tried scanning with my backup JF server. 

I have been running emby premiere for years now and this is the first time anything like this has happened.

I am providing logs as requested, however the issue manifests as a complete absence of log entries. Emby logs artwork saves to the affected folder via ProviderManager, but there is no corresponding log entry explaining why the show is skipped during indexing. The lack of logging is itself part of the bug report.

embyserver-63911641282.txt

[Luke 42312]

HI there, can you please show an example of your file and folder naming and organization?

I don't think the malformed nfo is a problem. The server has adequate error handling to recover from that. I think more likely something else is at play and the malformed nfo seems like the only visible answer to point to.

[nopenope12345 5]

Sure, here is an example of my naming convention:

/tv/Heated Rivalry [imdbid=tt35495073]/Season 1/Heated Rivalry - S01E01 - Rookies WEBDL-1080p.mkv

This convention is used consistently across my entire library of ~1,500 shows with no issues.

Regarding the NFO error handling, I understand your skepticism, but here is what I observed:

- Show A (Heated Rivalry) — truncated season.nfo, never indexed by Emby across dozens of scans

- Show B (aka Charlie Sheen) — truncated tvshow.nfo AND season.nfo, never indexed since September 2025

- I manually repaired the truncated NFOs (and JF scan).

- Both shows appeared in Emby on the next scan

The correlation seems direct to me. If there is other error handling at play I would expect to see something in the logs, but there are no log entries whatsoever about these folders being skipped, only ProviderManager entries confirming artwork was successfully saved to them.

Happy to test anything specific that would help isolate the actual cause.

[visproduction 338]

Try using only one dash prior to the resolution and delete all other dashes in the filename.  I have not completely tested this, but I seem to have fixed many file naming issues and dbase entries by removing the multiple dashes in file names.

[nopenope12345 5]

Appreciate the thought but this issue I am having is only on a few shows. My files are well-organized and this has never been an issue before that I am aware of.

I tried removing the imdbid from the series folder and rescanning my library. I can see that Emby did index it but it still never shows up in the UI or search.

I searched the db directly as well and found it but like I said, it doesn't show in my library at all:
 

sqlite3 /mnt/user/appdata/emby/data/library.db "SELECT Name, Path FROM MediaItems WHERE Path LIKE '%aka Charlie%';"

Miniseries|/data/tvshows/aka Charlie Sheen/Season 1
Part One|/data/tvshows/aka Charlie Sheen/Season 1/aka Charlie Sheen - S01E01 - Part One HDTV-1080p.mp4
Part Two|/data/tvshows/aka Charlie Sheen/Season 1/aka Charlie Sheen - S01E02 - Part Deux HDTV-1080p.mp4

 

Why would JF be able to index it regardless and also have it shown in the UI? It has only happened on the above show and the Heated Rivalry show. I was able to get the latter to show up by fixing the .nfo files but aka Charlie Sheen absolutely will not come up. 

I love Emby and have been a premiere user for years now. I genuinely think something isn't quite right here but it would take an Emby dev to verify. I am happy to test and try out suggestions from the devs!

[Luke 42312]

What's an example of a truncated nfo?

[visproduction 338]

In my experience, often any text before the last dash can be discarded in some situations. This text editing is used to create the pull down list of video resolutions on each media page, when you have multiple resolutions with the same filename and only a difference with the last - 1080P or - 720P.  This is feature to remove excess text and allow the pull down menu to look good show the different resolutions.  Unfortunately, I have noticed that this same text editing function has adjusted sometimes the title of the content in the on screen player that appears when you start media playback.  I think this text editing function is used in other times where titles appear in lists.

I mentioned this several times in various forum posts and no one seems to even try to test it.  I guess if you don't want to change titles of anything because it's too much work, then not even testing it, is the choice.  But, then you can't see if it's the actual problem.

Edited yesterday at 03:31 PM by visproduction

[nopenope12345 5]

21 hours ago, Luke said:

What's an example of a truncated nfo?

Here you go...

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<tvshow>
  <plot><![CDATA[It spans his rise to fame, subsequent spiritual and public fall, struggles with addiction, eventual sobriety (seven years sober), and road to recovery and redemption.]]></plot>
  <outline><![CDATA[It spans his rise to fame, subsequent spiritual and public fall, struggles with addiction, eventual sobriety (seven years sober), and road to recovery and redemption.]]></outline>
  <lockdata>false</lockdata>
  <dateadded>2025-09-28 19:25:57</dateadded>
  <title>aka Charlie Sheen</title>
  <originaltitle>aka Charlie Sheen</originaltitle>
  <actor>
    <name>Charlie Sheen</name>
    <role>Himself</role>
    <type>Actor</type>
    <tmdbid>6952</tmdbid>
    <tvdbid>253657</tvdbid>
    <imdbid>nm0000221</imdbid>
  </actor>
  <director tmdbid="1278071" tvdbid="8157417">Andrew Renzi</director>
  <trailer>plugin://plugin.video.youtube/play/?video_id=WqQUvfsavO4</trailer>
  <rating>7.519</rating>
  <year>2025</year>
  <sorttitle>aka Charlie Sheen</sorttitle>
  <mpaa>16</mpaa>
  <imdb_id>tt37898320</imdb_id>
  <tmdbid>298234</tmdbid>
  <premiered>2025-09-10</premiered>
  <releasedate>2025-09-10</releasedate>
  <enddate>2025-09-10</enddate>
  <runtime>91</runtime>
  <tagline>This isn't a comeback. It's a revelation.</tagline>
  <genre>Documentary</genre>
  <genre>Mini-Series</genre>
  <studio>Netflix</studio>
  <tag>addiction recovery</tag>
  <tag>biographical documentary</tag>
  <tag>documentary portrait</tag>
  <tag>healing journeys</tag>
  <tag>healing process</tag>
  <tag>hollywood star</tag>
  <tag>life after personal tragedy</tag>
  <tag>life and career</tag>
  <tag>miniseries</tag>
  <tag>recovering addict</tag>
  <tag>recovering alcoholic</tag>
  <tag>redemption</tag>
  <tag>rise and fall</tag>
  <uniqueid type="imdb">tt37898320</uniqueid>
  <uniqueid type="tmdb">298234</uniqueid>
  <uniqueid type="tvdb">466849</uniqueid>
  <tvdbid>466849</tvdbid>
  <uniqueid type="official website">https://www.netflix.com/title/82024990</uniqueid>
  <uniqueid type="tv maze">86525</uniqueid>
  <episodeguide>{"imdb":"tt37898320","tmdb":"298234","tvdb":"466849","official website":"https://www.netflix.com/title/82024990","tv maze":"86525"}</episodeguide>
  <id>466849</id>
  <season>-1</season>
  <episode>-1</episode>
  <displayorder>aired</displayorder>
  <status>Ended</status>

 

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<season>
  <plot />
  <outline />
  <lockdata>false</lockdata>
  <dateadded>2025-09-28 19:27:06</dateadded>
  <title>Miniseries</title>
  <year>2025</year>
  <sorttitle>Miniseries</sorttitle>
  <tvdbid>2200677</tvdbid>
  <premiered>2025-09-10</premiered>
  <releasedate>2025-09-10</releasedate>
  <uniqueid type="tvdb">2200677</uniqueid>
  <seasonnumber>1</seasonnumber>

 

[nopenope12345 5]

10 hours ago, visproduction said:

In my experience, often any text before the last dash can be discarded in some situations. This text editing is used to create the pull down list of video resolutions on each media page, when you have multiple resolutions with the same filename and only a difference with the last - 1080P or - 720P.  This is feature to remove excess text and allow the pull down menu to look good show the different resolutions.  Unfortunately, I have noticed that this same text editing function has adjusted sometimes the title of the content in the on screen player that appears when you start media playback.  I think this text editing function is used in other times where titles appear in lists.

I mentioned this several times in various forum posts and no one seems to even try to test it.  I guess if you don't want to change titles of anything because it's too much work, then not even testing it, is the choice.  But, then you can't see if it's the actual problem.

My issue is that literally all of my 70TB+ media library works perfectly. This has only happened on two shows and both had the truncated nfo files.

[visproduction 338]

Nope,

That is strange.  I would be interested to see what causes the truncated .nfo files.  Perhaps right at the point where the file stops is something that fails.  With Linux, many times, rights for specific files or subdirectories is not setup correctly or gets changed and some process cannot complete because of the ownership or rights.  I wonder if that could result in the .nfo just stopping from getting created.

Edited 1 hour ago by visproduction

[nopenope12345 5]

I really wish I could tie it into a server crash or something but so far I cannot sort it out.