このページでは、wikiなどで使用している用語の解説を行います。出来るだけ表現の統一を図っていきますが、異なる表現が混用されていた場合はIssueなどからご報告下さい。

• アイテムとして複数の動画を保持できる容れ物のようなものです。
• プレイリストと動画の関係は、フォルダーとファイルの関係のようなものです。
• プレイリストはまた別のプレイリスト(「子プレイリスト」とする)を子として複数持つことが出来ます。この場合、「子プレイリスト」をもつプレイリストを「親プレイリスト」と言います。
• 親プレイリストが存在しないプレイリスト、すなわち祖先・始祖のような立ち位置のプレイリストを「ルートプレイリスト」と言います。
• 内部的には、データベース上の1つの動画データが複数のプレイリストで共有され、あるプレイリストで行われた動画に対する変更が全てのプレイリストに反映されます。
• 例えば、sm9が「プレイリストA」と「プレイリストB」に登録されていたとき、「プレイリストA」で再取得を行うと、再生回数の増加などが「プレイリストB」のsm9にも反映されます。

• 動画を選択中のプレイリストのアイテムとして追加する処理を指します。
• 内部的には、動画データはデータベースに保存され、さらにプレイリストが保持しているアイテム(動画)のリストも更新します。

• プレイリストツリーで末端にあるプレイリストをクリックした際にプレイリストタイトルが変更された場合、クリックしたプレイリストは選択されたと言い、そのプレイリストを「選択しているプレイリスト」と言います。
• ルートプレイリストおよび親プレイリストは選択不可能です。

• 動画のうち、サムネイルのの左部分にあるチェックボックスにチェックが入っているものを「選択した動画」と言います。

• プレイリストのうち、マイリスト・あとで見る( 旧:とりあえずマイリスト )・ユーザー投稿動画・チャンネル投稿動画のいずれかと結びつけられているものを言います。
• もともとは作者がgit remoteのような差分のみ同期できる機能が欲しいと思って実装したためこの呼称になりました。
• 設定はリモートプレイリストウィンドウから行うことができます。

• 実行ディレクトリ直下のlogディレクトリに生成されるエラー情報などが出力されたプレーンテキストです。
• ファイル名は「niconicome-log-<年>-<月>-<日>-<時>-<分>-<秒>.log」の形式となっております。

• v0.3.0から、ダウンロードは「タスク」という単位で管理され、「ダウンロードキュー」と「ステージングキュー」という2つの概念に従って動作するようになりました。
• 「タスク」は解像度や保存パスのようなダウンロード設定と動画情報からなる処理単位です。
• 「ダウンロードキュー」はダウンロードの準備ができたタスクが登録されます。一旦ダウンロードが始まると、プログラムはダウンロードキューにタスクが存在する限りダウンロードを続けます。
• 「ステージング」はタスクを「ステージングキュー」に追加することであり、ステージングキューに追加されたタスクはダウンロードキューに登録されるまではDLされません。
• ダウンロードキューに登録されたタスクは、スレッド安全性の観点から解像度などの設定を変更することはできません。
• メインウィンドウで「ダウンロード」ボタンを押すと、ひとまず選択された動画すべてをステージングします。その後、ダウンロード設定の「メインページのダウンロードボタンでキューのタスクすべてをダウンロードする」が有効になっている場合にはステージングキューのタスクすべてを、それ以外の場合には現在選択されているプレイリストの動画から作成されたタスクをダウンロードキューに登録します。
• この後、ダウンロードが開始されます。
• 流れ的には、「動画情報・ダウンロード設定からタスクを作成」=>「ステージングキューに登録」=>（この後、管理画面で個別に解像度等を設定）=>ダウンロードキューに登録=>DL開始です。

• ID・URL・検索キーワード入力窓に入力された文字列を解釈する機能です。 たとえば視聴ページ・チャンネル・マイリスのURL、動画IDなどはその種別を判別し、適切な形で登録します。
• また、ローカルディレクトリのパスを入力された場合もそのディレクトリから動画を取得して登録します。
• 上記のどれでもない場合は検索キーワードとしてニコニコで検索して登録します。

• Windows10でのみ利用可能なAPI、特にWinRTのAPIを利用する機能です。
• v0.7.0で追加予定のクリップボード監視機能など。

• 本ソフトウェアではコメントをダウンロードする際に100コメント程度からなる「ブロック」とその集合体であるコレクションとして管理しています。
• 取得できなかったコメントを取得する際にはこの「ブロック」単位でコメントを取得します。
• このような理由で、コメントコレクションで1ブロックあたりのコメント数を減らすとリクエスト回数は増加するものの、より多くのコメント取得が期待できます。
• しかし、あまりに1ブロックのコメント数を減らしすぎるとコメント取得に時間がかかってしまうため、1ブロックあたり100コメント程度を推奨します。