neonrust / epm Goto Github PK

mark <id | ssearch> -> mark next episode (replaces (or same) as current next)
mark <id | search> all -> mark all episodes (currently without any extra argument)

Lists series & episodes most recently watched, in order.

A limit may be possible to specify (default 10 episodes).

The global one, as well as for each each series.

This has several benefits.

• Update checks (and tracking) does not need to update (or even read) the main series file.
• The upcoming audit command only need to read the meta files. #38

Move all meta data, except the file version?

Currently, there's not enough information in the meta data to know how many episodes are released at a specific point in time.
To do this I guess, the "unseen_episodes" could contain a list of release dates. Currently, it only contains a number (which includes also unreleased ones).

Use the same detection logic as <the thing that should not be named>.

It's a bit of a mess at the moment.

Probably also give the series title formatting a once-over as well.

Spotted with the "Nevers" (80828), where The Movie DB for some reason decided to add the second part of the first season as a "Specials" season, with number 0.

I guess we need to collect all seasons from the "seasons" container in the main details. And maybe then sort those episodes by air date? They might of course be interspersed with the other season's episodes.

Also see "Doctor Who" (57243) for an example of specials.

There's no rational reason to do this. ;)

I guess it could then stand for "Episode Managing Program".

As always, where?

That is, a new episode is indicated even though there are more than one episode unseen.
(If there's only one, the top-level list will say "TODAY")

e.g. VLC, others?

For "baking" a certain command line into an easily issued command:

> epm config show --alias=frobnicate --args '-a -p -I'
> epm frobnicate
.. output of "show -a -p -I" ...

Probably, these aliases can't accept additional options (b/c options are looked up based on the command used). Arguments should be possible without hassle.

To set default values and arguments.

e.g. > epm config unseen --args=-s
To run the unseen command with -s arguments by default.

This also implies that all boolean options needs to have a "disable" variant as well, to disable if it was configured as default enabled.

Command-line syntax is of course not final or even preliminary.

Add possibility to add alias for a series. Useful for simpler, possibly unambiguous, searches.

For example, "tm" for "Taskmaster", or "ds9" for "deep space nine".

I guess it should be a separate command? alias and unalias ?

epm alias tm=123

As the database grows, it makes sense to move the non-changing entries (i.e. the archived) into a separate database file.
This will make it more awkward to perform the "all" listings. Not by a lot though.

e.g. running epm unseen will only call should update() for series that actually have unseen episodes.

This means that if a series has no released and unseen episodes at one point, unseen will not displayit. Then, if there later are new episodes released, unseen will never list it, because its entry in the database will never get refreshed.

It should actually be called for all series.

So, it is probably better to just call it directly from db.indexed_series(), which is called for all series and all views.

Basically, it just rolls back the database to the most recent backup (i.e. series.1.*).
Can be run multiple times, until there are no more backups left (default 10).

This is probably and mostly only for developer use for debugging purposes. However, it could be useful also for undoing command-line mistakes, e.g. marking the wrong season.

Should of course ask confirmation.

Only .1 is used. All other slots are never touched.

Likely been broken a long time. :(

Currently, most commands will do a refresh_series(), regardless of it being required or not. This seems a bit unnecessary.

For example, printing a list where no series are stale -> no refresh required at all.
More specifically, printing the list should proceed "as long as" no refresh is needed, then if a stale series is encountered, do the refresh call as usual, then continue printing the list.

The "TODAY" text is bright green. Could be fitting to also tint the background of that row to be slightly green as well.

It seems to include future episodes as well as the episode already listed.

Currently, the active db file (series) is not compressed; only the backups are.
Also compressing the active one has several benefits.

1. Reading the compressed file is very fast. With zstd, it's negligible. (it it's on a "slow" medium, it's probably faster than uncompressed, but I doubt that's the case nowadays)
2. When writing the series file we already need to compress 1 file (the .1 backup).
3. With "sparse" backups (for #42), we don't need to compress anything.
4. Rolling back a backup is essentially a no-op.

Ideally, we should figure out how to reading and decompressing at the same time, i.e. the equivalent of zstd -d -c file.zst | jless. Or, at the very least, test if that is faster. That being said, orjson doesn't support reading from a file descriptor, so maybe this would be pointless.

Preferrably, this should be done before #42.

Anything, really. For example, why it was added, e.g. "made by so-and-so".
This is not the same as the rate command which also allows for a comment.

Not really necessary at this point. But it might be later.

This could contain superficial stats and a version number, among other things.
This meta data could be useful for example when migrating an older database structure for use with newer code.

For example, make the selection interactive (e.g. arrow buttons), and show more information for the current item.

This would also apply to the search command, but seeing as they are essentially the same this will automatically be the case :)

i.e. not all episodes were watched

Invoking an external binary if of course not ideal and entails latency and other overhead.

Both of these libraries have python integrations; zstd and lz4.

As always, should do some performance benchmarks.

I guess it could be possible to still use the external binaries as a fallback.

(only "Av" is visible of the title)

Basically, the watch percentage shouldn't be shown (there) at all.

It's significantly faster.

See https://developer.themoviedb.org/docs/append-to-response

For presentation, e.g. a list of strings stored in epm:meta.change_log.

Preferrably without adding a third line in the output, e.g.:

   19 The Walking Dead  (2010-2022)  ended                             tt1520211  
       Next:  s11e17 Lockdown                                      45min 2022-10-02

Should show e.g.:

   19 The Walking Dead  (2010-2022)  ended   9 left                    tt1520211  
       Next:  s11e17 Lockdown                                      45min 2022-10-02

Maybe it could show episodes left in the current season but also the total.

Not sure why I chose the list index to be dict-order and renumbered whenever series were added or deleted...

It would be much better if the list index were just serial numbers, just increased for every add.
This would need to store the list index in the series entry itself (in the epm:meta), not a big deal.

Also, a next_list_index could be stored on the top-level (in its epm:meta), so we don't need to compute it when adding a new series.

Probably only occurs when refreshing, i.e. many parallel requests.

There's now more space available on the title row, e.g. on the far right.

example (current display):

  193 The Last Ship (2014-2018)  ended  37%
       Next:    3:1 The Scott Effect         +38 more     41min 2016-06-19

proposal:

  193 The Last Ship (2014-2018)  ended  37%                      39 unseen
       Next:    3:1 The Scott Effect                      41min 2016-06-19

e.g. key repeat doesn't work nor home/end.
Maybe add shortcuts for number keys to jump to a specific hit.

Sometimes we'll start watching, but then drop it for whatever reason.
Similar to archiving; don't delete it completely but instead flag it.

Or could we simply consider a series that is archived but not completely watched as "abandoned" ?

When the number of series goes above 100 (or even 1000 ?!), the index number becomes rather cumbersome.

Maybe a higher base could be used? For example 1-99 base 10 is used and then additional digits are base 26 (i.e. letters and no numbers), so: a00 = 100.

Example: u13 is 21*100 + 13 = 2113 (`u is 21).

Could also print the two different base digits using different colors.

Listing recent changes.
That is, this should to read all backups of the database and present the changes_log in epm:meta for each backup.

Not sure which of those names is best... yet.

Currently the listing is ordered by title (no case), but other sorting could be useful.

For example:

• earliest "next" episode
• release year
• date added (also same as index order)
• etc

And, of course, the reverse of all these should also be possible.

Leaving the "meta" data in the current database file.
That is, the database file merely contains entries that reference (by TMDb ID) the series it is regarding.

The series data are instead stored in separate files, e.g. in a directory series (have to rename the database file in that case).

This has a few benefit:

1. Only the necessary series needs to be loaded, lazily. Some of the search properties might still need to be stored in the database, for search purposes, e.g. title.
2. When refreshing a series, only that file needs to be written.
3. Does not need to be backed up/versioned. Either they exist or don't (which is dictated by the main db file), and if they exist will always be the most recent version.
4. Since they're "write once; read many", they could be compressed harder. Maybe even in parallel (if more than one is refreshed at the same time).

This replaces #42.

When specifying series by name, that is.

Would be useful to find an example of a tool that does this...

Tricky part is when and how much to back off.

One way could be to keep a list of dates of the last N updates and if that frequency (e.g. updates/day) exceeds some threshold back off by some fraction of that.

The goal is to back off more and more as the updates gets less and less frequent.

Extreme example could be that if the series hasn't been updated for a year, don't refresh for 6 months.

Show N days (e.g. a month) in the future where episode releases are marked.

Moving around in the menu (using cursor keys), it will jump 1 step upwards each time stepping from 2nd to 1st entry.

And possibly, director/writer and such, which requires an extra fetch, however.

On a scale of e.g. 1 to 10, with optional comment.

At first, let's just store it internally, but in theory it could be used to post to e.g. IMDb.