A watch tracker can start with one field: the last playback time. That works until a viewer changes discs, rewatches an episode or uses another edition of the same series. A value such as “1200 seconds” cannot answer the most important question on its own: 1200 seconds into what?
For a physical-media tracker, I would separate story progress from a bookmark on a particular edition. This is a proposed design with fictional examples, not a report of a deployed application.
Model completion separately from position
Episode progress answers whether a viewer has completed a piece of content. A playback bookmark answers where an interrupted session might continue. Finishing episode three and stopping twenty minutes into episode four should produce two distinct facts.
A completion record needs a viewer or viewing-group identifier and a stable content identifier. If repeat viewing matters, include a viewing-run identifier too. Otherwise a completed first watch can be accidentally reset by an unfinished rewatch.
A bookmark needs more context: the edition, disc and playable item to which the position refers. It can also reference the content item, but that reference does not make the physical layout universal.
Keep edition layout out of the episode identity
The story's identity and the place it occupies on a disc are different relationships. The same episode may occupy different discs in different editions. A disc can also contain several episodes or supplementary material.
Use an edition-layout mapping to connect a playable item to the content it represents. A useful conceptual chain is edition to disc to playable item. The content record sits alongside that chain and is linked when the mapping is known.
Do not infer identity from “Disc 2, Item 1” alone. Nor should a title string be the only key: titles can repeat or be edited. Display names help people recognise records; stable identifiers preserve relationships.
Define the coordinate system before storing time
A bookmark field called “position” is underspecified. State whether it is elapsed time within an episode, within a disc title, or within some other playback unit. Store the unit as well; seconds and milliseconds should not be interchangeable by convention.
For a manually maintained tracker, a record could mean: viewer A, viewing run B, edition C, disc 2, playable item D, approximately 1200 seconds from the start of that item. The approximation is part of the record's meaning.
If the player does not expose reliable playback coordinates, let the user record a note rather than fabricating precision. A tracker should not claim it can seek the hardware to a stored position unless an actual integration supports that operation.
Treat unknown mapping as a valid state
Sometimes the application knows the disc label but cannot match its menu item to a canonical episode record. Preserve what is known and leave the relationship unresolved. Do not silently attach it to whichever episode happens to have the same number.
This is especially useful for specials, combined episodes and extra features. A free-text display label can keep a bookmark useful while the underlying content mapping remains incomplete.
Distinguish an unknown time from the beginning of playback. Zero can mean an actual position at the start; an absent value means no position was recorded. The interface should preserve that difference.
Choose conflict behaviour intentionally
Imagine that a phone records a newer bookmark while an offline tablet still has an older one. If the tablet later reconnects, accepting its stale write can move progress backwards. A timestamp alone is not a complete solution when device clocks disagree.
For a small service, one approach is to attach a server-managed revision to each bookmark. A client submits the revision it last read. If that revision is stale, preserve both observations or ask the user which to keep instead of silently overwriting the latest record.
Completion and bookmarks also need different rules. A replayed completion event should not create duplicate completions. A user explicitly undoing completion should be represented as an intentional action, rather than confused with a delayed bookmark update.
Make shared watching a first-class choice
A household does not have one universal viewing position. A person's solo watch and a group's shared watch can diverge. Put the viewing context in the record key and show it clearly in the interface.
The next action can then be derived within that context: continue the unfinished item, start the next mapped episode, or ask the user to choose when the mapping is uncertain. Avoid making “next” a guess hidden behind a confident button.
For spoiler-sensitive use, keep the default interface limited to titles and positions. Plot summaries are not necessary to communicate progress.
Test the boundaries of the model
Useful test cases include two editions with different layouts, the same episode watched in two runs, a special without a season number, a bookmark with an unknown time, and an offline update arriving after a newer revision.
Also test deletion and correction. Removing a temporary bookmark should not erase completed episodes. Correcting a disc-to-episode mapping should not silently rewrite what someone marked as finished without a deliberate migration rule.
These cases reveal whether the application understands its data or merely stores a set of numbers that happen to work for one collection.
Keep the interface simpler than the model
Most viewers only need to see “Last finished,” “Continue” and “Next.” The model can retain edition and playback details behind those labels while exposing uncertainty when it changes the action a person should take.
The practical benefit of separating these concepts is continuity. A discarded hardware bookmark does not erase story progress, and a different edition does not pretend that an old time offset points to the same scene.
Sony's Resume Play guidance illustrates why a tracker should not treat a player's temporary stop point as permanent viewing history: behaviour is conditional on equipment and discs. https://www.sony.com/electronics/support/articles/00032387
Top comments (0)