Import edge cases
Anime catalogues can disagree before playback starts.
Two services can describe the same release with different entries, episode counts and season boundaries. A safe import keeps the source record intact when that difference cannot be represented exactly.
Common structural differences
| Difference | Effect on history | Safe treatment |
|---|---|---|
| Specials | One catalogue can keep specials under the main series while another creates several separate entries. | Preserve the original entry and episode coordinate. Do not force a one-record-to-one-record assumption. |
| Split parts | One catalogue can use one entry while another divides the same material into Part 1, Part 2 and Part 3. | Keep the source part and count. Treat a translated progress value as a derived claim. |
| Recaps and inserted episodes | An extra recap or bonus episode can shift every later episode number. | Use explicit episode relations when available. A numeric offset alone is not durable evidence. |
| Season boundaries | An anime service can create a new entry for an announced part while a television catalogue keeps it inside one season. | Retain both the source entry and the target series or season context. |
| Moved or removed entries | A current lookup can return a different record or no record after a provider changes its catalogue. | Keep the source identifier recorded with the event and mark later correspondence as stale or disputed rather than rewriting history silently. |
| Missing event times | Some exports contain progress or completion without the original watch timestamp. | Keep event time unknown. Do not spread or invent precise dates to make an import look complete. |
What animeApi issue #11 adds
The discussion reports four connected problems. Several community data projects inherited a common archived baseline. Provider APIs can be restricted, incomplete or difficult to operate at scale. One-to-one correspondence loses specials and split entries. Third-party records can also become stale after a provider moves or removes an item.
These are not only metadata problems. They can change which episode a historical event appears to describe, whether a completed item becomes incomplete after import, and whether a retry creates a duplicate against a different target record.
Safe import behavior
- Keep source context
- Store the source namespace, source item identifier, source episode or part coordinate and the label used at import time.
- Name every time
- Keep event time, export time, import time and correction time separate. Unknown event time stays unknown.
- Allow unresolved records
- An event can remain useful while its destination subject is unresolved or disputed.
- Make correction explicit
- A later correction should preserve the original import evidence and record why the current interpretation changed.
- Require explicit deletion
- A missing provider entry, empty page or failed lookup is not evidence that the user's history should be removed.
- Version external evidence
- Record the source and checked date used for a correspondence so later changes can be inspected.
Example: one watched item, three destination entries
A source export reports episode 12 of one item as watched. The destination catalogue stores the same material as three separate parts. The importer can preserve the source event immediately, but it should not select a destination part from title similarity alone. The event remains unresolved until exact evidence or a user correction identifies the represented part.
Primary discussion checked 31 August 2026: nattadasu/animeApi issue #11, including the examples about specials, split parts, episode counts, stale provider records and lost watch timestamps. The page summarizes reported interoperability risks; it does not define a provider catalogue or rank a data source.
Found a reproducible import case? Report the source service, destination service, entry grain, episode coordinate, available event time and expected result through Scrobble.dev.