[Feature Request] Add a watch data structure - to hold watched/played/read data

[psyciknz]

Describe the solution you'd like
Currently as discussed in the re-reading discussions #479 the workflow was showed where rereads was increased and the last seen date was set to current. To see a full history of all changed the history section shows all the changes. But you do lose start/end times.

I'd like the data structure to support start, end, notes for each instance where the media is read.

Describe alternatives you've considered
Added each consume instance in notes, the trouble with this is its' hard to remember to use it, and without an import api where I could set this programmatically, it's a little clunky.

Additional context
I realise this is a fairly big structure change, but as some of these integrations get implemented, it makes sense to do it early

[FuzzyGrim]

As you say, it would be a very big change. I tried to implement it in this branch (https://github.com/FuzzyGrim/Yamtrack/tree/repeats_refactor), but it was very incompatible with the current structure of the application. As an alternative, I will add an option to export the change history.

[psyciknz]

I wasn't sure how the data structure was set up, as it looked like the events table with the addition of another date time and maybe a notes field could be used for pushed each "consume" event of media. But is that tracking that the user has been notified on a new item?

So for a movie, it gets a record in app_item, and a record in app_movie linked by item_id = id, then app_historicalmovie links the id from app_movie to history_id.

But then in app_movie there's a start, end date and progress, also in app_historicalmovie

So it looks like if the historical had a link to app_movie, it could contain all the progress information for each instance of watching. That's just me looking at the data structure, rather than seeing how the code puts it together.

[FuzzyGrim]

The events table is used to track calendar events, so for example for an anime it would have the release dates of each of its episodes.

App_item contains the basic metadata of each media item, such as title, media_id, source, image....

Then each app_media_type (app_movie, app_tv, app_anime...) is used for the actual tracking with each entry having a rating, start_date, end_date, notes and then linked to a user and app_item.

The historical tables logs each save for each app_media_type entry. So in theory by comparing the historical records, we could know when a user started something, dropped it, started again, rewatched...

We could create a activity history/journal like:

---

For Movie Parasite:

If the user sets the status to Planning on 2022-04-04:

• Activity history (2022-04-04): Parasite status set to Planning.

If the user changes the status to Completed and the completion date to 2022-05-03 on 2022-05-05:

• Activity History (2022-05-05): Parasite finished watching on 2022-05-03.

Then if in 2023-08-04, the user sets the status to Repeating:

• Activity History (2023-08-04): Parasite started rewatching.

Then, upon completion of the rewatch, the user changes the status to Completed, with the new completion date, and increases the repeat count to 1.

• Activity history (2023-08-04): Parasite completed rewatching on 2023-08-04.

Rewatches again with new completion date, and increases repeat count to 2.

• Activity history (2023-08-04): Parasite completed rewatching for the second time on 2023-08-04.

[fdw]

From what I read, app_media_type and the historical tables overlap a lot. If there were only one table containing all the status changes for one app_item, you could show the full history, with "started on 2022-04-04", "finished on 2022-05-05", "re-started on 2023-08-05". But you can also show if the item has even been fully watched (is there an entry with "completed"?), if it's currently in progress (last status by date) and how often it has been completed (count where status is "completed").

This feels, to me at least, like a more natural design fitting to how I think about movies and watch events. It also gets rid of the "Number of repeats" which is duplicated by the history table.

[FuzzyGrim]

Yes, they overlap, as the values of any entries in app_media_type will appear in the history tables, but the history tables are automatically managed by django-simple-history, which adds some other convenient things.

How often it has been completed (count where status is "completed").

But it's a bit more complicated because we can't really distinguish when someone is adding another watch or just fixing their data. A user could mark a movie as Completed, save the form and then fix the Score, which would mean two entries with Completed status. Or changing the completion date if a mistake was made when filling out the form....

[psyciknz]

but if all "changeable things" moved to a history type table, the start, end, score, notes (ie review notes).

Then wouldn't your django-simple-history track changes on that table (they they're altering a score - as conceivably a score could vary with each watch) or the original table where completed/planning is set.

[fdw]

I see, so the historical tables are more for an audit trail of app_media_type, persisting all changes to it?

At least for me, I'm not interested in all changes. I'm interested in my watch history. If I mistyped the date or rating, and fix it later, I don't need a record of that change. An entry that I watched it is enough, with the correct date and score. That is quite different from your model, however.

[psyciknz]

I see, so the historical tables are more for an audit trail of app_media_type, persisting all changes to it?

At least for me, I'm not interested in all changes. I'm interested in my watch history. If I mistyped the date or rating, and fix it later, I don't need a record of that change. An entry that I watched it is enough, with the correct date and score. That is quite different from your model, however.

yeah watch history for me is the most important as well, on episodes, movies and movies. Start and end is nice but not all that important IMO (only books show any sort of time span)

[fdw]

yeah watch history for me is the most important as well, on episodes, movies and movies. Start and end is nice but not all that important IMO (only books show any sort of time span)

While I wouldn't have thought to track start time, I can see its use. Most importantly, however, I don't care about changes to such a "watch" entity. I want to see its properties, but if I change any of them, I do not need to see that or what I changed.

[FuzzyGrim]

@psyciknz

watch history for me is the most important as well, on episodes, movies and movies. Start and end is nice but not all that important

I'm not sure I understand what you mean by watch history and start/end date.

---

@fdw

I see, so the historical tables are more for an audit trail of app_media_type, persisting all changes to it?

Yeah, the idea was to use the historical tables to create something like a journal, I was a AniList user and they have something like this:

For example, you could see when did you add something to your planning list, when you started it, how many chapters you read, when did you drop it, when did you decide to try again and continue reading...

Maybe it's something that only I like 😄

[FuzzyGrim]

Yamtrack's structure is based on how MyAnimeList and AniList work:

So currently in app_media_type there can only be one entry with the same user and item. In the other branch https://github.com/FuzzyGrim/Yamtrack/tree/repeats_refactor, what I was doing was allowing multiple entries with the same item and user, so I could have two completed media entries, representing a rewatch. Then we would not need the Repeating status, nor the Number of Repeats field.

And then have a UI like:

With this we would not need to rely on django-simple-history or any of the history tables, but it would require some code restructuring. Maybe I should continue with the work in https://github.com/FuzzyGrim/Yamtrack/tree/repeats_refactor? I'm open to suggestions.

[psyciknz]

@psyciknz

watch history for me is the most important as well, on episodes, movies and movies. Start and end is nice but not all that important

I'm not sure I understand what you mean by watch history and start/end date.

Watch history, all the times you consumed a single piece of media.
Which is currently shown in yamtrack by a increase in rewatch count + entries in the history

[FuzzyGrim]

I haven't used Trakt and maybe I'm too used to how AniList/MyAnimeList works, but I think you can replicate that in Yamtrack with this?

[fdw]

Yeah, the idea was to use the historical tables to create something like a journal, I was a AniList user and they have something like this:

For example, you could see when did you added something to your planning list, when you started it, how many chapters you read, when did you dropped it, when did you decided to try again and continue reading...

Alright, I see what you're going for, thank you 🙂
While I personally don't (yet 😉) need something like this, I can see the use case. And I'm not opposed to it, on the contrary...

So currently in app_media_type there can only be one entry with the same user and item.

That is the core of the problem, I think.

In the other branch https://github.com/FuzzyGrim/Yamtrack/tree/repeats_refactor, what I was doing was allowing multiple entries with the same item and user, so I could have two completed media entries, representing a rewatch. Then we would not need the Repeating status, nor the Number of Repeats field.

This is exactly what I tried to suggest: A number of "history entries"/"status change entries" (or some better name) per user and item. Then, as you said, Number of Repeats isn't necessary anymore and you have a well-defined history of that user and item.
I think we can combine this with your use case of "planned"/"read chapter 1"/"dropped" by making each of these events one entry in that history. Obviously, they have different properties, so some work is necessary to combine them into one table, but it's certainly doable. And then you have a clean data model to show the history 🥳

I haven't yet looked at the code you've linked, and I can't say how much effort is needed for this change. But the changes would align perfectly with my mental model and they'd be a clean, normalized DB schema.