{"action":"created","issue":{"url":"https://api.github.com/repos/japanesemediamanager/jmmserver/issues/32","repository_url":"https://api.github.com/repos/japanesemediamanager/jmmserver","labels_url":"https://api.github.com/repos/japanesemediamanager/jmmserver/issues/32/labels{/name}","comments_url":"https://api.github.com/repos/japanesemediamanager/jmmserver/issues/32/comments","events_url":"https://api.github.com/repos/japanesemediamanager/jmmserver/issues/32/events","html_url":"https://github.com/japanesemediamanager/jmmserver/issues/32","id":40559514,"number":32,"title":"Multiple AniDB accounts","user":{"login":"jmediamanager","id":6645153,"avatar_url":"https://avatars.githubusercontent.com/u/6645153?v=3","gravatar_id":"","url":"https://api.github.com/users/jmediamanager","html_url":"https://github.com/jmediamanager","followers_url":"https://api.github.com/users/jmediamanager/followers","following_url":"https://api.github.com/users/jmediamanager/following{/other_user}","gists_url":"https://api.github.com/users/jmediamanager/gists{/gist_id}","starred_url":"https://api.github.com/users/jmediamanager/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmediamanager/subscriptions","organizations_url":"https://api.github.com/users/jmediamanager/orgs","repos_url":"https://api.github.com/users/jmediamanager/repos","events_url":"https://api.github.com/users/jmediamanager/events{/privacy}","received_events_url":"https://api.github.com/users/jmediamanager/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/japanesemediamanager/jmmserver/labels/Enhancement%20-%20Core%20Change","name":"Enhancement - Core Change","color":"175DA9"},{"url":"https://api.github.com/repos/japanesemediamanager/jmmserver/labels/Enhancement%20-%20New%20Feature","name":"Enhancement - New Feature","color":"207de5"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2014-08-19T05:35:58Z","updated_at":"2016-08-05T05:10:05Z","closed_at":null,"body":"**Reported by xAndroidNekox, Nov 14, 2012**\r\n\r\nAdd the possibility to add a different AniDB account to every user. Right now only one user can have his AniDB account updated through JMM Desktop/MyAnime, this renders the otherwise great program useless where several people watches anime from one source.\r\n\r\n**jmediamanager**\r\n\r\nCurrently in order for me to use this properly i need to run 3 JMM server instances because there are 3 people using an AniDB account to list their anime, and everyone watches from the same server. Otherwise we would have to use one server on each computer, this would pretty much make the idea of having one central server for all clients not work at all.\r\n\r\n**Nov 14, 2012 xAndroidNekox**\r\n\r\nSeemed to me as an easy thing to store different AniDB and maybe even community sites login details for each account, and when switching users in for example MyAnime have JMM Server use this login information instead. Though it looks like it isnt as easy as it seemed in my head.\r\n\r\nOtherwise it is a great program and hwo knows, there might be a way in the future!\r\n\r\n**Nov 14, 2012  jmediamanager**\r\nYup what you are suggesting is something I looked at.\r\n\r\nHowever the reality this would require a lot of logging in and out.\r\nWhich would be fine in most cases, but if 2+ users were using JMM Server at the same time you have a good chance of getting banned.\r\n\r\ne.g if you have 3 AniDB users, and you add a file to your collection, it means you have to add that file for all 3 users.\r\n\r\nSo in a 1 user scenario (already logged in) you would send\r\nADD FILE\r\n\r\nfor 3 users (1 user logged in)\r\nADD FILE\r\nLOGOUT\r\nLOGIN\r\nADD FILE\r\nLOGOUT\r\nLOGIN\r\nADD FILE\r\n\r\nThere are other sorts of complications which also make it difficult.\r\nI haven't raised the issue with AniDB recently so I will try again\r\n\r\n**Nov 15, 2012  xAndroidNekox**\r\n\r\nOh, I see now that it was a whole lot easier in my head than in reality.\r\n\r\nYes please do that, and if you can would you be able to post an update on the matter here?\r\n\r\nIt would be great if they could add support for this on AniDB, thank you for the hard work and answering my lunatic questions!\r\n\r\n**Nov 22, 2012  inferknox**\r\n\r\nI recently joined AniDB due to finding JMM. When I investigated the site a bit (as I marveled at how JMM was updating it according to my collection, etc), I noticed that it's possible to link one account to another on AniDB.\r\n\r\nThe purpose of the linking is so that a master account can be set that is the regarded as the account that has the collection, whilst the accounts linked to it are marked as using the same collection, but have each account have independent watched/ratings/comments.\r\n\r\nCould JMM not be made to work with this system, by having users set which user account is the master account in JMM (which will correspond with the master account on AniDB), then marking the other accounts as linked accounts?\r\nThat way JMM can only send newly added files data to the master account, but at the same time JMM can be set that when another user (linked) logs into JMM, it will upload only their respective watches/ratings/comments to their individual accounts for that file, which would already be listed as present in their collection, since it was added to the master account they are linked to in AniDB.\r\nIf it can be done, a link to explain what such a setup means in AniDB & JMM, and how to set JMM to achieve this can be made in the users part of JMM.\r\nDoes that make sense? It does to me when I re-read it, but seems like what I'm saying might be confusing.\r\n\r\nhttp://wiki.anidb.net/w/PROFILE_MASTERACCOUNT\r\n\r\n**Nov 22, 2012 jmediamanager**\r\nWow I have been using AniDB for years and didn't know about this.\r\n\r\nUnfortunately it looks like it doesn't solve the problem.\r\nThe UDP API does not allow you to specify a user when you mark a file as watched, vote for an anime etc.\r\nSo I would still need to use the process I described above.\r\n\r\nI haven't talked to the AniDB devs yet so I will mention this as well.\r\nI have posted my request here, if anyone wants to follow it\r\nhttp://anidb.net/perl-bin/animedb.pl?show=cmt&id=45386\r\n\r\n**Nov 23, 2012 inferknox**\r\n\r\nHmm... I looked at the thread and I don't really understand that well. I'm a PC & network technician myself, but I don't do software development. I do somewhat understand the sort of logic to apply in it though, so I think I can perhaps have something to contribute to the thought process.\r\n\r\nTell me, at what level does JMM log in? Is it the JMM server or JMM desktop?\r\nAlso, how does AniDB interpret logins, is it:\r\n- login from a certain app at a certain IP, or\r\n- a certain user from a certain app at a certain IP?\r\nThat is to say, does AniDB recognise distinct traffic from multiple users logged in from the same type of app (eg. all users are using Opera 12.11) from different computers in the same LAN, that connects to AniDB (via NAT) through 1 public IP?\r\n\r\nI'm thinking that\r\n- if AniDB does recognise traffic from several users, using the same exact app type and version, on different computers in a LAN; as distinct traffic, and\r\n- if JMM logs in through JMM desktop,\r\n- then since multiple users using JMM simultaneously will only have 1 instance logged into 1 account per computer, it should work without logouts and logins to AniDB.\r\nAnd since there'll be only 1 master account per JMM network, only that one account will be sending the 'add file to mylist' sort of data, the rest will only be sending watches/ratings/comments data.\r\nJMM could be set that only the JMM server logs into the AniDB master account, whilst having all the accounts linked (on AniDB to the master account) log in on the JMM desktop level.\r\nWhen an individual logs into the master account in JMM desktop, it would simply control the JMM server's interaction with AniDB (which is how I imagine it works now).\r\n\r\nIf AniDB doesn't recognise the traffic from multiple users using the same type of application on 1 IP, then there's a problem.\r\nAlso, if the log into AniDB can only be at the JMM server level, not the JMM desktop, then that is a problem.\r\n\r\nThat's sort of my reasoning. Make sense? Hope so.\r\n\r\n**Nov 23, 2012 jmediamanager**\r\n\r\nJMM Server handles all the communications to AniDB (as well as all the hashing etc)\r\nJMM desktop just connects to jmm server.\r\n\r\nMoving this logic to the JMM desktop level would be much harder for me than my proposed solution.\r\n\r\nNote - to send any commands to the anidb udp server you must be logged in. ie retrieving file information when hashing, and so this logic is not user specific, and must be kept at the server level.\r\n\r\nNote - when i read about AniDB master accounts, it says that you can't actually mark a file as watched. I haven't tested it though.\r\n\r\n**Nov 23, 2012 radioragunda**\r\n\r\nJust when I was thinking about the log in/out problem of several users, i read in the request on AniDB that ommina had already answered my thoughts. Letting JMM server add all episodes at once for one user then switch and add it to the next user, would be the same as everyone adding it themselves. Using your list for 3 users (1 logged in) maybe it would be even less hammering on the server as JMM would send:\r\n\r\nADD FILE\r\nLOGOUT\r\nLOGIN\r\nADD FILE\r\nLOGOUT\r\nLOGIN\r\nADD FILE\r\n\r\nInstead of manually adding (1/3 users):\r\nLOGIN\r\nADD FILE\r\nLOGOUT\r\n\r\nI might be wrong, but it makes sense to me.\r\n\r\n**Nov 23, 2012 jmediamanager**\r\n\r\nYeah I think we are agreeing, I suggested that the add files requested be grouped by user\r\n\r\n**Nov 23, 2012 inferknox**\r\n\r\nI think then refining the communications would be the best way. I think making JMM users link accounts on AniDB, and identifying (in JMM) which is the master account and which are the linked accounts would still be helpful. It would allow you to set JMM not to send any data regarding new files, only to send about ratings/etc, since the files would be auto-added to linked accounts from the master account (within AniDB). Then besides that, JMM could be set to highly prioritise the master account traffic and only send link-account data at certain intervals and perhaps at certain events, like logins & logouts (in JMM), etc. It would minimise the logins & logouts to AniDB and reduce the \"commands sent per user\", which the AniDB mod said would be a positive thing.\r\nSound okay?\r\n\r\n**Nov 24, 2012 jmediamanager**\r\n\r\nI'm pretty sure that if you have a master account set (you are slave) that you cannot mark any files watched.\r\nWhich would make it pretty useless in this situation.\r\n\r\nBut I will test it out to make sure.\r\nNOTE the ADD FILE command is also the same command used to mark a file/episode as watched\r\nie you do a ADD file with the watched date parameter set\r\n\r\n**Nov 24, 2012 inferknox**\r\n\r\nI may be wrong, but it seems to say you can on the last sentence of:\r\nthe \"Set Master Account\" section here:\r\nhttp://wiki.anidb.net/w/PROFILE_MASTERACCOUNT\r\n\r\nAh, I see now about the command. Hmm... I guess testing would be necessary then to know for sure if it's possible to use the command for slave accounts to mark watched files, etc.\r\nWhich other apps make use of these commands? I ask, wondering if it is feasible to hope for AniDB to change the watched command if need be.\r\n\r\n**Nov 24, 2012 inferknox**\r\n\r\nOh, wait... I just saw in the note that it can't be done. So maybe to request addition of the feature, since it says it may be added in the future. Worth requesting. I would also back up the request and ask others I've introduced to JMM to do the same. :)\r\n\r\n**Nov 24, 2012 jmediamanager**\r\n\r\nI have suggested that on the AniDB thread.\r\nProbably best to leave it with the AniDB guys though, they probably won't be persuaded by numbers anyway.\r\n\r\n**Nov 25, 2012 inferknox**\r\n\r\nHmph, so judging by the response in the AniDB thread & the connections being made by JMM server, all the limitations are set.\r\nThat being the case... if you're going to go ahead with adding the feature to JMM, perhaps spacing out the logins and logouts could be best way to mitigate how server intensive JMM's interaction with AniDB is. Like perhaps having the add file command only get sent for JMM users are are already logged in & upon the event of a JMM user logging in?\r\nI know you've probably thought of that and more already, just throwing it out there anyway. :)\r\n\r\n**Nov 25, 2012  jmediamanager**\r\n\r\nHmm although that makes sense, it won't be transparent to most users.\r\nie if one user bulk imports 100 files, other users would expect them to appear on their anidb website as well.\r\nWaiting until they login might be confusing.\r\nEspecially since the UDP api is limited to one command every 2 seconds.\r\n\r\nAlso the in the response to the ADD FILE command, it gets the user's watched state/date, so it is good to have that ahead of time.\r\n\r\nTo be honest I haven't even figured out out how I will batch the commands yet, because the architecture isn't designed like that. It basically puts all the commands on a queue. You can give them a processing priority, but not order them by anything else.\r\n\r\n**Dec 4, 2012 xAndroidNekox**\r\n\r\nBut i have to say, as ommina at AniDB gave the green light it feels as it's just a matter of code before this is reality. How many levels of processing priorities are available? Is it just a matter of low, medium and high or something like lowest, low, medium, high and highest? And will the program follow the priorities to the fullest? If the latter was correct then you could put the queuing on different levels for each user. Sounds a little roundabout but it should work in theory. Otherwise is it not possible to queue all commands for one user first as usual then add logout-login and then queue the commands again? Or is the program processing the queue randomly? Im definitely out running on thin ice here but that's what i came up with thinking about it a little.\r\n\r\n**Dec 5, 2012 jmediamanager**\r\n\r\nThere are currently 15 levels of priority, but there is no actual limit.\r\nYup I have basically planned out how I will do it, and it does involve using a different priority for each user.\r\n\r\nFor my own notes, just in case I forget how I planned to do it...\r\n\r\nNew Table - AniDB_Credential\r\n- Username\r\n- Password \r\n- IsPrimaryUser\r\n- QueuePriority\r\n\r\nMigration\r\n---------\r\n- AniDB login in config file to be moved to a new record in the AniDB_Credential table. This will be marked as the primary user\r\n- IsAniDBUser field on user records will no longer be used. Instead each user can be linked to an anidb credential instead\r\n- Current users will be linked to the newly created credential\r\n- Remove creation of the \"Family Friendly\" user from initial database population\r\n- Initial database population to create and attach Primary User credential\r\n- All CommandRequest records relating to mylist commands to be deleted (as they will now be user specific)\r\n\r\nRules\r\n-----\r\n- Only one user can be the primary user\r\n- Primary user credential will be used for the initial login (although this is not really important)\r\n- When creating a user, option will be given to create or link to an anidb credential\r\n- QueuePriority on a credential will have a minimum value of 50 and a maximum value of 5000 (everything below is reserved for JMM use)\r\n  - When creating a new credential look at the current maximum and increment by 1\r\n- QueuePriority must be unique ie credentials cannot share the same priority\r\n- Changes to AniDB user specific commands\r\n  - All following commands to now include the Credential ID\r\n  - MYLISTADD : Priority = Credential Priority\r\n  - VOTE: Priority = Credential Priority + 5001\r\n  - MYLISTDEL: Priority = Credential Priority + 5002\r\n  - MYLISTSTATS: Priority = Credential Priority + 5003\r\n- When creating a new credential, or attaching an existing credential to a user, use the MYLIST HTTP command to get and update all recoords for that user (if they were already using AniDB)\r\n- Do not allow the user to remove the PrimaryUser flag, it can only be switched\r\n\r\n\r\nGuidance\r\n--------\r\n- Change the user creation process to work on a background thread\r\n- Advise the user that additional credentials/users (beyond the primary user) should not be created until the collection is fully imported (although not mandatory)\r\n- Advise the user that adding AniDB credentials can significantly increase processing time of a collection\r\n\r\nFuture Changes\r\n--------------\r\n- Allow default images (fanart, posters etc) to be set per user\r\n\r\n\r\n**Apr 9, 2013 diggzbox**\r\n\r\nWhat are the chances of extending this to other social accounts? In particular: MyAnimeList."},"comment":{"url":"https://api.github.com/repos/japanesemediamanager/jmmserver/issues/comments/237756587","html_url":"https://github.com/japanesemediamanager/jmmserver/issues/32#issuecomment-237756587","issue_url":"https://api.github.com/repos/japanesemediamanager/jmmserver/issues/32","id":237756587,"user":{"login":"bigretromike","id":6052025,"avatar_url":"https://avatars.githubusercontent.com/u/6052025?v=3","gravatar_id":"","url":"https://api.github.com/users/bigretromike","html_url":"https://github.com/bigretromike","followers_url":"https://api.github.com/users/bigretromike/followers","following_url":"https://api.github.com/users/bigretromike/following{/other_user}","gists_url":"https://api.github.com/users/bigretromike/gists{/gist_id}","starred_url":"https://api.github.com/users/bigretromike/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bigretromike/subscriptions","organizations_url":"https://api.github.com/users/bigretromike/orgs","repos_url":"https://api.github.com/users/bigretromike/repos","events_url":"https://api.github.com/users/bigretromike/events{/privacy}","received_events_url":"https://api.github.com/users/bigretromike/received_events","type":"User","site_admin":false},"created_at":"2016-08-05T05:10:05Z","updated_at":"2016-08-05T05:10:05Z","body":"I would like this with this issue: #337 as current the only user is stored in .config moving to db will help us make more account for users."}}
{"actor":{"display_login":"bigretromike"}}