Unresolved on Media Server Target.

[CarlitoGil]

Hi!
CrossWatch is amazing, thank you!

I'm trying to understand how unresolved items on Plex work.

I read about unresolved and blackbox, and get the general idea. That's great.

Not finding a movie from source Trakt on target TMDB should indeed be handled.
But if it just doesn't exist on a media server target, does CW have another strategy for that?
Can't it just ignore it?

Specifically when syncing to a media server with strict ID matching, it seems to me that unresolved are unnecessary and slower.
Many items from the user's history may just not currently exists on the server.

Is it really necessary to eventually put them on cooldown and doing the extra handling of unresolved?
And then go back to the slower process every so often?

Please forgive if I'm mistaken in my assumptions.

[cenodude]

Hi,

Specifically when syncing to a media server with strict ID matching, it seems to me that unresolved are unnecessary and slower.
Many items from the user's history may just not currently exists on the server.

First, CrossWatch needs to determine whether it can find the item on your Plex server (with or without strict IDs, that part isn’t the deciding factor). CrossWatch can’t just guess whether an item exists in your Plex library. If it can’t match the item, it will eventually get promoted to the Unresolved list. Unresolved is essentially an exclusion list: after an item fails a few times, it gets promoted and then excluded from future planned actions. So normally you’ll only see that behavior a few times, after that, the item gets ignored.

So after a few syncs, it should be settle down just fine. However, you're right regarding syncing from a tracker to a media server it works, but it was never the primary nor intended flow. Normally, you want media server to tracker (one-way or two-way).
More context: https://wiki.crosswatch.app/related-information/trackers-vs.-media-servers

It’s also important to know that the CrossWatch orchestrator is provider-agnostic. We don’t make special exceptions depending on direction (tracker to media server vs media server to tracker). The same rules apply either way. CrossWatch is basically a Swiss Army knife: you can do almost anything, but that doesn’t mean every setup is a smart idea.

To keep syncs reasonably clean, CrossWatch uses many different guard systems:

Unresolved
Most items that can’t be resolved end up in the unresolved lists under /.cw_state/*. These are created by the sync adapters, not by the orchestrator. These are excluded from further syncs

Key points:

• No TTL: unresolved items do not expire automatically.
• Manual cleanup: once an item is in the list, you must remove it manually. In the furture i will make some UI adjustments to clear items from that list.. Reminder to myself :-)
• Staging behavior: items typically get “promoted” after repeated failures, after a few sync runs they may end up in the permanent unresolved list.
• Typical causes: provider returns unresolved, provider downtime, “0 confirmations” fallback, partial failures that can be attributed to a specific key.

Blackbox
The Blackbox exists at the orchestrator level. It’s a safety mechanism to protect against weird behavior and repeated failures.

It triggers when the same key fails repeatedly:

• failures increment a flap counter
• items get promoted/blocked once consecutive failures hit the configured threshold (promote_after)

IF you want to read more:
https://wiki.crosswatch.app/blueprint-architecture/orchestrator/unresolved
https://wiki.crosswatch.app/blueprint-architecture/orchestrator/blackbox
https://wiki.crosswatch.app/blueprint-architecture/orchestrator/tombstones
https://wiki.crosswatch.app/blueprint-architecture/orchestrator/phantom-guard

Or a total overview of all guardrails can be read here: https://wiki.crosswatch.app/blueprint-architecture/orchestrator/guardrails#power-users

[CarlitoGil]

Thanks for the reply.

It’s also important to know that the CrossWatch orchestrator is provider-agnostic.

I think that pretty much settles it.
Kinda thought it would be better when the target is a media server to just loop over existing items and check the source.

I does get much faster after a few runs.
To test, I used Clear provider cache to see how much slower it would be again.

Normally, you want media server to tracker (one-way or two-way)

It tried it like that, two-way. Didn't seem faster. Is it?

I wanted movies newly added to the server that had previously been rated to fetch that rating.

Again, thanks for your work on CW.

[cenodude]

Performance/speed hasn’t been my top priority yet. I want to tackle that once CrossWatch is stable enough. I can squeeze some improvements out for certain providers, but sync speed is basically a “depends on everything” problem: internet latency, Media server response times, provider API latency, rate limits, storage/ssd, etc… the list doesn’t end. Ofcourse is also depends on how many records you have.

In practice, most users just schedule it and forget it exists. Personally, I run sync once and then keep things up to date with Watcher (history and ratings), but that only works if your media player is your main entry point / source of truth.