Tag Archives: ktorrent

KTorrentでCK語torrentがうまく扱えない件でも書いたまさにその件。もちろんKTorrentでもその「症状」は相変わらずで、実はTransmissionその他何種類かのクライアントでもそれは同じことが分かっていた。ちなみに同じ症状が出るトレントファイルをWindowsのμTorrentで開くとまったく問題ない。

では簡易BitTorrentクライアント機能が付いた最近のOperaではどうか。実はOperaのBT機能でもちゃんと開くことができる。しかしBT専用クライアントに比べると、Operaのソレはあまりにもシンプル過ぎるというか、細かい設定は一切できない。ポート関係についても他の利口なクライアントとは違って自分で「開ける」ポートを設定しなくてはならない。

あ、Vuzeってインストールしてあったよなと気がついた。気がついたというぐらいなので、インストはしてあってもインスト直後にちょっと試してみただけでほとんど使ったことはなかった。

VuzeはかつてAzureusという名で開発されていたBitTorrentクライアントに動画共有その他の機能を追加したものらしい。今回はそのVuzeを再度試してみた。

Vuzeの動画共有はそれなりだが、HD動画はアイコンでHD動画であることがすぐ見て分かるようになっているのはユーザに優しい。そして(自分にとっては)肝心のBitTorrent関係の機能。これもVuzeとなるまでAzereusとして知られていた間ユーザから支持されていただけあって、機能に不足はない。Javaで書かれていて動作が重いのではないかと思った自分は頭が古いらしく、動作速度の点でも普通に使える。

KTorrentやTransmissionでは出る不具合だが、しかしOperaやこのVuzeでは出ない。そしてWindowsのμTorrentでも出ない。てことは、Ubuntu/Kubuntuの文字エンコード/デコード関係のライブラリに問題あり、なんだろうか。あるいは問題というよりは、「エンコードがおかしい(トレント)ファイルは怪しいからオープンしないよ」という親切設計なのか。(爆)

で、一番重要なポイントは、KTorrent、Transmissionその他では「エンコードがおかしいぞ」的エラーを吐いてうまく開くことができなかったトレントファイルをなんなくVuzeは開いてしまうこと。トレントファイル中でCK語で記述されたファイル名などの表示はできない(フォントがないから?)が、それでもトレントファイルを開いてダウンロードすることはVuzeではできてしまう。

ということで、自分はメインのクライアントとして使うことはなさそうだが、それでも必要に応じてVuzeは今後使いそうな感じ。コンソールのbashプロンプトから起動する場合(つまり自分の場合)、エラーメッセージその他起動時も起動中も色々出てきてうるさいので、起動時はこうする:

vuze &> /dev/null

デフォルトではログにも記録もされているので、標準出力や標準エラー出力はでぶぬるに送ってしまう。Kメニューにも追加しておくことにする。

年末の部屋の掃除もさることながら、PCの中(=ハードディスクの中)もお掃除。

特に要らないファイルは消すか外部のメディアにバックアップ。KTorrentをはじめソースからのビルドを試みてその後それを使うなり使わないでいるなりどちらでもほぼすべてを消す。

そしてナニゲに思い出した「なんでrelated post linkがこのブログでは現れないのだろう?」ということをチェックするためにWordPressのヘルプを改めて参照。利用しているテーマが問題なのかなあとずっと思っていたのだけれど、ヘルプをみると「英語ブログだけで利用できるかも」とある。へ?

英語以外の言語で書いている記事が多いブログでも、英単語が使われているものはたくさんあるだろうに。

では、とまずブログ設定で主に書く言語を日本語から英語に変更してみた。ひょっとしたらこれ一発で利用できるようになるのかも。んー、わからん。

KTorrent

KTorrentを動かしていることが多い自分。それも非力なCPUと高々2GB弱(ビデオに若干取られている)のメモリで10本+アルファのタスクをKTorrentにさせていると、けっこうなCPUロードとメモリ使用量になる。

特に自分の場合、USB外部接続のHDDに保存するようにしており、しかもそれら(複数)のUSB外部接続HDDはどちらもNTFSフォーマットされている。NTFSフォーマットであるのはもちろんWindowsとの共用を考慮してのことなのだが、USB経由でも辛いのにそれに加えてntfs-3g経由という二重苦なのである。重い。

KTorrentではトレントのサイズをはじめに確保しておくオプションがあり、遅いマシンではこれをしておかないとタスク終了時まで長いこと(いや長いとは限らないけれど)ディスク書き込みオーバーヘッドが余計にかかってしまう。だから最初に確保するようにして利用しているのだが、5、6本以上のトレントを一度に放り込む(開始)するとほとんど他のことは何もできないぐらい重くなってしまう。(泣)

まあ、これはこの非力なマシンかつUSB外部接続HDDに保存などということをしている以上仕方がない。

が、KTorrentのタスクが走っている最中にもロードが高くなったままになることもあって、これはさすがに困る。トレントなんぞはあくまでも「ながら」作業でなくてはいけない。

ということで、少しでもそうした負荷を軽減できるようKTorrent側でまずチューニングを試みる。

KTorrentの「設定」メニューから「ダウンロード」タブを開く。関係する設定箇所はいくつかあるが、ここでは特に「torrentあたりの最大接続数」、「全体の接続制限」に注目する。「最大アップロード/ダウンロード速度」の2項目も関係があるが、今回はデフォルトの0(ゼロ=無制限)のままにしておく。

自分が何度も設定を変えてしまったのでデフォルトの値はもう忘れてしまったのだが、「最大接続数」と「全体の接続制限」を現在の値から少なくしてみる。1や2変えただけではほとんど意味がないので10単位で変えてみる。なぜならここの値は自ホストに許す接続数なので、これが多ければ多いほどCPUの仕事も多くなるからだ。

KTorrentを使用中、プラグインで「情報ウィジェット」をロードし「ピア」をモニタするタブを選択、もちろんトレントやタイミングによっても違うが、普段自分が落とすトレントなどでは大体どのぐらいの相手からダウンしているかがこれで分る。もし自ホストにダウンする他ホスト数が例えば10以下だったとしたら、「torrentあたりの最大接続数」はその10以下でよいだろう。

そして一度にいくつのタスク(=トレント)をダウンするのか自分でも分るはずなので、その本数分を(例えば)10倍した値を「全体の接続制限」にセットすればよい。

自分はFTTH回線利用者なのだが、そもそも自分のような低速CPU搭載機で利用する場合、同時接続数とは別にあまりに高速の転送(ダウンにしてもアップにしても)はそれももちろんCPUに多大な負荷を掛ける。これが嫌な場合は上記の「最大アップロード/ダウンロード速度」も制限するべきだろう。

あとは常時接続ならスケジューラを大いに活用し、「就寝時から朝まで」など、自分が使わない間に動かすよう設定するのも便利だ。

いやしかし、こんなに苦労しているのは自分だけなのかもしれないな。

KTorrent

KTorrentのKDE3用としては「最後の」バージョンがリリースされた。

KTorrent 2.2.8 has been released

Read More »

KTorrent

HDD上のファイルを整理中、まだKTorrentで終了していないtorrent(とそのデータ)を間違って削除してしまい、あたふたしたもののどーしよーもなく。(爆)

50%もいっていないtorrentでそこに至るまで数日掛かっていた代物だったのに……… 仕方なく一からやり直し。

自分のKDEではデスクトップは4つ。Konsoleは1番目のデスクトップで常に開いていて、シェルはそこで2つ。そのうちひとつはtopを常に動かしている。(GUI版は使わない) 2番目には通常ThunderbirdとOpera(かFirefox)、3番目はAmarok、KTorrent、その他、そして4番目のデスクトップにはKopete、Pidgin、SkypeなどIM関係、なのだが、Yakuakeを常用する自分はCLI系で何かするときはそのF12キーでYakuakeをどのデスクトップにいてもsummonして使う。これはひじょーに便利なのだが、どこでもさっとシェルにアクセスできるのはある意味危険であった。そう、今回誤って消してしまったのも、Yakuakeのシェル上でやってしまった。

とか言い訳にもならないので、今後気をつけることにしよう。(しかし実はこの間違い、今回が初めてではなかったりもする)

えーと、つまりはアレゲなトレントでの話。ご存知のようにって、知らない人や関係ねーな人のほうが多いだろうが、アレゲなトレントではCK、つまり大陸や半島の方々が作成したトレントが多い。モノ自体のファイル名がC語でもK語(H語?)でも別にいいのだが、トレントファイルの中身がそれらCK語であるとき、場合によってはKTorrentが「エンコードおかしいんちゃいますか、このトレント。面倒みきれませんわあ」てなエラーを吐いて、つまりはまったく受け付けないことが。

これってどちらが悪いのか。つまり、トレントファイルがやはりおかしいのか、あるいはこれはあくまでもKTorrent側の文字ハンドリング能力が足りないのか。

確かに別なBTクライアントもインストールしてあるのだが、使い慣れたKTorrent以外を使うのはちと面倒だし不安。こんなとき、ああμTorrentがあればなあと思うのだが、ないものねだりしてもしょーがない。え、WINEで動かせてか? いやいや。(笑) ほえ? VirtualBoxとかVMwareで動かせ? うーん。ちょっとディスクが足りましぇん。

で、仕方なく(仕方なくデス、ほんとーに)こうしたKTorrentで扱ってくれないトレントはOpera内蔵のBTクライアント機能に頼ってしまうのだが、このOpera内蔵BTクライアントが「とりあえず機能、つけました」的なものでイライラする代物。もーいやっ。

ちなみに今使っているKTorrentのバージョンは2.2.7のKDE3用。なんでって、KDE4もインストールしてあるが、見た目は確かに綺麗でカックいいKDE4でもなんかまだちょっと(動作が)変なところがある気がして結局KDE3に戻ってしまっているのであった。KDE4対応のKTorrentはバージョン3が出ていて、そちらだともしかするとこうした文字エンコード関係の問題は解消されているのかもしれない。

新しもの好きな自分なので、なんにでも一度は手を出してみるものの、やっぱりPCは使えてナンボですよ、うん。てことで、もうしばらくはまだKDE3にお世話になるし、KTorrentも2.2.7を使い続ける予定。

追記:

いや、ブラウザとしてのOperaは大好きです。現にFirefoxじゃなくOperaを毎日起動する私、であります。