Docker container on ghcr.io

[aleksasiriski]

1. Started work on Docker CI/CD pipeline for ghcr.io
2. Added AGPL license to copyleft the project

What is needed for this to work:

1. Decoupling config generation from the main script

What is optional but nice to have:

1. YAML config instead of py
2. Jellyfin API key instead of the current login method

What else will I add:

1. Usage of asyncio to run the program indefinitely with an also configurable timeout, alleviating the need to use cronjobs. SIGINT will be able to gracefully stop the script.

[terrelsa13]

I will work on decoupling the config creation from the script.

What are the benefits of changing the config file from .py to .yaml?

The script already uses the Emby/Jellyfin API. The admin username and password are only used during setup to request an API key during the creation of the config file. The password is not stored and only the API key is used after the config is created.

[aleksasiriski]

Yaml is much prettier to read, and easier for beginners to use. It's pretty much de facto standard for config files.

As for the API token, after running the script I don't see it created in API keys section of Jellyfin Admin Dashboard? If that key is tied to the account, what happens if that account changes password, or if it gets deleted?

[terrelsa13]

Got it. Converting the config to yaml will have to be a future change.

The API key is tied to the account. The account must be an Admin account to be able to delete media. If you change the password or delete the account the API key is not longer valid. The config will have to be made again and a new API key created.

How to create the API key was something clara-j (the originator of the script) and I discussed early in the development of the script. We decided not to involve the GUI as a mandatory part of creating the config. However an API key could still be created in the GUI and used for this script. With that said, I could update the config creation to give the user a choice.

[terrelsa13]

I am working on decoupling the the config generation from the script. Are you able to help me understand why this needs to happen? It will help me understand at what level the decoupling needs to happen.

1. Are you asking to have them decoupled so much that users have to run the mumc_generate_config.py first to create the config. And then they run the mumc.py all of the subsequent times to delete media?
2. Or are you asking that I just move all of the config related functions into the mumc_generate_config.py. But users still only run the mumc.py to create the config and to delete media?

[aleksasiriski]

I am working on decoupling the the config generation from the script. Are you able to help me understand why this needs to happen? It will help me understand at what level the decoupling needs to happen.

1. Are you asking to have them decoupled so much that users have to run the `mumc_generate_config.py` first to create the config. And then they run the `mumc.py` all of the subsequent times to delete media?

2. Or are you asking that I just move all of the config related functions into the `mumc_generate_config.py`. But users still only run the mumc.py to create the config and to delete media?

Since I want to eliminate the need for cronjobs, the container itself will run the logic with provided config file. Firstly it will crash saying there's no config file and users will have to run mumc_generate_config.py first to generate the config or manually provide one on their own, and after that the script will work.

[terrelsa13]

How does this affect anyone not running the script in a docker container? It sounds like we are making this more complicated for non-docker users.

Is there a way to detect when this is running in a container vs not running in a container? So the non-container users can have the config auto-build. While the container users can run the external config builder.

[aleksasiriski]

Why not just make a check in the main script, if config isn't generated it will autogenerate it without user's input and also display a log message like "No config detected, generating a basic one. If you want to use an interactive config generator run ./mumc_generate_config.py"

[terrelsa13]

Config needs to know the following things that cannot be assumed without user input.

• Emby or Jellyfin
• Server URL
• API Key
• Which user(s) should be monitored
• Which libraries for each user should be monitored

There is no way to know this information without user input during the config creation.

[terrelsa13]

Trying to wrap my head around how to keep this user friendly for the users who will continue to run this outside of a container.

Or do I misunderstand how this will look in the end? Is the goal to have some kind of "executable" that will run on all operating systems without having to manually install docker specific packages on the machine running it?

[aleksasiriski]

Another solution would be to separate config generator script from the main functionality script, and then make a third script that runs both. Instruct that the third script should be run locally, but docker will use only the functionality one.

[aleksasiriski]

Or do I misunderstand how this will look in the end? Is the goal to have some kind of "executable" that will run on all operating systems without having to manually install docker specific packages on the machine running it?

Docker will have to be installed to run docker container (or other OCI image alternatives like podman, kubernetes, etc.). That will be the only requirement to run this inside docker, whereas for the current setup you must install Python and other app's dependencies.

[terrelsa13]

Another solution would be to separate config generator script from the main functionality script, and then make a third script that runs both. Instruct that the third script should be run locally, but docker will use only the functionality one.

You read my mind here.

3rd File

• mumc.py
  • Call both mumc_get_media.py and mumc_generate_config.py
  • Used when running outside of a container
• mumc_get_media.py
  • Contains the main functionality
  • Used when running inside of a container
• mumc_generate_config.py
  • Contains the config generation
  • When running outside of a container this will be called via mumc.py to generate the config
  • When running inside of a container this will have to be run manually to generate the config

When outside of a container mumc.py is run. When inside of a container mumc_get_media.py is run.

[terrelsa13]

Truly splitting the "functionality" and "config generation" into two separate files is a bigger project I am not able to complete quickly. BUT I have an alternative solution. The script already has the ability to pass in options:

Example - /path/to/python3 /path/to/mumc.py -c /path/to/custom_mumc_config.py

I am going to add a new option -d to tell mumc.py it is being run in a container. With the -d option the config generation part of the script will be disabled.

If I understand the docker/Dockerfile, this is the line that will need to be updated. Not sure which is correct:

ENTRYPOINT ["python", "./mumc.py -d"]

OR?

ENTRYPOINT ["python", "./mumc.py", "-d"]

Do you have any issues going this route?

[aleksasiriski]

Truly splitting the "functionality" and "config generation" into two separate files is a bigger project I am not able to complete quickly. BUT I have an alternative solution. The script already has the ability to pass in options:

Example - /path/to/python3 /path/to/mumc.py -c /path/to/custom_mumc_config.py

I am going to add a new option -d to tell mumc.py it is being run in a container. With the -d option the config generation part of the script will be disabled.

If I understand the docker/Dockerfile, this is the line that will need to be updated. Not sure which is correct:

ENTRYPOINT ["python", "./mumc.py -d"]

OR?

ENTRYPOINT ["python", "./mumc.py", "-d"]

Do you have any issues going this route?

That will work (the second one is more correct). It's still sad that some poor soul decided to write 9000 lines of python code in a single file...

[terrelsa13]

Haha. I am that poor soul so i can only blame myself.

Could be worse; could be 10000 lines of python in a single file.

[terrelsa13]

Just merged your docker updates into the beta branch.

Let me know if the -d option will work the way we need it to work.

[aleksasiriski]

Just enable Actions and it should autobuild a docker image