Multiple AniDB accounts

[GoogleCodeExporter]

Add 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.

Currently 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.

Original issue reported on code.google.com by xAndroid...@gmail.com on 14 Nov 2012 at 3:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi!

Ok that is a shame.

Seemed 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.

Otherwise it is a great program and hwo knows, there might be a way in the 
future!

Original comment by xAndroid...@gmail.com on 14 Nov 2012 at 11:24

[GoogleCodeExporter]

Yup what you are suggesting is something I looked at.

However the reality this would require a lot of logging in and out.
Which 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.

e.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.

So in a 1 user scenario (already logged in) you would send
ADD FILE

for 3 users (1 user logged in)
ADD FILE
LOGOUT
LOGIN
ADD FILE
LOGOUT
LOGIN
ADD FILE

There are other sorts of complications which also make it difficult.
I haven't raised the issue with AniDB recently so I will try again

Original comment by werndly...@gmail.com on 15 Nov 2012 at 1:50

[GoogleCodeExporter]

Oh, I see now that it was a whole lot easier in my head than in reality.

Yes please do that, and if you can would you be able to post an update on the 
matter here?

It would be great if they could add support for this on AniDB, thank you for 
the hard work and answering my lunatic questions!

Original comment by xAndroid...@gmail.com on 15 Nov 2012 at 12:40

[GoogleCodeExporter]

I 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.

The 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.

Could 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?
That 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.
If 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.
Does that make sense? It does to me when I re-read it, but seems like what I'm 
saying might be confusing.

http://wiki.anidb.net/w/PROFILE_MASTERACCOUNT

Original comment by inferk...@gmail.com on 22 Nov 2012 at 4:23

[GoogleCodeExporter]

Wow I have been using AniDB for years and didn't know about this.

Unfortunately it looks like it doesn't solve the problem.
The UDP API does not allow you to specify a user when you mark a file as 
watched, vote for an anime etc.
So I would still need to use the process I described above.

I haven't talked to the AniDB devs yet so I will mention this as well.

Original comment by werndly...@gmail.com on 22 Nov 2012 at 8:55

[GoogleCodeExporter]

I have posted my request here, if anyone wants to follow it
http://anidb.net/perl-bin/animedb.pl?show=cmt&id=45386

Original comment by werndly...@gmail.com on 22 Nov 2012 at 10:48

[GoogleCodeExporter]

Hmm... 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.

Tell me, at what level does JMM log in? Is it the JMM server or JMM desktop?
Also, how does AniDB interpret logins, is it:
- login from a certain app at a certain IP, or
- a certain user from a certain app at a certain IP?
That 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?

I'm thinking that
- 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
- if JMM logs in through JMM desktop,
- 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.
And 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.
JMM 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.
When 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).

If AniDB doesn't recognise the traffic from multiple users using the same type 
of application on 1 IP, then there's a problem.
Also, if the log into AniDB can only be at the JMM server level, not the JMM 
desktop, then that is a problem.

That's sort of my reasoning. Make sense? Hope so.

Original comment by inferk...@gmail.com on 23 Nov 2012 at 6:34

[GoogleCodeExporter]

JMM Server handles all the communications to AniDB (as well as all the hashing 
etc)
JMM desktop just connects to jmm server.

Moving this logic to the JMM desktop level would be much harder for me than my 
proposed solution.

Note - 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.

Note - 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.

Original comment by werndly...@gmail.com on 23 Nov 2012 at 11:59

[GoogleCodeExporter]

Just 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:

ADD FILE
LOGOUT
LOGIN
ADD FILE
LOGOUT
LOGIN
ADD FILE

Instead of manually adding (1/3 users):
LOGIN
ADD FILE
LOGOUT

I might be wrong, but it makes sense to me.

Original comment by radiorag...@gmail.com on 24 Nov 2012 at 12:54

[GoogleCodeExporter]

Yeah I think we are agreeing, I suggested that the add files requested be 
grouped by user
(I am jonbaby on AniDB)

Original comment by werndly...@gmail.com on 24 Nov 2012 at 5:14

[GoogleCodeExporter]

I 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.
Sound okay?

Original comment by inferk...@gmail.com on 24 Nov 2012 at 7:49

[GoogleCodeExporter]

I'm pretty sure that if you have a master account set (you are slave) that you 
cannot mark any files watched.
Which would make it pretty useless in this situation.

But I will test it out to make sure.
NOTE the ADD FILE command is also the same command used to mark a file/episode 
as watched
ie you do a ADD file with the watched date parameter set

Original comment by werndly...@gmail.com on 24 Nov 2012 at 11:44

[GoogleCodeExporter]

I may be wrong, but it seems to say you can on the last sentence of:
the "Set Master Account" section here:
http://wiki.anidb.net/w/PROFILE_MASTERACCOUNT

Ah, 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.
Which 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.

Original comment by inferk...@gmail.com on 24 Nov 2012 at 4:36

[GoogleCodeExporter]

Oh, 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. :)

Original comment by inferk...@gmail.com on 24 Nov 2012 at 4:40

[GoogleCodeExporter]

I have suggested that on the AniDB thread.
Probably best to leave it with the AniDB guys though, they probably won't be 
persuaded by numbers anyway.

Original comment by werndly...@gmail.com on 25 Nov 2012 at 1:42

[GoogleCodeExporter]

Hmph, so judging by the response in the AniDB thread & the connections being 
made by JMM server, all the limitations are set.
That 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?
I know you've probably thought of that and more already, just throwing it out 
there anyway. :)

Original comment by inferk...@gmail.com on 25 Nov 2012 at 8:02

[GoogleCodeExporter]

Hmm although that makes sense, it won't be transparent to most users.
ie if one user bulk imports 100 files, other users would expect them to appear 
on their anidb website as well.
Waiting until they login might be confusing.
Especially since the UDP api is limited to one command every 2 seconds.

Also 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.

To 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.

Original comment by werndly...@gmail.com on 25 Nov 2012 at 7:59

[GoogleCodeExporter]

But 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.

Original comment by xAndroid...@gmail.com on 4 Dec 2012 at 5:16

[GoogleCodeExporter]

There are currently 15 levels of priority, but there is no actual limit.
Yup I have basically planned out how I will do it, and it does involve using a 
different priority for each user.

For my own notes, just in case I forget how I planned to do it...

New Table - AniDB_Credential
- Username
- Password 
- IsPrimaryUser
- QueuePriority

Migration
---------
- 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
- IsAniDBUser field on user records will no longer be used. Instead each user 
can be linked to an anidb credential instead
- Current users will be linked to the newly created credential
- Remove creation of the "Family Friendly" user from initial database population
- Initial database population to create and attach Primary User credential
- All CommandRequest records relating to mylist commands to be deleted (as they 
will now be user specific)

Rules
-----
- Only one user can be the primary user
- Primary user credential will be used for the initial login (although this is 
not really important)
- When creating a user, option will be given to create or link to an anidb 
credential
- QueuePriority on a credential will have a minimum value of 50 and a maximum 
value of 5000 (everything below is reserved for JMM use)
  - When creating a new credential look at the current maximum and increment by 1
- QueuePriority must be unique ie credentials cannot share the same priority
- Changes to AniDB user specific commands
  - All following commands to now include the Credential ID
  - MYLISTADD : Priority = Credential Priority
  - VOTE: Priority = Credential Priority + 5001
  - MYLISTDEL: Priority = Credential Priority + 5002
  - MYLISTSTATS: Priority = Credential Priority + 5003
- 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)
- Do not allow the user to remove the PrimaryUser flag, it can only be switched

Guidance
--------
- Change the user creation process to work on a background thread
- Advise the user that additional credentials/users (beyond the primary user) 
should not be created until the collection is fully imported (although not 
mandatory)
- Advise the user that adding AniDB credentials can significantly increase 
processing time of a collection

Future Changes
--------------
- Allow default images (fanart, posters etc) to be set per user

Original comment by werndly...@gmail.com on 5 Dec 2012 at 10:14

[GoogleCodeExporter]

Original comment by werndly...@gmail.com on 21 Dec 2012 at 2:33

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

What are the chances of extending this to other social accounts? In particular: 
MyAnimeList.

Original comment by diggz...@gmail.com on 10 Apr 2013 at 5:22

[GoogleCodeExporter]

https://github.com/japanesemediamanager/jmmserver/issues/32

Original comment by werndly...@gmail.com on 19 Aug 2014 at 5:36

• Changed state: Migrated