Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date Based TV Show Support #1503

Closed
wants to merge 6 commits into from

Conversation

herby2212
Copy link
Contributor

@herby2212 herby2212 commented Sep 7, 2021

Description

Continued with PR #1960. This PR is outdated and marked as draft.

This PR aims to fix issue #1487 and provide a place where we can work & discuss on this topic.

UI fields needing a change/fixed:

  • Recently Added
  • Current Activity
  • Library Recently Added
  • User Recently Watched
  • TV Show History
  • Library Media Info
  • Users Table
  • Info page breadcrumb / header
  • Newsletter templates
  • Notification parameters

Please report any occurrences of this issue that aren't listed above.

Screenshot

tautulli activity date based tv show

Type of Change

  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated the docstring for new or existing methods

@herby2212 herby2212 mentioned this pull request Sep 7, 2021
5 tasks
@herby2212 herby2212 marked this pull request as ready for review September 7, 2021 17:10
@JonnyWong16
Copy link
Contributor

You don't need all the format_date_based_show functions. originallyAvailableAt is already in ISO format YYYY-MM-DD. Don't use the dots.

@herby2212
Copy link
Contributor Author

You don't need all the format_date_based_show functions. originallyAvailableAt is already in ISO format YYYY-MM-DD. Don't use the dots.

I know it is already in the ISO Format. The idea was to keep it in line with the current style (seasons have the dots S3 · E1 and Plex also for the date based episodes).

@herby2212
Copy link
Contributor Author

herby2212 commented Sep 16, 2021

@JonnyWong16
Could you handle the implementation for the Newsletter Templates regarding the date based tv show support? As I'm not familiar with the way they function or the files affected.

So we can complete/progress this Pull Request.

I first tried to contact you via a Discord PM as I would have liked to not clutter up the PR with a message like this.

@JonnyWong16
Copy link
Contributor

The date format you see in Plex is based on locale. It will use a dot, dash, or a slash and a different order of year, month, and day depending on where you set your location.

In Tautulli, since there is no localization, the date could be

  1. ISO format YYYY-MM-DD.
    • Pro: international standard
    • Con: not everyone likes it
  2. Follow the "Date Format" in the settings.
    • Pro: user chooses the format they like
    • Con: user wants a different date format for general UI vs. episodes
  3. Add a new "Date-Based Episode Format".
    • Pro: user chooses the format they like
    • Con: another setting could be confusing

For Discord, you can just use the #general channel.

@herby2212
Copy link
Contributor Author

herby2212 commented Sep 21, 2021

We should either go with 1. or 3. as 2. would be nothing complete (users can choose but not on a sufficent level).

So from my perspective:
1 ISO Format:

  • Pro: Would be clean and lightweight without any formatting
  • Con: Unable to be customized by a user (could be a irregularity for the user if the normal date is customized & customizable but this not)

3 Add a new "Date-Based Episode Format"

  • Pro: User can customize it to fit its region and/or match the configured regular date (with a slight difference for example just like by default in Plex)
  • Pro: Would be a full feature implementation (incl. setting) instead of a "basic support" implementation (to make it work) as a request for this setting wouldn't seem unlikely once released

I tend to 3. to give users one more option from the start, but I would like to know your opinion.

For Discord, you can just use the #general channel.
Okay, wasn't sure if deeper development/PR topics are allowed there (as there is also no development channel for example).

@herby2212
Copy link
Contributor Author

herby2212 commented Sep 21, 2021

How do we want to display the episode range in the newsletter with date based tv shows?

For some items the listing could work like 2021·08·22, 2021·08·23.
If there are more episodes take the earliest and latest episode (based on the timestamp) like this 2021·08·22-2021·09·01 maybe.

tautulli newsletter episode range

@JonnyWong16
Copy link
Contributor

I need to think about the newsletter.

Let's go with option 3, a separate setting for "Date-Based Episode Format".

@herby2212
Copy link
Contributor Author

I need to think about the newsletter.

Let's go with option 3, a separate setting for "Date-Based Episode Format".

Any decision/news about the newsletter?

@JonnyWong16
Copy link
Contributor

I'm thinking just the range of dates for the newsletter.

Season 2, Episodes 2021-01-01 - 2021-06-30

@herby2212
Copy link
Contributor Author

I'm thinking just the range of dates for the newsletter.

Season 2, Episodes 2021-01-01 - 2021-06-30

Sounds good and seems like the cleanest solution.

@@ -502,6 +502,7 @@
{'name': 'Season Number', 'type': 'int', 'value': 'season_num', 'description': 'The season number.', 'example': 'e.g. 1, or 1-3'},
{'name': 'Season Number 00', 'type': 'int', 'value': 'season_num00', 'description': 'The two digit season number.', 'example': 'e.g. 01, or 01-03'},
{'name': 'Episode Number', 'type': 'int', 'value': 'episode_num', 'description': 'The episode number.', 'example': 'e.g. 6, or 6-10'},
{'name': 'Episode Number', 'type': 'str', 'value': 'episode_date', 'description': 'The episode number of date based tv shows (in date format).'},
Copy link
Contributor Author

@herby2212 herby2212 Oct 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provide a additional notifier variable episode_date that is only used for date based tv shows or extend the description of episode_num that in case of a date based tv show shows the air date?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's already an air_date parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but in case of a item that uses the date based system episode_num and episode_num00 will be replaced with originally_available_at. Should we include this in the notifier description? That was the idea behind this question/change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, don't change the behaviour of episode_num (in this PR).

Copy link
Contributor Author

@herby2212 herby2212 Oct 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I will work on that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just gave it a thought, how would you propose to implement the notifications for date based tv show?

If the user uses episode_num and hits a on date based episode the variable then should use the originally_available_at as its currently implemented from a logic standpoint in my opinion.

@herby2212 herby2212 mentioned this pull request Jan 6, 2023
16 tasks
@herby2212 herby2212 marked this pull request as draft January 6, 2023 18:41
@herby2212
Copy link
Contributor Author

herby2212 commented Jan 6, 2023

Continued with PR #1960. This PR is outdated and marked as draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

2 participants