Ommina

Latest revision as of 22:55, 16 October 2017

--> Edit FILE docs to include MyList data block <--

CATEGORY: Retrieve Category Data

SIMILAR: Approve or Disapprove of a Similar Pairing

Command String:

SIMILAR entity=1&id1={int4 id}&id2={int4 id}[&approve={str [y|n|r]}]

Possible Replies:

275 SIMILAR APPROVAL

{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str [y|n]}

276 SIMILAR APPROVAL FOUND

{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str [y|n]}

277 SIMILAR APPROVAL UPDATED

{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str [y|n]}

278 SIMILAR APPROVAL REVOKED

{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str r}

375 NO SUCH SIMILAR PAIRING

{int entity}|{int id1}|{int id2}

376 NO SUCH SIMILAR PAIRING APPROVAL

Info:

entity is always 1.
id1 and id2 represent an existing pair of ids. There are no provisions for adding new similar pairs
Which id is assigned to id1 and which id is assigned to id2 is irrelevant
Use approval=y to approve the pair, approve=n to disapprove, and approve=r to revoke (delete) an existing approval/disapproval.
If an approval vote is already assigned, submitting a new y/n value will replace the old vote.

UPDATED: Get List of Updated Anime IDs

Returns a list of AniDB anime ids of anime that have been updated in in a given time frame, ordered by descending date.

Command String:

UPDATED entity=1&[age={int4 id}|time={int4 date}]

Possible Replies:

243 UPDATED

{int entity}|{int total count}|{int last update date}|{list aid}

343 NO UPDATES

Info:

entity is always 1
Either age OR time can be specified, but not both
age is specified in days.
- eg: age=30 requests a list of aid values of anime that have changed in the past 30 days
time is specified in unix time.
- eg: time=1264982400 requests a list of aid values of anime that have changed since 2010-02-01
A maximum of 200 values will be returned
count specifies the total number of items found for the given time period. In short, if this value is great than 200, you have not retrieved all applicable ids.
last update date will contain the AniDB update time of the last aid to appear on the list

An anime will be considered updated if:

A change is made to the anime record itself
An main or official anime title is added, edited, or deleted (not short or synonym)
An episode for the anime is added, or delete (but NOT edited!) ( --> But perhaps airdate changes should <-- )
An episode title is added, edited, or delete
An anime category is added, or deleted (but NOT edited: eg, weight change)
An anime relation is added, or deleted

REVIEW: Get Anime Review

Retrieves the review scores and text for an anime review. Like ANIMEDESC, it will likely take multiple calls to this comment to retrieve a complete review - almost all reviews will overflow the size limits of a UDP packet.

Command String:

REVIEW rid={int4 id}

Possible Replies:

234 REVIEW

{int4 current part}|{int4 max parts}|{int4 review id}|{int4 author uid}|{int4 score_animation}|{int4 score_sound}|{int4 score_story}|{int4 score_character}|{int4 score_value}|{int4 score_enjoyment}|{str review_text}

234 REVIEW

{int4 current part}|{int4 max parts}|{str review_text}

334 NO SUCH REVIEW

Info:

IDs and scores are returned with part zero only. Parts one through max exclude the scores and return the text block only.

[Maybe exchange author uid for author name. Or a uid->name lookup via USER?]

WISHLIST: Retrieve Wishlist Data

Retrieve wishlist data.

Command String:
full list:

WISHLIST

by aid:

WISHLIST aid={int4 aid}

by wishlist id:

WISHLIST lid={int4 lid}

by priority:

WISHLIST priority={int4 priority}

Possible Replies:

by aid, lid:

223 WISHLIST

{int4 lid}|{int4 aid}|{int2 type}|{int2 priority}|{int4 fromuid}|{str comment}|{int4 adddate}

full list, by priority:

229 MULTIPLE WISHLIST ITEMS

{int4 aid}|{int4 type}|{int4 priority}/n

..repeated n times

323 NO SUCH WISHLIST ITEM

Info:

Priority values are 0: low, 1: medium, 2: high
Type values are 1: to watch, 2: to get
Multiple items are returned in descending priority (high priority first)
The fromuid field represents the uid of the user that created the wishlist entry. Typically this is the actual user, but could be a buddy.

WISHLISTADD: Add Anime to Wishlist

Command String:

WISHLISTADD aid={int4 aid}&type={int2 type}&priority={int2 priority}[&comment={str comment}]

226 WISHLIST ITEM ADDED

{int4 wishlist id}

228 WISHLIST ITEM UPDATED

{int4 wishlist id}

WISHLISTDEL: Remove Anime from Wishlist

NOTIFICATION: Retrieve Notification Date

NOTIFICATIONADD: Add Anime or Group to Notify List

Command String:

by anime id:

NOTIFICATIONADD aid={int4 aid}&type={int2 type}&priority={int2 priority}

by group id:

NOTIFICATIONADD gid={int4 gid}&type={int2 type}&priority={int2 priority}

Possible Replies:

246 NOTIFICATION ITEM ADDED

{int4 notification id}

248 NOTIFICATION ITEM UPDATED

{int4 notification id}

399 NO CHANGES

Info:

Priority values are 0: low, 1: medium, 2: high
Type values are 0: all, 1: new, 2: group, 3: complete

NOTIFICATIONDEL: Remove Anime or Group from Notify List

Command String:

by anime id:

NOTIFICATIONDEL aid={int4 aid}

by group id:

NOTIFICATIONDEL gid={int4 gid}

Possible Replies:

247 NOTIFICATION ITEM DELETED

{int4 notification_table}|{int4 relid}

324 NO SUCH NOTIFICATION ITEM

Info:

notification_table values are 1: anime, 2: group
relid value matches the aid/gid supplied

Empty Table

Byte 1
Bit	Decimal	Data Field
0	1	String
1	2	String
2	4	String
3	8	String
4	16	String
5	32	String
6	64	String
7	128	String

Permissions (badges)

[22 Jan 12 16:57] * Ommina: baka gives good advice.  Let's get the permission thing fully figured out.  If I'm going to stop playing minecraft, I don't want to have to redo stuff.  (and now gone for food.)
[22 Jan 12 17:04] * worf: well ... what do we have
[22 Jan 12 17:04] * worf: we have a set of personal settings that only affect you
[22 Jan 12 17:05] * worf: hiding thumbnails, hiding all images, hiding porn images, hiding all porn
[22 Jan 12 17:06] * worf: but those dont need to be considered in the xml
[22 Jan 12 17:07] * worf: and then we have the permissions 
[22 Jan 12 17:07] * worf: see me in user list, see my anime list, see storage info, see source info, see viewed info, see ep info, see file info, see state info, see my votes, see my wishlist, see my userpage, see my porn
[22 Jan 12 17:08] * worf: see my porn - obviously would apply to the hentai badge
[22 Jan 12 17:09] * worf: see my anime list - should apply to all anime and creator badges
[22 Jan 12 17:09] * DerIdiot: see my anime list/see viewed info/see ep info/see my votes are the ones that matter
[22 Jan 12 17:11] * worf: see my votes shouldnt matter
[22 Jan 12 17:11] * DerIdiot: wasn't sure if you have some badge with them
[22 Jan 12 17:11] * DerIdiot: if not then yes it doesn't
[22 Jan 12 17:11] * worf: there is a counter badge
[22 Jan 12 17:11] * worf: but we are already displaying the number of votes on the userpage anyway
[22 Jan 12 17:12] * worf: i dont think that permission hides the counter either
[22 Jan 12 17:12] * DerIdiot: i'm not 100% sure, but if not then yes you cna ignore it
[22 Jan 12 17:14] * worf: the only usage of PERM_SEEVOTES on the userpage appears to be for hiding the latest votes
[22 Jan 12 17:17] * worf: so ... 
[22 Jan 12 17:17] * worf: PERM_SEEMYPORN for the hentai badge
[22 Jan 12 17:18] * worf: PERM_SHOWMYLIST for all anime and creator based badges including the hentai badge
[22 Jan 12 17:18] * worf: PERM_VIEWEDINFO same as the above i guess
[22 Jan 12 17:20] * worf: PERM_EPINFO shouldnt apply since we arent displaying which episodes have been watched. just how many
[22 Jan 12 17:22] * DerIdiot: PERM_EPINFO says that somethign is in mylist; PERM_VIEWEDINFO does the same + says that it's watched
[22 Jan 12 17:25] * worf: if you have PERM_SHOWMYLIST on "everyone" and PERM_EPINFO on "no one" then you can only see which anime a person has but not which episodes
[22 Jan 12 17:25] * DerIdiot: yes
[22 Jan 12 17:25] * worf: hm, ok
[22 Jan 12 17:25] * worf: it hides the counts too
[22 Jan 12 17:26] * worf: k
[22 Jan 12 17:26] * DerIdiot: but you only got watched badges not collecting ones right?
[22 Jan 12 17:26] * worf: yes
[22 Jan 12 17:26] * DerIdiot: then PERM_VIEWEDINFO is enough
[22 Jan 12 17:26] * DerIdiot: should prolly have PERM_SHOWMYLIST and PERM_VIEWEDINFO
[22 Jan 12 17:27] * worf: hmm

EPISODEDESC: Retrieve Episode Description

Command String:
by eid

EPISODEDESC eid={int eid}

Possible Replies:

241 EPISODE DESCRIPTION

{int4} eid|{str description}

341 NO DESCRIPTION

Info:

Be aware of the UDP packet size limits. As of this writing, fewer than one percent of all episode descriptions will not fit into one packet. That value falls further if compression is enabled. Nonetheless, some especially enthusiastic descriptions will be truncated as necessary.

@@ Line 1: / Line 1: @@
-== Notify Commands ==
+{{TOCright}}
-=== Introduction ===
+--> Edit FILE docs to include MyList data block <--
-Broadly speaking, notifications provide an indication to the client that some event has occurred within the AniDB database.
+=== CATEGORY: Retrieve Category Data ===
-There are three types:
+=== SIMILAR: Approve or Disapprove of a Similar Pairing ===
-* New file [[Notifications|notification]]. (Only anime type supported.)
-* New private message notification.
-* New buddy event notification.
-Note that, while a user can subscribe to multiple 'new file' events (see [[Notifications|notifications]]), at present, the UDP API only supports notifications of new files by anime.  New files by group, or new files by producer, are NOT presently supported.  Just the same, keeping in mind that the API is designed to potentially support such notifications in the future will help in understanding why some of the commands are structured the way they are.
+'''Command String:'''
+* SIMILAR entity=1&id1={int4 id}&id2={int4 id}[&approve={str [y|n|r]}]
-The word "notification" is also used a bit inconsistently in this document.  An AniDB notification is originally a "new file [[Notifications|notification]]". It might be more correct to use the term "event" for the original "happening" and then "notification" as the means to notify the user (client). New-file, new-message, buddy-* and going-down are all events that results in notifications. Only the first two type of events are persistent, though, meaning they exist and remain in the same state until some user action affects them.
+'''Possible Replies:'''
+* 275 SIMILAR APPROVAL
+{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str [y|n]}
+* 276 SIMILAR APPROVAL FOUND
+{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str [y|n]}
+* 277 SIMILAR APPROVAL UPDATED
+{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str [y|n]}
+* 278 SIMILAR APPROVAL REVOKED
+{int entity}|{int sid}|{int id1}|{int id2}|{int total}|{int approved}|{str r}
-=== Getting Notifications ===
+* 375 NO SUCH SIMILAR PAIRING
+{int entity}|{int id1}|{int id2}
+* 376 NO SUCH SIMILAR PAIRING APPROVAL
-Clients that wish to receive notifications have two routes available to them.  They are by no means mutually exclusive and selecting one does not imply a client is unable to use commands from another.
+'''Info:'''
+* ''entity'' is always 1.
+* ''id1'' and ''id2'' represent an ''existing'' pair of ids.  There are no provisions for ''adding'' new similar pairs
+* Which id is assigned to ''id1'' and which id is assigned to ''id2'' is irrelevant
+* Use ''approval=y'' to approve the pair, ''approve=n'' to disapprove, and ''approve=r'' to revoke (delete) an existing approval/disapproval.
+* If an approval vote is already assigned, submitting a new ''y''/''n'' value will replace the old vote.
-'''Method One: Polling'''
+=== UPDATED: Get List of Updated Anime IDs ===
+Returns a list of AniDB anime ids of anime that have been updated in in a given time frame, ordered by descending date.
-With this method, the client contacts the server at some interval (no more than once every 20 minutes) to see if there are new file notifications waiting.  If there are, the client can the get further details of the files in question.  This is analogous to checking an email server every half hour to see if new email has arrived.
+'''Command String:'''
+* UPDATED entity=1&[age={int4 id}|time={int4 date}]
-Its principal advantage is that it is easy to design and code.  Blocking sockets are sufficient as the client can expect the reply received to correspond with the command sent.
+'''Possible Replies:'''
+* 243 UPDATED
+{int entity}|{int total count}|{int last update date}|{list aid}
-The disadvantage of this approach is that it introduces a delay and some uncertainty in receiving notifications.  If, for example, the user clears the notification on the website before the client collects it, the client will not learn of the new file.  Similarly, if the user does not dismiss notifications via the site, the client will have an increasing amount of stale data to work though.  Finally, notifications cleared by the client also clears them from the website, so users will need to be made aware of what is going on.
+* 343 NO UPDATES
-A polling HOWTO:
+'''Info:'''
+* ''entity'' is always 1
+* Either ''age'' OR ''time'' can be specified, but not both
+* ''age'' is specified in days.
+** eg: age=30 requests a list of aid values of anime that have changed in the past 30 days
+* ''time'' is specified in unix time.
+** eg: time=1264982400 requests a list of aid values of anime that have changed since 2010-02-01
+* A maximum of 200 values will be returned
+* ''count'' specifies the total number of items found for the given time period.  In short, if this value is great than 200, you have not retrieved all applicable ids.
+* ''last update date'' will contain the AniDB update time of the ''last'' aid to appear on the list
-* Use NOTIFY (no more than once every 20 minutes) to get the number of pending notifications
+'''An anime will be considered updated if:'''
-* IF there are new notifications pending, use NOTIFYLIST to get a list of notification types and associated IDs.
+* A change is made to the anime record itself
-* Use NOTIFYGET to receive a notification, suppling the ID provided by NOTIFYLIST
+* An ''main'' or ''official'' anime title is added, edited, or deleted (not ''short'' or ''synonym'')
-* Use NOTIFYACK to acknowledge a notification, suppling the ID provided by NOTIFYLIST (if desired)
+* An episode for the anime is added, or delete (but NOT edited!) ( --> But perhaps airdate changes should <-- )
+* An episode title is added, edited, or delete
+* An anime category is added, or deleted (but NOT edited: eg, weight change)
+* An anime relation is added, or deleted
+=== REVIEW: Get Anime Review ===
+Retrieves the review scores and text for an anime review.  Like ANIMEDESC, it will likely take multiple calls to this comment to retrieve a complete review - almost all reviews will overflow the size limits of a UDP packet.
-{{eyecatch|NOTE|The ID supplied by NOTIFYLIST will be the ID of the affected notification type.  Since, at present, only the anime type is supported, this value is always an aid.  In the future, it may represent a group or producer ID.  In these cases, the str '''type''' value will indicate what entity the ID represents.}}
+'''Command String:'''
+* REVIEW rid={int4 id}
+'''Possible Replies:'''
+* 234 REVIEW
+: {int4 current part}|{int4 max parts}|{int4 review id}|{int4 author uid}|{int4 score_animation}|{int4 score_sound}|{int4 score_story}|{int4 score_character}|{int4 score_value}|{int4 score_enjoyment}|{str review_text}
+* 234 REVIEW
+: {int4 current part}|{int4 max parts}|{str review_text}
-'''Method Two: Server PUSH'''
+* 334 NO SUCH REVIEW
-With this method, the server takes the active role in advising the client that a new file has arrived.  The client must register with the server to receive these advisements, and will be responsible for keeping the login session from timing out, and any NAT router ports open.
+'''Info:'''
+* IDs and scores are returned with part zero only.  Parts one through max exclude the scores and return the text block only.
-This method compensates for the disadvantages of the polling method, but is more difficult to code.  Blocking sockets are no longer an option, nor can a client make any assumptions that an incoming packet will necessarily be a reply to the last command sent.  The tag option may be helpful here.
-A PUSH HOWTO:
-* PUSH to register your client session.
-* Listen for 271-274 NOTIFICATIONs ('''not 290''').
-* Use PUSHACK to to acknowledge the notification using the nid supplied with NOTIFICATION
-* Use NOTIFYGET to receive a notification, suppling the relid provided by NOTIFICATION (NOT the packet ID)
-* Use NOTIFYACK to acknowledge a notification, suppling the relid provided by NOTIFICATION (if desired)
-* Use UPTIME (with an interval between 30 and 35 minutes) to keep login session valid
-It is probably a good idea to use tags to separate NOTIFICATIONs from the other communication. NOTIFICATIONs will '''never''' have tags.
+[Maybe exchange author uid for author name.  Or a uid->name lookup via USER?]
-=== PUSH: UDP Notification Registration ===
+=== WISHLIST: Retrieve Wishlist Data  ===
-With this command you can register your client as an observer for anidb notification events for the current user. If you are registered for one or more event types the anidb server will send an UDP packet (format see below) on each change which affects the current user. The UDP packet is sent to the ip and port from which the AUTH command was recieved.
+Retrieve wishlist data.
+'''Command String:'''<br>
+full list:
+* WISHLIST
+by aid:
+* WISHLIST aid={int4 aid}
+by wishlist id:
+* WISHLIST lid={int4 lid}
+by priority:
+* WISHLIST priority={int4 priority}
+<br>
+'''Possible Replies:'''<br>
+<br>
+by aid, lid:
+*223 WISHLIST
+: {int4 lid}|{int4 aid}|{int2 type}|{int2 priority}|{int4 fromuid}|{str comment}|{int4 adddate}
+<br>
+full list, by priority:
+*229 MULTIPLE WISHLIST ITEMS
+: {int4 aid}|{int4 type}|{int4 priority}/n
+: {int4 aid}|{int4 type}|{int4 priority}/n
+..repeated n times
+<br><br>
+*323 NO SUCH WISHLIST ITEM
+<br>
+'''Info:'''
+* ''Priority'' values are 0: low, 1: medium, 2: high
+* ''Type'' values are 1: to watch, 2: to get
+* Multiple items are returned in descending priority (high priority first)
+* The ''fromuid'' field represents the uid of the user that created the wishlist entry.  Typically this is the actual user, but could be a buddy.
+=== WISHLISTADD: Add Anime to Wishlist ===
+'''Command String:'''<br>
+* WISHLISTADD aid={int4 aid}&type={int2 type}&priority={int2 priority}[&comment={str comment}]
+* 226 WISHLIST ITEM ADDED
+: {int4 wishlist id}
+* 228 WISHLIST ITEM UPDATED
+: {int4 wishlist id}
+=== WISHLISTDEL: Remove Anime from Wishlist ===
+=== NOTIFICATION: Retrieve Notification Date ===
+=== NOTIFICATIONADD: Add Anime or Group to Notify List ===
+'''Command String:'''<br>
+by anime id:
+* NOTIFICATIONADD aid={int4 aid}&type={int2 type}&priority={int2 priority}
+by group id:
+* NOTIFICATIONADD gid={int4 gid}&type={int2 type}&priority={int2 priority}
+<br>
+'''Possible Replies:'''
+* 246 NOTIFICATION ITEM ADDED
+: {int4 notification id}
+* 248 NOTIFICATION ITEM UPDATED
+: {int4 notification id}
+* 399 NO CHANGES
+<br>
+'''Info:'''
+* ''Priority'' values are 0: low, 1: medium, 2: high
+* ''Type'' values are 0: all, 1: new, 2: group, 3: complete
+=== NOTIFICATIONDEL: Remove Anime or Group from Notify List ===
+'''Command String:'''<br>
+by anime id:
+* NOTIFICATIONDEL aid={int4 aid}
+by group id:
+* NOTIFICATIONDEL gid={int4 gid}
+<br>
+'''Possible Replies:'''
+* 247 NOTIFICATION ITEM DELETED
+: {int4 notification_table}|{int4 relid}
+* 324 NO SUCH NOTIFICATION ITEM
+<br>
+'''Info:'''
+* ''notification_table'' values are 1: anime, 2: group
+* ''relid'' value matches the aid/gid supplied
+=== Empty Table ===
+<table>
+ <tr>
+  <td colspan="3" align="center">Byte 1</td>
+ </tr>
+ <tr>
+  <td>Bit</td>
+  <td>Decimal</td>
+  <td>Data Field</td>
+ </tr>
+ <tr>
+  <td>0</td>
+  <td align="right">1</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>1</td>
+  <td align="right">2</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>2</td>
+  <td align="right">4</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>3</td>
+  <td align="right">8</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>4</td>
+  <td align="right">16</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>5</td>
+  <td align="right">32</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>6</td>
+  <td align="right">64</td>
+  <td>String</td>
+ </tr>
+ <tr>
+  <td>7</td>
+  <td align="right">128</td>
+  <td>String</td>
+ </tr>
+</table>
+=== Permissions (badges) ===
+<pre>[22 Jan 12 16:57] * Ommina: baka gives good advice.  Let's get the permission thing fully figured out.  If I'm going to stop playing minecraft, I don't want to have to redo stuff.  (and now gone for food.)
+[22 Jan 12 17:04] * worf: well ... what do we have
+[22 Jan 12 17:04] * worf: we have a set of personal settings that only affect you
+[22 Jan 12 17:05] * worf: hiding thumbnails, hiding all images, hiding porn images, hiding all porn
+[22 Jan 12 17:06] * worf: but those dont need to be considered in the xml
+[22 Jan 12 17:07] * worf: and then we have the permissions
+[22 Jan 12 17:07] * worf: see me in user list, see my anime list, see storage info, see source info, see viewed info, see ep info, see file info, see state info, see my votes, see my wishlist, see my userpage, see my porn
+[22 Jan 12 17:08] * worf: see my porn - obviously would apply to the hentai badge
+[22 Jan 12 17:09] * worf: see my anime list - should apply to all anime and creator badges
+[22 Jan 12 17:09] * DerIdiot: see my anime list/see viewed info/see ep info/see my votes are the ones that matter
+[22 Jan 12 17:11] * worf: see my votes shouldnt matter
+[22 Jan 12 17:11] * DerIdiot: wasn't sure if you have some badge with them
+[22 Jan 12 17:11] * DerIdiot: if not then yes it doesn't
+[22 Jan 12 17:11] * worf: there is a counter badge
+[22 Jan 12 17:11] * worf: but we are already displaying the number of votes on the userpage anyway
+[22 Jan 12 17:12] * worf: i dont think that permission hides the counter either
+[22 Jan 12 17:12] * DerIdiot: i'm not 100% sure, but if not then yes you cna ignore it
+[22 Jan 12 17:14] * worf: the only usage of PERM_SEEVOTES on the userpage appears to be for hiding the latest votes
+[22 Jan 12 17:17] * worf: so ...
+[22 Jan 12 17:17] * worf: PERM_SEEMYPORN for the hentai badge
+[22 Jan 12 17:18] * worf: PERM_SHOWMYLIST for all anime and creator based badges including the hentai badge
+[22 Jan 12 17:18] * worf: PERM_VIEWEDINFO same as the above i guess
+[22 Jan 12 17:20] * worf: PERM_EPINFO shouldnt apply since we arent displaying which episodes have been watched. just how many
+[22 Jan 12 17:22] * DerIdiot: PERM_EPINFO says that somethign is in mylist; PERM_VIEWEDINFO does the same + says that it's watched
+[22 Jan 12 17:25] * worf: if you have PERM_SHOWMYLIST on "everyone" and PERM_EPINFO on "no one" then you can only see which anime a person has but not which episodes
+[22 Jan 12 17:25] * DerIdiot: yes
+[22 Jan 12 17:25] * worf: hm, ok
+[22 Jan 12 17:25] * worf: it hides the counts too
+[22 Jan 12 17:26] * worf: k
+[22 Jan 12 17:26] * DerIdiot: but you only got watched badges not collecting ones right?
+[22 Jan 12 17:26] * worf: yes
+[22 Jan 12 17:26] * DerIdiot: then PERM_VIEWEDINFO is enough
+[22 Jan 12 17:26] * DerIdiot: should prolly have PERM_SHOWMYLIST and PERM_VIEWEDINFO
+[22 Jan 12 17:27] * worf: hmm
+</pre>
+=== EPISODEDESC: Retrieve Episode Description ===
+'''Command String:'''<br>
+by eid
+* EPISODEDESC eid={int eid}
+'''Possible Replies:'''
+* 241 EPISODE DESCRIPTION
+: {int4} eid|{str description}
+* 341 NO DESCRIPTION
+'''Info:'''
+* Be aware of the UDP packet size limits.  As of this writing, fewer than one percent of all episode descriptions will not fit into one packet.  That value falls further if compression is enabled.  Nonetheless, some especially enthusiastic descriptions will be truncated as necessary.