Record the direction that succeeded
Compare a viewing action in Infuse that appears in Trakt with a change made in Trakt that does not appear back in Infuse. These are two directions, and a successful outgoing update does not establish that incoming updates use the same owner or route.
Keep the media source type with the observation. Firecore’s general description says free Infuse sends data one way, while Pro adds incoming Trakt updates. Its separate server-connection paragraph narrows that expectation for media presented through Emby, Jellyfin or Plex.
Check which system owns the item state
For a media-server connection, inspect the title’s history and progress on that server using the authorised account. Firecore says Infuse uses that server-provided state rather than pulling watched history from Trakt. A Trakt edit alone should not be treated as a guaranteed command to rewrite the server’s record.
For another source route, inspect the applicable product entitlement and Trakt prerequisites instead. Firecore lists a Trakt account, signing in on each device and enabling scrobbling. Keep those checks tied to the actual route; repeatedly reconnecting a working server does not change which service supplies its viewing state.
Keep iCloud and Trakt observations distinct
Firecore says Trakt sync can operate with or without iCloud sync enabled. Do not use an unrelated iCloud preference as proof that an incoming Trakt update should control a server-owned item. Record the changed service, device and timestamp to keep the direction of the attempted update clear.
For help, provide the Infuse version and product state, source connection type, direction that worked and where the conflicting watched state is visible. Use a non-sensitive title example. This evidence distinguishes a missing setup prerequisite from the explicitly documented server exception, and prevents an unnecessary purchase from being presented as a universal remedy for every incoming-history difference.