Leveraging the native HDHomeRun ScanInProgress flag for channel lineup syncs

[PowerCC 11]

Hi Luke and the Emby development team,

First off, thank you for all the continued work on the Live TV infrastructure. The way Emby handles standard, physical HDHomeRun tuners is incredibly stable, and the fast loading times for the guide data are much appreciated.

I’ve been diving into some custom tuner management lately and noticed a great opportunity to make Emby’s channel synchronization even more seamless, particularly for users whose channel lineups evolve over time (which is becoming a lot more common).

Currently, because Emby does such a great job optimizing and caching the /lineup.json data for fast performance, adding new channels to a tuner often requires users to do a full remove-and-re-add cycle in the dashboard to force a fresh sync.

A Native Protocol Opportunity While reviewing the official SiliconDust documentation, I noticed there is actually a native signaling mechanism designed for this exact scenario that we might be able to tap into.

When an HDHR device is updating its lineup or running a background scan, it broadcasts a state change via the /lineup_status.json endpoint using the ScanInProgress field.

The normal transition looks like this:

1. Standard idle state: "ScanInProgress": 0

2. Lineup actively updating: "ScanInProgress": 1

3. Update complete: "ScanInProgress": 0

Here is an example of the payload during an active update:

JSON

{
    "ScanInProgress": 1,
    "ScanPossible": 1,
    "Source": "Cable",
    "Lock": "qam256"
}

The Proposed Enhancement If Emby's tuner logic could monitor this endpoint and watch for that 0 -> 1 -> 0 transition, it could use the final drop back to 0 as a native trigger to silently re-fetch /lineup.json in the background.

Implementing this small protocol handshake would allow Emby to gracefully append new channels without requiring users to rebuild their tuner configurations. It’s a subtle change, but it would be a massive win for power users and likely cut down on forum support questions regarding missing channels.

I’d be more than happy to provide logs or payload captures of these state transitions if it helps the team test this out. 

[PowerCC 11]

@Lukeand the Emby development team,

Following up on this feature request from the weekend, I wanted to share some concrete telemetry and testing results after fully implementing this ScanInProgress handshake in my own HDHomeRun emulation environment.

I built out the exact protocol signaling we discussed, and the results are highly promising. Here is the implementation that is currently working in production:

1. The Trigger: When a new upstream M3U is generated, the system verifies it is a complete, non-empty write to prevent race conditions.

2. The Signal: The emulator raises ScanInProgress=1 on /lineup_status.json for a 45-second window (SCAN_SIGNAL_SECS).

3. The Handshake: Emby successfully watches this 0 → 1 → 0 transition and silently triggers a background re-fetch of /lineup.json exactly as intended.

The Good News: Emby’s network polling handles this brilliantly. When the 0 transition hits, Emby pulls the fresh JSON and seamlessly injects any newly added channels into the live TV database without requiring a manual guide refresh or a tuner remove/re-add.

The Final Mile (Where we need your help): > While Emby pulls the updated JSON perfectly, the internal database logic appears to perform an "upsert" rather than treating the new JSON as the authoritative, absolute state. Additions work flawlessly, but channels that were removed from the JSON are left behind as "ghost channels" in the Emby database. Currently, the only way to clear these ghosts is to manually delete and re-add the HDHomeRun TV source. 

Since the ScanInProgress network handshake is already working so well on Emby's end, would it be possible to tweak the ingest logic so that it honors the absence of a channel during these background syncs?

If Emby could drop channels that no longer exist in the payload after a successful scan signal, it would completely eliminate the need for manual TV source maintenance.

Happy to provide any logs or test builds if it helps refine the database ingest side of this!

[EODCrafter 181]

Wow! This would be great! I know @Luke answer will be future release but we can hope!

[TMCsw 275]

TVnext_Features_pub - Google Drive

This was said to be the next beta after the 4.9-stable release;

Make your own conclusions. 

[Luke 42578]

The normal guide refresh will remove dropped channels

[PowerCC 11]

@Luke

 

To clarify, the issue isn't about standard guide data updates—it is a specific bug in how Emby processes the native HDHomeRun HTTP API (/lineup.json and /lineup_status.json).

Emby’s network polling driver actually handles the hardware protocol brilliantly right now. When the tuner completes a scan and ScanInProgress transitions from 1 → 0, Emby instantly triggers an immediate background pull of /lineup.json to synchronize the lineup.

The real issue is that this real-time background pull acts as a strict database upsert:

• Additions work perfectly: Newly added channels are injected instantly into the Live TV guide.

• Deletions fail completely: Channels that have been removed from the tuner's JSON payload are left behind as "ghost channels."

Because Emby retains these defunct channels instead of clearing them out during the hardware sync, it causes severe channel overlaps and mapping conflicts in the guide. Currently, the only way to resolve these broken overlaps is to completely delete and re-add the HDHomeRun TV source.

Since Emby is already doing the heavy lifting of monitoring the hardware flag and fetching the fresh JSON payload in real-time, matching the database state to the actual payload (dropping channels no longer present) would make the HDHR HTTP integration perfectly seamless.

Appreciate you taking a second look at the database ingest side of this hardware handshake!