Open Splinter7914 opened 2 months ago
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.
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.
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"
}
}
}
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?
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.
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.
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.
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
If we want to remain backwards compatible that is doable. Something along the lines of:
Some unknowns: