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

[Feature Request] Structured way of specifying configs #198

Open
Splinter7914 opened this issue Sep 16, 2024 · 7 comments
Open

[Feature Request] Structured way of specifying configs #198

Splinter7914 opened this issue Sep 16, 2024 · 7 comments

Comments

@Splinter7914
Copy link

Splinter7914 commented Sep 16, 2024

Having a more structured way of specifying configs could allow users to specify any number of servers and sync them how they please. For example

  • top level sync object controls what servers we sync and in what direction
  • Users section can be used to provide mapping of user names between servers and also override sync settings.
{
    "sync": {
        "plex": [
            "emby"
        ],
        "Jelly": [
            "Plex2",
            "Plex"
        ]
    },
    "users": {
        "user1": {
            "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
            "plex": "my name in plex",
            "plex2": "my name in plex2",
        }
    },
    "servers": {
        "plex": {

        },
        "plex2": {
            
        },
        "emby": {
            
        },
        "jellyfin": {
            
        }
    },
    "libraries": {
        "name1": {
            "plex": "name in plex",
            "emby": "name in emby"
        }
    }
}

If we want to remain backwards compatible that is doable. Something along the lines of:

  • new code understands the new configuration object only.
  • At startup we determine if new config object is present. If not we take existing env vars and dynamically create the expected config and pass that to the code to run.
  • Eventually we would retire the old configs and ask users to migrate to the new object.

Some unknowns:

  • how do we specify block/allow user list.
  • how would we specify library mapping between servers. May be this is sub section inside each server block?
@Splinter7914
Copy link
Author

Thinking about this more we could make users like

 "users": {
        "user1": {
            "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
            "names": ["name in plex", "name in jellyfin", "etc"]
        }
    }

So the user just gives us a list of all the names the same user has and as we read users from a system we see use this to determine what user it maps to and also store the name of the user in a given server. We could do similar with libraries etc. Would make the the json a little less complicated.

User object in python would store the sync override settings for a user, a list of names for the user and then a key value pair of server name and its name in that server.

@luigi311
Copy link
Owner

luigi311 commented Sep 20, 2024

Yeah that structure sounds good.

So we would do the user mapping from user1 to "name in plex" and "name in jellyfin" and "etc" and sync all watch progress from user1 to all of those existing names on each server. That makes sense to me.

users would be

"users": {
        "user1": {
             "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
            "names": ["user", "etc"]
        },
        "user2": {}
}

user 1 is only synced from Jelly to Plex and Plex2 and it can match on user1, user and etc
user2 follows the main sync and is matched only on the name user2

libraries would then be

"libraries": {
      "Movies": {},
      "Shows": {
           "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
           "names": ["Tv Shows", "TV Shows"]
       },
       "Anime Shows": {}
}

Movies and Anime Shows to all servers that have a library with the exact same name
Shows will match only from Jelly to Plex and Plex2 where the names are either Shows, Tv Shows, TV Shows.

@luigi311
Copy link
Owner

Here is a fully complete json for documentation purposes

{
    "sync": {
        "plex": [
            "emby"
        ],
        "Jelly": [
            "Plex2",
            "Plex"
        ]
    },
    "users": {
        "user1": {
             "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
            "names": ["user", "etc"]
        },
        "user2": {}
    },
    "libraries": {
      "Movies": {},
      "Shows": {
           "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
           "names": ["Tv Shows", "TV Shows"]
       },
       "Anime Shows": {}
    },
    "servers": {
        "plex1": {
            "type": "plex",
            "baseurl": "http://localhost:32400",
            "token": "SuperSecretToken"
        },
        "plex2": {
            "type": "plex",
            "baseurl": "https://nas:32400",
            "token": "AnotherSuperSecretToken"
        },
        "emby1": {
            "type": "emby",
            "baseurl": "http://localhost:8097",
            "token": "SuperSecretToken"
        },
        "emby2": {
            "type": "emby",
            "baseurl": "http://another_emby:8097",
            "token": "AnotherSuperSecretToken"
        },
        "jellyfin1": {
            "type": "jellyfin",
            "baseurl": "http://localhost:8096",
            "token": "SuperSecretToken"
        },
        "jellyfin2": {
            "type": "jellyfin",
            "baseurl": "http://nas:8096",
            "token": "AnotherSuperSecretToken"
        }
    }
}

@Splinter7914
Copy link
Author

Splinter7914 commented Sep 20, 2024

over all I think this looks good. Based on how the code end's up being you might want to tweak it.

What I was thinking was as we read users from the system we create a user object store the name from various servers for that user (if that user has different names)

Then when we are doing lookup's we do not check if this user name is in the list, instead we just query the above object and say give me this users name in plex etc. Figured that might make the code easier to write. Just a thought :). Similar approach could be done for libraries as well.

When I was reading the code I was seeing various checks where we were checking for the user in keys and values which I found hard to follow.

Also we can have sync override settings at library level as well? What would be the order of preference?

For example lets say

global: sync plex -> jelly + emby
user1: sync plex -> emby
library1: sync plex -> jelly

What would/should we do in this case?

when we sync libraray1 from plex to jelly we do it for all users expect for user1?

@luigi311
Copy link
Owner

Also we can have sync override settings at library level as well? What would be the order of preference?
For example lets say
global: sync plex -> jelly + emby
user1: sync plex -> emby
library1: sync plex -> jelly
What would/should we do in this case?
when we sync libraray1 from plex to jelly we do it for all users expect for user1?

I think it would go library > user > global in order of preference so yes what you said was correct. library 1 is synced from plex to jelly for all users except user1.

@luigi311
Copy link
Owner

One thing this new structure is missing is a blacklist option. Whitelist is handled by including the options you want for users and libraries since without it it will do all objects.

@luigi311
Copy link
Owner

luigi311 commented Nov 9, 2024

Another thing to keep in mind is this change will break unraid since theres no real easy way to handle something like this so the old method will have to stick around and have a function that converts it to the new structure like mentioned before.

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

No branches or pull requests

2 participants