Archive for the ‘Linux’ Category

先日、Thunderbirdでメールアカウントを一時的に無効化する(例: 新規メールを受信しない)方法が分かった。以前検索しても見つからなかったので書く。ただ、Thunderbirdの内部設定を変更するので危険が伴うのと、自分でも充分に確認した訳ではないので、試す方は設定などのバックアップをしたり事前に調査・確認するなど、充分な準備をされたい。以下を読んで内容が理解できない方は、絶対に実行しないで下さい。トラブルの相談をされるのは困ります。

Thunderbirdで、メールアカウントの設定や既存のメールを残したまま無効化(一時停止)して、新規メールを受信しないようにする手軽な方法はない。設定で新しいメールを受信しないようにしても、思わぬ時に受信してしまう。検索して出てくるのは、そのアカウントを削除することである。削除したら設定や既存のメールがなくなってしまうので、とても不便だ。しかし、設定エディタを眺めているうちに、アカウントの種類を「ローカルフォルダ」に変更すれば無効化できることに気付いた。ローカルフォルダは1個しか作れない訳ではないようで、筆者の環境(Thunderbird 52.9.1 (64-bit), OS: Linux)では、以下のように2つできている。

Thunderbirdのローカルフォルダを2つにした。

メールアカウントの種類を「ローカルフォルダ」に変更する手順を書く前に、関連する主な設定を以下に示す。なお、以下で、NMはサーバやアカウントの番号を示す数字(例: 1)である。設定の意味や値は筆者の推測であり、ThunderbirdのバージョンやOSによって名前や意味や値が変わる可能性がある。

  • mail.server.serverN.type: アカウント(サーバ)のタイプ
    • "none": ローカルフォルダ
    • "imap": IMAP
    • "pop3: POP
  • mail.server.serverN.userName: サーバのユーザー名
    • ローカルフォルダの場合、"nobody"
  • mail.server.serverN.hostname: サーバのホスト名
    • ローカルフォルダの場合、"Local Folders"
  • mail.server.serverN.name: アカウント(サーバ)の名前(Thunderbirdの左側のアカウント・フォルダ一覧に表示される)
    • ローカルフォルダの場合、"ローカルフォルダ"
  • mail.server.serverN.directory, mail.server.serverN.directory-rel: そのサーバのメール格納ディレクトリ。前者は絶対パス、後者は(何かからの)相対パス。なぜ2つあるかは不明。
  • mail.server.serverN.check_new_mail: そのサーバから新しいメールを受信するか
    • "true": 受信する
    • "false": 受信しない
  • mail.server.serverN.storeContractID: そのサーバのメールの格納方法 (mbox または maildir)
    • "@mozilla.org/msgstore/berkeleystore;1": 全メールを1ファイルに格納 (mbox: 通常)
    • "@mozilla.org/msgstore/maildirstore;1": 各メールごとに別ファイルに格納 (maildir)
  • mail.account.accountM.server: アカウントMのサーバ名(上記の"serverN"に相当する)の指定 (例: "server7")
  • mail.accountmanager.accounts: 有効なアカウントリスト
    • 有効なアカウント名(上記"accountM"に相当)を","区切りで列挙する。

既存のIMAPなどのアカウント(実際にはサーバ)のタイプをローカルフォルダに変更して(一時的に)送受信しないようにする手順を以下に示す。例にはサーバserver7を「ローカルフォルダ2」に変更する場合を書いた。

  1. 設定エディタを起動する。
  2. 変更したいアカウントのサーバを調べる。 → 例として"server7"とする。
    • "mail.server."を設定エディタの検索フィールドに入れ、列挙される設定中のホスト名(例: "mail.server.server7.hostname")などで判別する。
  3. そのサーバの種類を「ローカルフォルダ」に変更する。なお、そのサーバでの送受信を復活させる時に再設定することになるので、変更する前の値を記録しておくこと。
    • mail.server.server7.type: "none"にする。
    • mail.server.server7.userName: "nobody"にする。(おそらく設定不要)
    • mail.server.server7.hostname: "Local Folders2"にする。(おそらく設定不要)
    • mail.server.server7.name: "ローカルフォルダ2"にする。(おそらく設定不要)
    • mail.server.serverN.check_new_mail: "false"にする。(おそらく設定不要)
  4. 設定エディタと設定を閉じ、Thunderbirdを再起動する。

再起動後は、元々IMAPなどだったメールアカウントが2個目のローカルフォルダになっているはずである。もちろん、メール送受信は行われない。

なお、ローカルフォルダのディレクトリを既存のものと変えるには、新しいローカルフォルダ用のディレクトリを作成し、mail.server.serverN.directoryとmail.server.serverN.directory-relに指定すれば良い。

また、アカウントの種類(例: IMAP → POP)の変更も、今回と同様な手順でできそうだ(ただし、種類変更に伴う追加の設定が要る。筆者は試していないので、各自挑戦されたい)。

設定変更に失敗するとアカウントが見えなくなってしまうことがあるが、その場合は以下を行うと復活できる可能性がある。

  1. 設定エディタを起動する。
  2. mail.account.accountM.serverで、見えなくなったサーバのアカウントを調べる。 → 例として"account9"とする。
    • server7が見えなくなった場合、mail.account.accountM.serverの値が"server7"のものを探す。
      • "mail.account.account"を設定エディタの検索フィールドに入れ、列挙される設定のうち、mail.account.accountM.serverの値が"server7"のものを探す。
  3. mail.accountmanager.accountsに上記アカウントが含まれていないはずなので、追加する。
    • mail.accountmanager.accountsの最後に",account9"を追加する。
  4. 設定エディタと設定を閉じ、Thunderbirdを再起動する。

再起動後は、見えなくなったアカウントが見えるようになっているはずである。

上記とは直接関係ないが、メールの格納方法(例: mbox → maildir)の変更は容易ではない(筆者はそもそもそれがやりたかった)。設定エディタで格納方法(mail.server.serverN.storeContractID)を変更することは可能だが、それまでに格納されたメールの保存形式はそのままなので、見えなくなってしまう。エクスポート・インポートのアドオンを使うなどして、自分で保存形式を変換するしかない。なお、筆者の使ったアドオンImportExportToolsではうまくできなかった(階層化フォルダを一括エクスポートする場合、各メッセージを個別ファイル(eml)にすることができない)ので、過去の受信メールを変換するのは諦めた。

また、現在のThunderbirdの不具合・制限なのか、maildirの場合には検索フォルダがうまく動かない(Thunderbirdを再起動すると表示されなくなってしまう)ようなので、注意する必要がある。筆者は、そもそもローカルフォルダをmboxからmaildirに変更したかったのだが、この問題があったので、ローカルフォルダを2つにして片方をmboxにし、検索フォルダをそちらに入れている。また、上記のように過去の受信メールの変換も諦めたので、それも入れている。

そもそも、なぜ、ローカルフォルダをmboxからmaildirに変更しようとしたかを書くと、筆者は読んだメールをサーバからローカルフォルダに移動している。しかし、この状態で長く使っていると、受信メールのファイル(mbox)が肥大化するので、いろいろと都合が悪い(例: mboxが大きいと処理が重くなる。1メールの受信(移動)ごとにmboxが更新されるので、バックアップ対象のデータ量が無駄に大きくなってしまう)。そもそも、サイズが無限に大きくなるファイルを作ること自体が非常識だ(センスが悪い)。そこで、近頃追加された(前からあったのかは不明)maildirにして、各メールを個別のファイルにすることで問題を解消しようとした。

このように、Thunderbirdにはいろいろな不満があるのだが、現状では他にいいものがないので、試行錯誤しながら使っている。

(9/22 15:04 ローカルフォルダのディレクトリについて修正)

 

PS. こういう情報を書く時にいつも思うのは、本来書くべきサイト(例: ユーザーフォーラム)に書いた方がいいだろうということだが、どうしてか、MusicBeeのフォーラム以外ではまともに反応があったことがないので(MusicBeeの翻訳をやっていたのは、そういう「張り合い」があったことも大きい)、書くだけ無駄だと思い、ここに日本語で書いている。僕の英語が良くないと思われるかも知れないが、それだけでもなくて、なんとなく、海外のサイトには排他的な雰囲気があるように思う。こっちは日本に閉じこもるつもりは毛頭ないのだが、海外には意外に許容力が低い人が多いようだから仕方ない。まあ、それで彼ら自身が損しているのだから、別にいいけど。

それから、公式サイトは、大抵の意見や不具合報告に対して「ありがとう。検討します」などで終わってがっかりするので、全く書く気がしない。

まあ、近々、Google辺りが自動翻訳を強化して、日本語で書いたって、英語(でも他の言語でも)で普通に検索できるようにしてくれそうだから、もう英語で書く必要はないのではないかとも思っている。そういう時に重要なって来るのは、(国際的に通じやすくなるように、)論理を明確に書くということだろうか。

そして、「英語が国際語」というのは、そろそろ過去の話になるのではないだろうか。どうですか、R社のミッキーさんw

PS2. 実は、メールの保存形式の変更(mbox → maildir)に失敗していて、ある日以前の受信メールがなくなっていたことに、さっき気付いたw 変換前のファイル(mbox)が残ってなくて慌てたが、バックアップがあったので無事回復できた。ここで気付いたのだが、保存形式の異なるフォルダ間でドラッグ・ドロップでメールの移動ができたので、上記のエクスポート・インポート処理は不要なのかも知れない。 (9/21 19:38)

  •   0
  •   0

Duplicacy(ソフト)+Backblaze B2(ストレージ)でのオンラインバックアップを始めてから、約1か月経った。全般的には期待どおりに問題なく動いており、処理も通信も高速で気持ちがいい。まあ、動作に関しては、自分で作った部分(定期的なバックアップ・prune(不要な履歴の削除)処理やバックアップ条件など)があるので、期待・希望どおりにするまでには結構時間や手間が掛かった。

ちなみに、処理時間を書くと、通常の差分バックアップは、大量のデータを追加しない限り、5分以内で終わる(現在の圧縮後の全データ量: 約420GB、毎回の差分データ量: 約200MB)。また、prune処理は、大量のデータを更新していない限り、20分程度で終わる。

それに引き換え、CrashPlanは全然良くなかった。例えば、CPU負荷が高いと思って調べたら、CrashPlanのバックアッププロセスが延々と(数時間)動いていることが多かった。更新ファイルのスキャンが遅いのか、転送速度が遅くて延々と送信しているのだろう。プログラムがJAVAで書かれているから重いのかも知れない。しかも、GUIがあるのに、その時に何をしているか、何のファイルをバックアップしているかが全く分からず、バックアップしているかどうかしか分からない(ある時から改悪されてしまった)。そんなんだったら、GUIの意味がない。

それで、馬鹿馬鹿しいからCrashPlanを使うのを止めてアンインストールした。そうしたら、(以前からなのだが、)「バックアップがしばらく行われていない」という警告と「バックアップの状態は問題ない」というのが互い違いに(別の仕組みで送っているのだろう)来るようになったので、呆れた。更に頭に来るのは、通知を解除したのに、他にも隠れた設定があるようで、ずっと「問題ない」メールが来続けていることだ。鬱陶しいので、今月半ばの期限前に退会しようと思ったのだが、その方法さえ不明だった(ボタンなどなし)。CrashPlan(Code42)のwebには大手企業のロゴが多く出ていたが、こんないい加減なサービスを本当に使っているのかと思う。

(9/16 10:26追記) CrashPlanからの退会は、なんと、サポートに連絡しないとできないようだ。自動支払いの停止や会員資格の無効化(こういう状態がある意味は不明)はwebで可能だが、退会はできない(退会しないとクレジットカード情報が消せないので、どうしても退会したい)。しかも、サポートは夜間や週末は休みというありさまだった。更に、昨日サポートに連絡して回答がなかったが今朝はログインできなくなっていたので、回答せずに削除したようだ。本当にいい加減で信用できない会社で、入ったのは全く失敗だった。

(9/17 21:13追記) 上記の件、サポート担当は何もしておらず、期限切れで自動的にアカウントが削除されたようだ。というのは、今頃一次回答(「問い合わせが多いので、順次処理しています」みたいなもの)が来たので。まったく冷笑するしかない。 ← (9/18 5:28追記) ログインの手違いだったようで、アカウントはまだ残っていた。本物の回答が来ていたので、再度削除依頼を出した。

カスの話はこれくらいにしてDuplicacyに戻ると、普通のデータ圧縮はもちろん、重複排除がかなり効いている感じだ。例えば、VirtualBoxのWindows 7の馬鹿でかい仮想ディスク(サイズ: 約44GB)が更新されても、バックアップデータの増分は4GB程度で済む。CrashPlanだと延々とバックアップが続くパターンだったと思う。ただ、Duplicacyでも、その4GBのprune処理にかなり時間が掛かってしまう(30分以上)ので、今は、仮想ディスクをコピーして2個(1個は保存用)にし、使う方はバックアップの対象外にしている。とにかく、Windowsはリソースを無駄に消費するから大嫌いだ(スキャンにしか使ってないのに、44GBだって足りなくなって来ている)。一日も早く、完全に脱却したい。

バックアップの頻度や変更履歴の保存数をどうするか迷っていろいろ試していたが、結局、バックアップは8時間ごと(概ね1日3回)にし、履歴は過去1か月分だけ毎週の分を残すことにした(その後は最後のものだけ残す)。なお、prune処理を溜めると処理時間が長くなるようなので、毎日実行している。

今、Backblazeのページを見て気付いたのだが、変更履歴を保存しておくと、ランサムウェア(要は「ウイルス」)対策になるようだ。感染前の履歴(状態)が残っていれば、感染に気付いた時に、そこに戻せるのだ。そういう意味では、1か月もあれば感染に気付きそうだから、現状で良さそうだ。が、保存数や間隔を調整する余地はあるかも知れない。もちろん、ウイルスがB2のストレージを初期化するようなものだったら、「おじゃん」だがw

料金については、先日支払った最初の1か月分が約US$2だったので、年額にすれば2600円程度となる。実際にはもう少し増えて3200円程度になるだろうが、それでも期待どおり安い。CrashPlanの個人用は6千円を超えていたから、約1/2になりそうだ。なお、料金は、保存データ量以外にダウンロードデータ量と特定APIの実行回数でも加算されるのだが、通常時はどれもほとんど無料か数セント程度なので、問題なさそうだ。

ただ、気になっているのは、保存データ量が増え続けることだ。最初は350GB程度だったのが、(その後、貴重な音楽ファイルなどを追加したこともあり、)今は約420GBになっている。ログを見ると、バックアップごとに200MBくらい増えているが、prune処理で200-400MB程度減るから発散はしなさそうだ。が、日々、メールや写真などのデータは増える一方なので、いくらストレージの料金が安いとはいえ、「最後」はどうなるのか心配だ。

実際には、メールや写真だけなら、とんでもない料金になるほど急増することはないので(実際、写真は16GBのSDカードを3年も使っているが、まだ3500枚も撮れるようだ)、当面は問題ないだろうが、その他のデータが増えるかも知れないので、しばらく様子を見ることにする。そのうち、(テープを使用するなどして、速度は遅いけど)もっと安いところや無制限のところが出てくるかも知れないし。Backblazeがそういうサービスを出してくれるとありがたいのだが・・・

(9/10 11:27追記) 昨日のprune処理でデータ量が一気に41GBも減って、約378GBになった。開始から約1か月経過したので、変更履歴が大幅に整理されたのだろう(おそらく、その大半はVirtualBoxの仮想ディスクではないか)。そのため、prune処理が随分長かったが、これで、当面はデータ量に心配する必要はなさそうだw

あと、安いストレージ業者がいくつか見つかった。C14とOVHだ。ただ、どちらにも難点・不明点があり、即座に乗り換えられる訳ではない。前者は操作性や課金方法に癖があって、本当に安くなるかは分からず、後者(Cloud Archive Storage)は課金方法に癖があるのと、うたい文句はすばらしいのだが、関連会社のサービス(hubiC)が悪評高く、しかも、先日からその新規加入を中止しているので、会社としての信頼性には疑問がある。その点でも、prune処理でデータ量が大幅に減ったのはありがたい。

 

(タネが大分減った)

  •   0
  •   0

結構前に、それまで使っていた地銀がセコいことをした(特定のコンビニのATMは無料で使えていたのが、突然、手数料を取るようになった)ので、別の用途に使っていたネット銀行に完全移行しようとしたのだが、そこはコンビニのATMが一定回数まで無料で使えるから便利なものの、公共料金引き落としに弱いことが分かって、泣く泣くその地銀も使っている。

一方、先日退職したので、支出が想定どおりか定期的に確認する必要があり、今朝、そのために、毎月の残高を記録するスプレッドシートを作っていたら、ふと、「これは自動化できないか? (何かのwebやアプリで『スパっ』と表示できないか)」と思いついた。「そういえば、そういうサービスがあった気がするなぁ」と思って調べたら、「アカウントアグリゲーション」というサービスのようで、いくつか見つかった。調べてみると、僕が使っている銀行やクレジットカードなどに対応しているものがいくつかあったので、さっそく試してみたのだが、寂しい結果になった。

最大のガンは、またしても例の地銀だった。各サービスのページには対応しているように書いてあるのだが、どこで試してもエラーで接続できなかった。なお、MoneyForwardはキャッシュカードの暗証番号まで登録するようになっていて、さすがに非常識で恐ろしいので止めた(他のサービスは、ログインに必要な情報だけで暗証番号は入れない)。それから、MoneyLookはサーバにログイン情報を格納しないので、セキュリティの面で一番いいと思うのだが、そのための管理アプリがWindows用なので、全く使えなかった。アプリがLinuxで使えないのは仕方ないが、折角ブラウザを使っているのだから、自由なパスワード管理ソフトが使えれば更に便利になると思うのに、残念だ。結局、試しに入ったサービス全部から退会した。

余談だが、こういうところでOAuthが活用されるのだろうと思った。試していないが、僕が使っているネット銀行なら、OAuthでスマートに(ログイン情報すら登録せずに、「承認」ボタンを押すだけで)接続できたのかも知れない。

その地銀について補足すると、通常のネットバンキングはIDとパスワードでログインするが、そこでは、ログインのたびに、IDとパスワードに加えて乱数表に書かれた数字を何個か入れる必要がある。一種の2要素認証なので、セキュリティの点では万全で何も間違っていないのだが、いかんせん面倒だ。しかも、紙を見てワンタイムパスワードを入れるなんて、全く時代遅れだ。老眼なので、小さい数字を読むのは結構辛いものがあるのだw アカウントアグリゲーションサービスを検討したのも、この手間やイライラが省けないかと思ったからだが、やっぱり乱数表の数字を入力させられたあげくにエラーだった。サービス会社と銀行がうまい連携をしているのかと期待したが、そういうものはないようだ・・・

余談: ということは、各サービス会社は、全部に対してではないだろうが、各ネットバンキングのAPI(実際には、まず公開されていない)を使っている訳ではなく、一種のリバースエンジニアリングで、ブラウザの振りをしてページを取得して文字を読んで(用語があったが思い出せない → 「スクレイピング」だ)、ログインして残高を読んでいるのだろうか? もしそうだったら、素人的なやり方(僕だって作れそうだ)で、本当にそれでいいのかと思う。あと、MoneyForwardは暗証番号を入れたってログインできないはずだが、そこだけは違うやり方なのだろうか?

また、例の地銀でどのサービスで試してもエラーだったのは、近頃(接続用のプログラムの作成後に)ネットバンキングのページの仕様に何か変更があったために、うまく行かなくなったのかも知れない。

更に余談: こういうのも、AI(機械学習)が発展すれば、苦労してスクレイピングのプログラムを作らなくても、何度か学習させれば自動でログインできるようになるのかも知れない。ちょっと期待したいw

その地銀に更に嫌気が差して、全く別の銀行を検討した。が、ここら辺の公共料金(国保や水道・ガスなど)が引き落とせるところはかなり限られ、可能性があるのは、もう一つの(この辺りの)有力地銀かゆうちょ銀行程度になる。そのもう一つの地銀は、以前母を騙して保険を売りつけたので、検討するまでもなく却下し、ゆうちょ銀行を検討した。

そうしたら、学生の頃、親から仕送りしてもらうのに使っていた郵貯の口座を思い出した。それを復活させれば使えるかと思ったが、カードはあったものの通帳も印鑑もないし、登録してある住所もどこか不明なので、かなりハードルが高そうだった(新規開設の方がずっと楽そうだった)。が、サイトを見ていたら、ネットバンキングの申し込みはできそうな感じだったので、試してみた。が、エラーになって駄目だった。おそらく、長期間使ってなかったので口座が凍結されているのだろう。

良く考えると、郵便局より例の地銀のATMの方が家の近くにあるから(しかも、退職した今は、そのATMが追加手数料なしで使える時間に行ける)、感情に任せてゆうちょに移ってもメリットがないことに気付き、結局、「現状維持」にした。まあ、これも前回書いた、「こだわり過ぎは良くない」のひとつなのだろう。ただ、もし、その地銀が口座維持手数料を取るようになったら、移動を考える必要がある。

そして、またしてもローテクな作業(毎月、スプレッドシートに預金残高を手入力)を実施することになったw こういう具合に、いくらITが進歩しても事務の人の手作業は減らず、効率化もできないのだろうかと、今想像した。

  •   0
  •   0

先日の富騒動の時に、ついでも明朝体フォントも替えようと思い、あまり乗り気ではなかったのだが、源ノ明朝にしてみた。いろいろ試したが、許せるものが他になかったのだ。なお、以前はIPA P明朝だった。すると、そもそも明朝体を使うサイトはほとんどないのだが、使っているサイトではすごく綺麗になって、まさに見違えたので、びっくりしている。以下に、(最初に綺麗さに気付いた)なおきさんのブログからキャプチャさせて頂いて例を示す。

IPA明朝を作った方には申し訳ないが、やる気のなさが伝わって来る。この、ぼてっとした締りない形は、何か元のフォントを変換しただけの気がする※(調べるとそうでもないようだが)。一方、源ノ明朝の(特に漢字の)形には言うことがない。キリッとしていて、見ていて気持ちいい。印刷なら、活版とオフセットの違いみたいなもの? ビールで言ったら、ギネスとスーパードライの違いのようなものか。ちなみに、僕は、オフセットは好きだがスーパードライは嫌いだw

※昔話になるが、大昔はX Window SystemやUNIXで使える日本語フォントのバリエーションがほとんどなくて、元になるフォントを変換して無理に作っていた。しかも、その頃はTrueTypeなんてないからビットマップフォントで、変換のせいで線が波打っていたりして、とても汚かった。IPA明朝を見るとそういうのを思い出すのだ。

では、なぜ乗り気でなかったのかというと、源ノ明朝の先に出た、源ノ角ゴシック(今使っている源真ゴシックの元)は、句読点などがプロポーショナルでないのと、僕のブログで使った時に行間(正確には、文字の上下の隙間)が若干広過ぎたためだ。それで、おそらく源ノ明朝もそうだろうと思い、(源真ゴシックの姉妹品となるであろう、)「源真明朝」が出るのを待って試さずに居た。

源ノ明朝が出てから1年以上待ったが、残念ながら、源真明朝は出なさそうだ。サイトを見ると、数年間更新がないので・・・ それに、今気付いたが、そもそも作者はゴシック体だけしか作っていない。でも、いつか出して下さるのを期待している。

実際、源ノ明朝の句読点もプロポーショナルでなかった(CSSの設定が関係するせいか、行間は大丈夫だった)が、それを補って余りある綺麗さだ。

 

PS. 掲示板のLinuxを勧める投稿への反論コメントで、「Linuxは文字が汚いから駄目。(Macは綺麗)」という書き込みを何度か見たが、僕はこれで充分綺麗だと思っているけど、それ以上なのだろうかといつも思う。実際、僕もMacを使ったことはあるが、ものすごく美しいとは思わなかった。ジジイが大昔の話をしているのか、プロレベルの出版などの話なのだろうか? 一般的な場面で(そういう条件を明示せずに)それを言うのもおかしいと思うが。

いずれにしても、そもそも今のOSはフォントを自由に入れられるのだから、「文字が汚い」という批判は的外れだと思う(綺麗さに違いがあるとすれば、文字の描画処理やディスプレイドライバの違いだろう)。本当に違いがあるとしたって、自分で確かめずにそれを真に受ける人も多いようなのは、残念だ。

  •   0
  •   0

ようやく、オンラインバックアップの構成が落ち着いた感じだ。自分でも予想していなかったのだが(でも、いつものことだw)、いろいろな問題が起こって二転三転して、想定外の結論になった。予想外に時間が掛かったし、今後も何かあるかも知れないので、早目に着手して良かった。それにしても、いつものことながら、予想外に疲れた。

結局、僕にはDuplicacyというオンラインストレージ対応のバックアップソフトとBackblazeのオンラインストレージB2 Cloud Storageを組み合わせるのが費用対効果で最適となった。バックアップするデータ量を減らして350GB程度(ストレージでのデータ量)にしたので※、少し余裕を見ても、月額US$2(年間2600円)程度になる見込みだ。(去年終了した)CrashPlanの個人プランは(いくらだったか忘れたが、調べたら)月額US$5だったので、従来の半分以下に(年間4千円程度も)減らせそうだし、後継のビジネスプランは月額US$10なので、来年継続するよりも大幅に安い。

※減らしたのは音楽データである。そのほとんどはCDを取り込んだもので、基本的には、データがなくなっても再度取り込めばいい。ところが、実際問題として、全部なくなった時に再度数百枚のCDを取り込む気にはなれない。が、今はSpotifyがあるから、そこにあるものはそれで聴けばいいだろうと考えた。

すると、バックアップが必要なのは、(ほんのわずかにある)自分の演奏や昔のカセット・LPなどからの曲やダウンロード購入したものや、手持ちやレンタルしたCDのうちSpotifyにないものだけとなるので、そういう曲を選別した。選別は、スクリプトを作って自動判別しようと思ったが、作るのが面倒だったので、手でアーティストごとに検索した。つもりだったが、実際には手持ちのCDについては調べてなかった。それは大変だ。。。やっぱり、お金に任せて全部バックアップするのがいいのかも知れない。

良く考えると、オンラインバックアップからしかリストアできない場合というのは、災害などでPC本体はおろか外付けHDDもなくなってしまった状態だろうから、そんな時はCDだってないだろうから、取り込み直すことはできない。また、Spotifyのレパートリーかどうかで分類すると、別のサービスに乗り換えたら再度分類する必要が出て煩雑だ(これはベンダーロックインのようなものだ)。そうすると、全部バックアップするか、全然しないか、特別なもの(例: 再入手不可能なもの)だけするかになる。全部はいかにも無駄なので、特別なものだけバックアップするのが良さそうだ。そういうものは果たして何枚あるだろうか? (調べるのはおもしろそうだ) → 結構な数になった。めぼしいもの112アルバム(約19GB)を追加バックアップしたら、B2の総データ量は410GBになった。 (8/12 4:14記)

なお、ストレージでのデータ量は圧縮されているため、元のデータ量はもっと多い。今の構成にする時に計算し直さなかったのだが、500GB程度はあるはずで、それが350GB程度までに減ったのはどうも信じられない。Duplicacyの性能がいいのかも知れないが、バックアップ対象設定の誤りで抜けがないか心配なので、追って確認したい。 → バックアップされたファイル一覧で確認したら、問題なかった。今回の構成にする時に更にデータ量を減らしていた。 (8/12 4:14記)

仮に従来と同じデータ量(1TB程度)をバックアップすることにした場合でも、月額US$5.1(年間6800円)程度となり、今までのCrashPlan(個人プラン)と同等になるから、しばらくは実際に掛かった料金を見ながら検討したい。

なお、Duplicacyはファイル変更の履歴を保存できるため、データ量が想定以上に増えないかやAPI実行回数が異常に増えないかの監視が必要だ(どちらも料金が増える原因のため)。

それにしても、バックアップソフトにDuplicacy, Duplicati, Duplicityと、似たような名前のものがいくつもあって、大変紛らわしい。"De-duplication"(重複排除)から来ているのだろうが、最初はどれだったのか気になる。どうでもいいことだが。

それはともかく、試したほとんどのソフトが(機能・性能・安定性の点で)まともに使えなかったのは全く嘆かわしい。Linuxで使うのにシンボリックリンクに対応していないもの、変更のスキャンや転送やリストアや変更履歴の整理(prune)が遅過ぎるもの、スリープ(からの復帰)に対応していないもの、処理を中断すると管理データが壊れるなど堅牢性や安定性に欠けるものなどがあった。僕の環境や使い方が特殊だとは思えないので、細かいことをちゃんと考えて作っていないのだろうか。バックアップソフトでそれは困るのだが・・・

そういう点で、Duplicacyは信じられないほど期待通りの機能・性能(「まとも」)なので感心している。転送速度が安定して高速(おそらくCrashPlanの10倍以上)なのはいいし、初回のバックアップは別として、その後のスキャンもpruneも高速かつ負荷が低い(おそらくCrashPlanの1/5以下)ので、定期実行するにはとても良い。いつものことだが、しつこく探してダメ元で試して良かったw そして、コマンドライン版が無料なのは大変ありがたい。コマンドの使い方が独特なので、GUIの方が楽だったとは思うが、設定が確定した後はGUIの価値はないので、毎年お金を払うよりはいいと思う。

運用の話を書くと、バックアップは6時間ごとに自動で行わせている。バックアップ間隔を短くする価値があるのか良く分からない(今は趣味だけなので、おそらくない?)ので、しばらく状況をみて調整したい。変更履歴は、1週間までは毎日1個、1か月(30日)までは1週間に1個、1年(360日)までは30日に1個残すことにした。これも、どういう設定がいいのか良く分からない。ただ、今まで、履歴を使ったことや欲しかったことがほとんどない(そもそも、オンラインからリストアしたことがほとんどない)ので、多くを保存する必要はない気はする。変更履歴の整理(prune)間隔は1日に1回とした。

バックアップの履歴の必要性について個人的な考えを書くと、おそらく、履歴は要らない。プログラムなどの開発の時に使う、gitなどのバージョン管理システムの方がずっといい。というのは、定期バックアップはいつ実行されるか不明なので、残っているものが必ずしも有用なもの(「欲しかったもの」)とは限らないからだ。手動で実施するにしても、忘れたり間隔が長くなり過ぎる可能性がある。それなら、キリのいい時に自分で(gitなどに)コミット(保存)した方がずっといい。コミット時にコメントも付けられるから、それがどういうものかも分かる。そして、そのリポジトリをバックアップしておけば、安心だろう。

あと、プログラムじゃないもの(例: システムの設定ファイル)については、「あ、やっちゃった!」と思ったら、そのファイル内にコメントとして残しておいたオリジナルに戻すか、記憶で戻すか、あらかじめ保存しておいたファイル(例: *.orig)に戻すか、すぐにバックアップ(もしあれば)から戻すか、再度作り直すかするかwするので、やっぱり履歴は要らない気がする。この場合は、バックアップ自体が役に立たないことが結構ある。

まあ、履歴に慣れ親しんだ人だと効果的に使えるのだろうけど、履歴に頼り過ぎてしまうと、過酷な環境では生きて行けなくなってしまうからw、余り良くないと思う。 (8/12 17:04)

少し話が逸れるが、運用に関連しているので書くと、このブログサーバのバックアップも、最終的にはB2にするようにした。今までは、週一回、PCの外付けHDDにバックアップするだけだったが、今回から、週一回のバックアップをPCの内蔵HDDに行い、そこを外付けHDDとDuplicacyのバックアップ対象にしておき、その後の定期バックアップでB2に送るようにした。実は、サーバにもDuplicacyを入れれば直接B2にバックアップすることが可能だが、サーバにB2のアカウント情報を入れるのは不安なので、このように間接的なことをしている。

実装の話になるが、バックアップなどを定期的に実行するのにはcrontabを使っている。crontabを使う際の問題として、スリープからの復帰後に、スリープ中に行われるべきだったスケジュールが実行されないために※、スリープ中にスケジュールがあると、最長6時間、バックアップが遅れる。そのため、バックアップコマンド(スクリプト)を2時間ごとに起動して、最長(6時間でなく)2時間の遅れで、スリープ中に行われるべきだったバックアップが行えるようにした。そして、そのコマンドの中で、前回からのバックアップやpruneからの経過時間が最小間隔(例: 6時間、1日)より短い場合には何もしないようにして、バックアップ間隔を維持するようにした。なお、コマンド起動間隔の2時間は1時間でも30分でもいいが、そこまで厳密でなくていいので、長目にした。

※実際の動作を見たら、スリープ中に行われるべきだったスケジュールは必ずしも実行されない訳ではなく、スリープからの復帰後に実行される場合がある(例: スリープ中だった14:04のスケジュールが復帰後の15:08に実行された)。ただ、実行されない場合もあったので、その違いが良く分からない。スリープが長時間で、複数回のスケジュールが飛んだ場合は実行を諦めるのだろうか。あるいは、復帰した時刻と実行すべきだった時刻の差で判断しているのか。あるいは、僕の思い違いで、最後に飛ばされた1回は必ず実行されるのか。マニュアルに書いてあるのかも知れないが、無精なので調べていない。 (8/12 16:10)

それから、仮にバックアップ処理が6時間以上に長引いた場合や間違って実行した時に複数のバックアップ処理が同時に実行されるのは良くないので、既に実行中の場合に後から実行したものは何もしないで終わるようにした。こういうのはGUIだと何も考えずに対処されるのだろうが、Linux版がないので仕方ない・・・

余談だが、光回線が予想以上に優秀で、上下同時に使ってもどちらも80Mbps以上出たので感心した。あと、今は基本的に転送データ量での速度制限はしない(以前、「混雑した時に制限するポリシーに変更した」という連絡があった)ようで、数日間、断続的に80Mbps前後でアップロードし続けていても大丈夫だった(いつ警告が来るか心配ではあったがw)。

光回線を上下同時に使っても80Mbps以上出た(左の「金 06」の上の上下に大きく振れているところ)。

(8/12 16:36 若干、加筆・修正)

  •   0
  •   0

[8/11 1:59 ResticとWasabiの評価で問題が見つかったため結論を変更し、その件を記載した。 → まとめ]
[8/4 12:24 8/2の更新後のDuplicatiの試用中に新たな情報が得られたので、再度、結論などを変更した。結局、最初の結論に戻った。]
[8/2 15:45 投稿後に新たな情報が得られたので、結論などを変更した。見難くならない限り、前回の記述を取り消し線で残した。]

現在使っているオンライン(クラウド)バックアップサービスCrashPlanは、Linux対応で定額制(使用量・転送量が無制限)で良かったのだが、去年、個人向けサービスを終了してしまって、Linuxで使う場合はビジネス用プランに移行せざるを得なくなって、かなりの値上げ(確か、年間5千円程度増)になった。来年の1月までは大幅な割り引き(75%引き)になっているので、ムカつきながらも(それで止めた人は多そうだ)とりあえず使っているが、今年中に移行先を見つける必要がある。本音を言うと、Windowsの時に使っていたBackblazeがLinuxでも使えれば、それで全く問題ないのだが、サポートされていないので他を探すしかない。

検討作業は9月頃から始める予定だったのだが、近頃時間ができたのでいろいろ試してみたら、今まで知らなかった新しいことが分かった。ここでは、そういうことも紹介したい。

結論を先に書くと、Backblazeや個人向けCrashPlanほど適当なものはなく、いくつかのものを組み合わせて実現するしかない。今は、以下のようにオンラインストレージ対応のバックアッププログラムを使って、オンラインストレージにデータをバックアップする構成が(費用対効果が)最も良さそうだと考えている。

別々の構成は、面倒だったり費用がかさむ気がするが、光回線とプロバイダのような感じで、それぞれが選べる点がいいのかも知れない。料金が変わったなどの場合に、気軽に片方(主にストレージか)を換えることも可能だ。それから、バックアッププログラムとストレージが別だと、仮にストレージに侵入された場合でも、記録データのフォーマットや暗号化の情報がなければ、データが流出しにくいことが期待できる。

実際には、フォーマットは公開されていたり、そうでなくても解析すれば分かるだろうし、暗号化だってしょぼかったら解読されてしまうが、データの暗号化と記録が一体化したバックアップサービスの場合よりは強固そうだ。強力なのは、ブロックチェーンのように、データを分割して世界中のサーバに分散して記録することではないだろうか。

試しているうちに、いくつかの必須条件や注意点が見つかったので、列挙する。

  1. クライアント(PC)側から鍵(パスワード)を指定してデータの暗号化ができること。更に、その鍵はサーバには保存しないこと。
  2. シンボリックリンクをサポートしていること。
  3. スリープからの復帰後にバックアップが自動で再開すること。
  4. 転送速度が高速なこと。
  5. 可能なら、ストレージ側でファイル・ディレクトリ名が見えないこと。
  6. サーバは、なるべく2要素認証であること。

1は、サーバ(ストレージ)側でデータがどのように扱われるか分からない(例: サーバのHDDが壊れた時、どう破棄されるか)し、サーバのアカウントが破られる可能性があるので、こちらからデータを送る時に暗号化する必要がある。「サーバ側で***方式で暗号化して保存する、強固なセキュリティ」などと書かれていてもそれを信じてはいけないと思う。あと、「SSL/TLSで(通信経路を)暗号化」とか書いてあるのは当たり前過ぎて笑えるが、それだけしかなかったら、全く駄目なサービスだ。

2は、Linux(UNIX)で使うなら必須だ。シンボリックリンクはWindowsのショートカット(キーでない方)やエイリアスに相当するもので、データ量としては取るに足らないが、情報としては重要なこともある。あるものが欠けたらシステムが動かなくなることもある。最初は、バックアップするのはテキストや写真など、通常のデータが主だから、なくてもいいか(我慢する)とも思ったが、復旧時に、記憶を頼りに手作業で直すのは現実的でないと思うし、何も考えずに保存できなかったら、それはバックアップとは言えないと思う。試したうちで、「Linux対応」とと書いてあったりLinux用のアプリなのに、さらっとシンボリックリンクをサポートしないもの(iDrive, Rclone)があったので、注意が必要だ。そういえば、今使っているCrashPlanが大丈夫か、心配になって来たw

3は、バックアップを定期的に自動で行う場合に、デスクトップPCなので、常時稼働させている訳ではないから、バックアップ中にスリープできなかったり、スリープからの復帰後に手動での再開処理が要るのでは「使えない」ということだ。スリープさせたら、復帰後に何もしなくてもバックアップが再開されて欲しい。

5も1と同様で、ファイル・ディレクトリ名が見えない方が、セキュリティの点で望ましいだろう。

6は今では当たり前のことだが、まだ少なくて、従来のパスワード方式が多い。そのため、1のデータ暗号化をする価値があると思う。

今回試したか検討したものと評価を以下に書く。

バックアップサービス (アプリ+ストレージ)

  • ×× iDrive
    • GUI
    • シンボリックリンク: NG (無視する)
    • スリープ後の復帰: NG (回復しない)
    • 高速: 約10MB/s
    • サポートがひどい。
    • 安い: CrashPlanからの移行ユーザには大幅な割り引き(最初の年は9割引き!)があるが、シンボリックリンクをサポートしていない時点で論外(安さにつられて、気付かずに加入してしまった)。「安かろう悪かろう」の典型。
    • 暗号化鍵をサーバに保存しているフシがある。
    • (8/21 19:17追記) 入ってすぐに止めたら、頼んでいないのに返金してくれていた。その点は意外にまともだった。なお、為替変動のため、数円損したw
  • × pCloud
    • GUI
    • 高い (2TB: $96/年)
    • クライアント側でのデータの暗号化ができない(別料金)。

バックアップアプリ (ストレージ別)

  • × CloudBerry
    • GUI
    • 動作がおかしい・不安定 (起動しないことがある、ファイル数・データ量の表示がおかしいことがある)
    • シンボリックリンク: OK
    • スリープ後の復帰: OK
    • ストレージでファイル名が見えてしまう。
    • 中速: 約3.3MB/s
    • Wasabiが使えない(設定してもエラーになる)。
  • × qBackup
    • GUI
    • シンボリックリンク: OK
    • スリープ後の復帰: OK
    • ブロック化しているため、ファイル・ディレクトリ名は見えない。
    • 高速: 約7.7MB/s
    • ファイルのサイズと更新日時だけで更新を判定している(他のソフトがどうしているかは未確認)。
    • データをブロック化しているため、バックアップの一部でも壊れた場合に修復できない。直すには全体を作り直すしかない。→ 大規模・長期間使用で破綻するリスクが高い。
  • × GoodSync
    • コマンドラインのみで、これがGUIのバックエンドそのものという感じで、オプションの数が多過ぎるうえに資料も少なくて、どうしていいか分からない(考えたくない気分になった)
    • 設計が古くて、いかにもWindows的(例: Linux版なのに、オプションの先頭の文字が"-"でなくて"/"、ヘルプは"/?"。すごくおぞましいし、パスのセパレータがどうなるのか分からなかったので、止めた)。
  • × Duplicacy
    • コマンドライン。GUIもあるらしいが、見つからなかった。← Linux用GUIは開発遅延中。
    • GUIは有料で毎年お金が掛かる: $20+$5/年、コマンドラインは個人使用は無料。
    • シンボリックリンク: OK
    • データをブロック化しているため、ファイル・ディレクトリ名は見えない。
    • (ブロック化しているので、)破損に関しての信頼性は不明だが、正当性のチェック機能があるので、異常の検出は可能。
    • 高速: 7MB/s前後 (ただし、処理スレッド数を増やさないと遅い)
    • リストアも高速
    • ファイルのスキャンも高速
    • prune(不要な過去バックアップの削除)も遅くない。
    • スリープ後の復帰: OK (10-15分程度)
    • Wasabiが使える。
    • バックアップ除外指定に正規表現が使える。
    • 負荷は高くない。(Load ave.は最大1.5前後)
    • サーバ(ストレージ)に暗号化鍵を保存しない。
    • リポジトリのロックを行わない。
  • ×× Duplicati
    • Web UI (コマンドラインも可)
    • シンボリックリンク: OK
    • データをブロック化しているため、ファイル・ディレクトリ名は見えない。
    • (ブロック化しているので、)破損に関しての信頼性は不明だが、正当性のチェック機能があるので、異常の検出は可能。
    • バックアップデータ(リポジトリ)の堅牢性に欠ける。
      • バックアップを中断したらリポジトリが破損し、確かに異常検出はされたが、修復処理をしても回復できなかった。
    • ブロックのファイルが単一ディレクトリに格納されるので、数が増え過ぎた時に問題が起こらないか不安 (センスが悪い)
    • 処理が遅い。 高速: 8MB/s前後
    • リストアも高速だが、通信速度以上の速度になるので、動作が疑わしい。
    • ファイルのスキャンが遅い。resticの1/3程度。
    • スリープ後の復帰: NG (回復しない) OK (復帰まで15分くらい掛かる)
    • Wasabiが使えない(設定してもエラーになる)使える。
    • バックアップ除外指定に正規表現が使える。
    • CPU温度が高目(resticより5℃くらい高い= 負荷が高い?)。
    • Windows版の移植(Monoというもので動かしている)。機能的には問題ないが、負荷が高いことや動作がおかしいことがあるのはここに起因している?
  • × restic
    • コマンドラインのみ。
    • シンボリックリンク: OK
    • スリープ後の復帰: NG (回復しない場合がある)
    • データをブロック化しているため、ファイル・ディレクトリ名は見えない。
    • (ブロック化しているので、)破損に関しての信頼性は不明だが、正当性のチェック機能があり、異常の検出と修復が可能。
    • ファイルのスキャンが遅いことがある。
    • 高速: 約9.6MB/s (遅い場合もある)
    • リストアが遅い。: 約1MB/s
    • prune(不要な過去バックアップの削除)がすごく遅い。
    • バックアップ先のストレージをLinuxにマウントしてアクセスできるのは便利。
    • Wasabiが使える。
    • サーバ(ストレージ)に暗号化した暗号化鍵を保存する。
    • バックアップ除外指定に正規表現が使えない(シェルのパターンのような簡易なもの)。
    • 正常に終了してもロックが解除されず、次回エラーになる。
    • B2でrcloneと一緒に使う場合、通信エラーが頻発することがある。
  • × Rclone
    • コマンドラインのみ。
    • シンボリックリンク: NG (実体をコピーするか無視を指定)
    • スリープ後の復帰: OK
    • ストレージでファイル名が見えてしまう。
    • ストレージに対してls(ファイル一覧)などのコマンドが実行できるのは便利。
    • 高速
    • Wasabiが使える。

オンラインストレージ

  • × Amazon AWS
    • 一番安いもの(Glacier)を選んでも、やっぱり高い。
    • 転送量なども効いてくるので、費用の見積もりが難しい(面倒)。
  • × Oracle
    • ストレージは安そうなのだが、単体で使えるのか謎だった(相変わらず売る気がない?)。
  • Backblaze B2 Cloud Storage
    • 安い: $0.005/GB/月 → 1TBの場合、$5.1/月
    • 最低利用料金がない。
    • 転送量とAPI実行回数に課金あり。
    • 10GBまで無料で使えるが、ダウンロード制限がキツくて、満足に試せない(リストアの確認ができなかった)。
    • Webは2要素認証
    • Webの使い勝手はいい。使っていて気持ちいい。
  • Wasabi
    • 最安: $0.0049/GB/月 → 1TBの場合、$5/月
    • 最低利用料金($4.9/月= 1TB分)がある。
    • 転送量とAPI実行回数に課金なし。
    • 30日間、1TBまで無料で使える(クレジットカードの登録不要)。B2のような制限がないので、かなり充分に試せる。
    • 新しいサービスなので、信頼性などには疑問あり。なぜか、対応しているはずなのに使えないアプリや、謎のエラーが出たりする。
      • 謎のエラーは解決した(8/1の追記を参照のこと)。 (8/1 11:21)
    • 格納データ量が1日に1回しか計算(更新)されない。
    • Webの使い勝手はいい。

その他 (今回気付いた現状の問題)

  • CrashPlan
    • 今回試したものに比べて、かなり遅い(更新のスキャンも転送も)ことが分かった。
    • いつも転送ばかりしている感じ。
    • アプリが簡素過ぎて(改悪されてしまった)、見ても状態がほとんど分からず、本当にバックアップされているのか不安になる。

[以下の灰色部の記述は古いが、履歴として残す。 8/4 14:29]

最初は駄目だと思っていた、Duplicatiが一番良さそうである。単一のアプリですべての条件を満足するし、Web UIがあるのでバックアップ用のスクリプトを作る必要がなく、状態監視・操作・設定が楽でいい。基本動作の確認後、Wasabiの試用期限まで、実運用の状態でバックアップしてみて、問題の有無や使い勝手などを確認しようと思う。

Duplicatiのweb画面 (バケット名は隠した)

(8/3 8:57追記) それにしても、resticが暗号化鍵をサーバに保存するという仕様は全く不可解だ。昨日、見つけた比較サイトで知って唖然とした。もちろん、暗号化鍵は更に暗号化して保存しているようだが、なぜそんな危険を冒すのだろうか。多少便利になるのだろうか? 理解できない。

それで、resticのサイトを確認したところ、ユーザの設定したパスワード自体はサーバに保存していないが、それから導かれた、暗号化や認証に使う鍵はサーバに保存している。更に資料を読むと、そうする理由が書いてあって、パスワードの変更を容易にできるようにするためとのことだ。つまり、パスワードと暗号化鍵を同じものにすると、(漏洩対策などのために)パスワードを変更するには、全データを再暗号化する必要が生じる。一方、resticの方式ではその必要はない。確かにそうだが、現実問題として、どちらがいいのだろうか。resticの方式が破られる可能性はないのだろうか?

いずれにしても、resticはリストアが遅すぎて実用的でないから、現時点では使うことはできない。

(8/4 12:24, 13:51追記) Duplicatiを実際の条件で試用していたら、どうも動作が不安定な感じがした。例えば、スキャン速度やデータ送信速度が実行のたびに大きく異なる(すごく遅い場合がある)ことである。更に、リストアが速過ぎる(通信速度を大幅に超えていた)ので、どうも信頼できない印象を受けた。

それで、バックアップを中断してresticを試したのだが、使い勝手の点で劣るため、気が変わって再度Duplicatiでのバックアップを再開したら、リポジトリが破損しているエラーが出た。それで修復処理を実行したのだが、どうしても直らなかった。

どうやら、Duplicatiはリポジトリの構造が脆弱(壊れやすく復旧できない)なようだ。壊れるだけならいいが、バックアップの中断程度で回復できなかったら、実使用には全く耐えられないから、不採用とし、resticでの評価を再開している。

ちなみに、resticも、再開しようとしたら、リポジトリのチェックが要るというエラーにはなったが、ちゃんと修復できてバックアップが再開できた。なお、ストレージに保存済みのデータをチェックしているのか、データ送信が再開するまでには結構時間が掛かった。それでも、中断まで書き込んでいた時間よりは短かった(6時間書き込んでいて、チェック(?)は1時間程度だった)。

resticの問題は、リストアがすごく遅いことと暗号化鍵がストレージに保存されることと使い勝手が劣ることだ。リストアの遅さは我慢するしかないが、大規模なリストアでなければ、ストレージをマウントして、ファイル一覧を見ながら1個ずつリストアできるというメリットはある。暗号化鍵の点は、リポジトリのパスワードが破られなければ安全なので、強度はDuplicatiと同等なのかも知れない。ただ、resticの仕組みが破られたりやバグが突かれたら駄目だろうから、そこは信用するしかない。使い勝手については、スクリプトを作るなどして自分で解決したり、我慢する必要がある。

 

[8/4 12:24 結論が変わったので、再度有効にした。][以下の灰色部の記述は古いが、履歴として残す。 8/2 15:45]

残念ながら、現状では単一のバックアップアプリ・サービスで最適なものはなかった。アプリの機能ではresticが一番良かったのだが、スリープ非対応なので、最初はそこをうまく対処して(バックアップ中にスリープしたら、復帰後にアプリを再起動させる)使おうと思っていた。

そのためのスクリプトも作ったのだが、resticとRcloneが組み合わせられれば(「いいとこ取り」ができれば)最強だと思って更に調べたら、本当に組み合わせて使えることが分かり、今はその形態で、実使用に近い大容量(500GB-1TB)・長時間のバックアップを試している。

なぜ2つを組み合わせるといいかというと、resticが駄目なのは、スリープからの復帰後に失敗した通信をリトライしないからなので、バックアップデータの処理はシンボリックリンクをサポートするresticにやらせ、オンラインストレージへの記録は、通信の失敗時にリトライするRcloneに任せればいいのである。以下のような構成である。

バックアップデータ → restic → Rclone →(ネット)→ オンラインストレージ

なお、resticとRcloneを組み合わせた場合には、restic単体に比べて若干転送速度が低下する(約8.8MB/s)。組み合わせたせいで遅くなるのか、なぜかRcloneではWasabiのリージョンがUS東海岸しか選べないせいなのかは不明である。それでも、CrashPlanよりは充分に速い(確か10倍以上)ので問題はない。

(8/1 2:50 加筆・修正)

(8/1 11:26追記) Rcloneで、WasabiのUS西海岸リージョン(us-west-1)へのアクセスがエラーになる問題は解決した。専用のホスト名(s3.us-west-1.wasabisys.com)を指定する必要があった。(→ 参照) 今の評価が終わったら、速度を比較したい。

(8/2 2:16追記) 西海岸リージョンを試したが、劇的に速い訳ではなく、東海岸より12%程度速いだけだった。Rcloneを入れると速度が低下するようだ。それでも、経路が近い方が問題の起こるリスクは下がるので、こちらを使うことにする。

次に、リストアを試したら、リストア自体は問題なくできたのだが、速度が約720KB/sと、かなり遅かった。B2でも遅かったので、サーバが遅い訳ではなく、リストア処理が重いのだろうと思う。Rcloneを通さないで試したら、1.5倍くらい速くなることが分かった。リストアは定期的に行うものではないし、リストア中にスリープするような危険は冒したくないので、restic実行用スクリプトを修正して、リストア時はRcloneを通さないようにした。

この条件で再度テストを行った後、試用期間いっぱいまで、実運用の状態でバックアップしてみて、問題の有無や使い勝手などを確認しようと思う。

resticを使ってみたら、さまざまな問題が出て来て、かなり不完全でとても実用には耐えないと思った。例えば、resticはバックアップなどの処理の際にリポジトリ(バックアップデータ)をロックした後、正常に処理を終えてもロックを解除しないので、自分で解除処理をしないと次回にエラーになってしまう。これだけでも出来を疑ってしまう。

それから、画像のように圧縮できない小さいファイルが多い場合や、大きなファイルの転送が遅く、バックアップ対象変更時の再スキャンも遅く、prune処理(過去の不要なバックアップ履歴の削除)がかなり遅い(数時間掛かる)。更に、prune処理中にスリープしたらハングした。また、Rcloneと組み合わせてB2で使うと、エラーが多発した(resticではなく、RcloneとB2の相性だと思う。大きなファイルの転送時に起こると思われる)。また、プログラムの出力をファイルにするとメッセージが少なくなってしまって、処理状態が分からないなど、使い勝手の問題もあった。

Wasabiは、よく調べたら1TB分の最低利用料金が掛かることが分かり、データ量が少ない場合には最安ではないことと使い勝手に不満があったので、却下した。

それで再検討・評価したところ、当初は毎年更新料が必要と思っていたために(実際にはそうでなかった)却下していたDuplicacy(コマンドライン版)とBackblaze B2の組み合わせが最適という結論になった。この組み合わせは最初に挙げた必須条件をすべて満たすうえに、すべての処理(ファイルのスキャン、転送、リストア、prune)が高速なのが素晴らしい。

DuplicacyとB2の基本的な動作を評価して大きな問題がなかったので、現在は実運用の状態で継続的にバックアップを行い、問題の有無や使い勝手などの確認を行っている。その後、しばらくCrashPlanと並行して使うか、CrashPlanを止めるかする予定である。 (8/11 1:59)

 

PS. 通信速度の高速化には目を見張るものがあり、昔はオンラインでのバックアップに1か月以上掛かっていたが、今なら数日間で終わりそうだ。太平洋の回線がかなり太くなったような気がする。もちろん、サーバ側のリソースにも依り、CrashPlanは悲惨なものだ。

PS2. まともなアプリはほとんどコマンドラインというのは嘆かわしい。しょうもないGUIよりはましだし、自分の希望どおり細かく設定できるのはいいのだが、正直なところ、バックアップなんて、いい加減(お手軽)に設定してもそこそこちゃんと動いて欲しいものだ(いや、その「そこそこちゃんと」が難しいのだがw)。。。

PS3. Duplicatiは、resticのリストアがすごく遅いので、解決策を検索していたら、他のアプリ(Borg)が紹介されていて、それとresticを比較しているページを読んでBorgは使えないことが分かったのだが、更に検索したら、何かのフォーラムにDuplicatiがいいという投稿があったので再度試してみたら、機能も性能も良かった。最初に試した時は慌てていて、いろいろ間違っていたのかも知れない。 (8/2 15:58)

(8/3 17:14 Duplicatiのファイルスキャンが遅い件を追記; 8/11 1:00 再々更新)

  • restic/restic

    restic/restic

    Fast, secure, efficient backup program. Contribute…

  •   0
  •   0

拙作のSpotifyミニプレーヤー(minisp)の話である。

僕は外国の音楽を聴くことが多いので、Spotifyアプリの言語設定を英語にしている。それでminispもそのまま英語表記にしていたのだが、演奏者の名前については、日本のポップ音楽の時は、日本語で書いた方が見やすい気がしていた(なお、英語モードにしていても、日本のポップ音楽の曲名やアルバム名は日本語で出る)。例えば、前の稿で書いた渡辺真知子は"Machiko Watanabe"じゃなくて、やっぱり「渡辺真知子」の方が見やすいし適切だろうと思って、何とかしようとしていた。

が、その「日本のポップ音楽の演奏者だけは、名前を日本語で書く」という機能を実現するのは結構難しかった。どうやって日本のポップ音楽の演奏者を判別するかが問題だった。最初はMusicBrainz(フリーの音楽情報DB)の演奏者情報を使おうとしていたのだが、フリーのためか、登録されている情報が使いにくい(英語圏以外の人名が現地語で書かれている(例: ルガンスキーは"Николай Луганский"): DBの情報としてはすごく正しいことだが、使いにくい)とか一貫性がない(例: 抜けがある)などの問題があって、うまく使えなさそうだった。仮にそこが何とかなっても、そもそも「日本の演奏者」を判定するのが困難だったので、ずっと保留にしていた。

が、先日、SpotifyのWeb APIが使えるようになり、それで取得できる演奏者情報の中にジャンルがあり(なぜか、曲にはない)、運のいいことに、日本のポップ音楽の演奏者のジャンルには"japanese"とか"enka"とか"kayokyoku"とかいう単語が含まれていることが分かったので、それで判別することにした。なお、ISRC(曲の録音の識別記号)の先頭の2文字で「日本の録音」であることが判別可能なので、それを使うことも可能なのだが、仮に外国の演奏者の日本録音盤があった場合(ないとは思うが・・・)に誤判定になるので止めた。

少し苦労したが、うまく行った。が、思わぬ伏兵が居た。日本人のクラシック音楽の演奏者だ。その人たちのジャンルにも"japanese"が入っているので、名前が日本語で表記される。例えば、内田光子だ。それも一貫性があっていいのだが、個人的には、世界的なクラシック演奏者は英語で書く方が適切だと思っているし、オリジナルCDでも英語なので、ここは英語にしたい。

幸い(というか、どういう訳か)、日本人のクラシック音楽の演奏者には"japanese"とともに"classical"という単語が入っているので(例: "japanese classical performance")、その場合には英語表記にすることにした。

余談: (日本の曲だけを演奏している訳でない)クラシック音楽の演奏者のジャンルに国の情報を入れるのは、ちょっと差別的(昔の、「日本人のクラシックだよ()」という嘲笑を感じる)な気がするが、まあ、Spotifyはそういうポリシーなのだから仕方ないし、今は便利だから良しとする。でも、個人的には、入れるのであれば、「出身地域」などのようなフィールドの方が適切だと思う。が、いろいろな問題や文句が出そうなので、無理そうだ。

更に調べたら、ユジャ・ワンやチョ・ソンジンのジャンルには、国籍を示す単語は入ってなかった。どういうことなのか理解に苦しむが、考えても仕方ない。まあ、Spotifyでなく、レーベルがデータを作ってSpotifyに渡していて、その作り方の違いなのかも知れない。実際、ソン・ヨルムのジャンルは空だった。

という訳で、とりあえずできたが、(僕のわがままのせいで)いろいろな判定が多くなってプログラムが複雑(正確には「肥大化」)になっているのが気に入らない。あと、上の判定はやっぱりいい加減なので、今後、思わぬ落とし穴が見つかりそうだ(例えば、日本のポップ音楽だけを演奏する外国の演奏者が居たら、一体どうなるのか?? あと、宇多田ヒカルはどうなんだ? → ジャンルに"japanese r&b"が入っているので、日本語で出るはず)。

技術情報: SpotifyのWeb APIで、例えば曲情報の言語(例: 日本語/英語)を指定して取得する方法はあまり資料には書いてないが、可能だ。カテゴリーのブラウズにならって、要求のURLにlocale引数を追加すればいい。例えば、Spotify IDがxxxxの曲のトラック情報を日本語で取得するには、URLを以下のようにする(太字部分を追加)。

GET https://api.spotify.com/v1/tracks/xxxx?locale=ja_JP

これは公開情報でないので、いつまで使えるかは不明だが、単に資料の記載漏れと思うので、大丈夫だろうと思う。

  •   0
  •   0

暇なので、余計なことをいろいろ考え付く。昨日、ふと、光回線のアダプタ(ONU)が邪魔に思えた。ONUの後に繋ぐルータは結構前に本棚の下に移設して、見えなくしていたのだが、ONUは光ケーブルが短いうえに弱くて移動できないので、光端子の近くに置いて、小さい衝立のようなもの(台)で隠していた。が、やっぱりすっきりせず、見るたびに何とかしたいという気分になっていた。しかも、衝立の陰に埃が溜まって来たのも、嫌な感じだった。

それが、何の拍子だったか、「丈夫な光ケーブルがあれば延ばせるのではないか?」と思い※、Amazonを探してみたら、強化された光ケーブルがあった。キーワードは、「光配線コード」と「曲げに強い」とか「曲げフリー」のようだ。

※順序が逆かも知れない。「とりあえず断線してもいいから、安いケーブルで延ばそうか」と探していたら、関連商品に強化されたものが見つかったような気もする。しょうもないことに、すっかり記憶がないw

全く知らなかったのだが、通信用光ケーブルにはいろいろな種類があるようで、フレッツの光回線に使えるのは、以下の仕様らしい。

SCコネクタ(シャッターなしでも可), シングルモード(9/125), 1心(芯?), SPC研磨, 波長: 1310/1550nm

畑違いなので、まったく初めての単語が多い。そして、家庭用でもシングルモードを使っているのがちょっと意外だった(業務用をそのままを使っているのかも知れない)。だから、やろうと思えば100mくらいは延ばせるのではないか(要確認)。

余談: オーディオマニアは、このケーブルを使うことは考えないのだろうか? 普通のS/PDIF用光ケーブルなんて、きっとマルチモードだし、減衰も大きそうだし、特性も悪そうだから、この通信用インタフェースとケーブルを使えば、波形が美しくなり、ノイズやジッタなどが減って、音質が向上するとは思わないのだろうか? (僕は思わないがw) まあ、音質は分からないとしても、コネクタはしっかりしているから、それだけでも使う価値はありそうだ。

ヨドバシには全く置いてなかったので、Amazonで注文した。線が黄色の物は安いのだが、目立つのは嫌なので、割高だけど白色のものにした。5mで約1500円だった。プライム会員でないと送料が掛かるのだが、運良くお試し会員になれたので、なった。

今朝届いたが、とても簡素な袋(クッションの薄い紙袋)に入っていて、輸送中に破損しないのかと思った。更に、「ステンレス管で保護」とかいう割には華奢で弱そうだった(しなやかで、全然硬さを感じない。径は3mm程度)。破損させないように気を付けるに越したことはないだろう。さっそく試してみたら問題なく通信できたので、ONUをルータの近くに移動させた。ルータ同様に横置きできることが分かったので、最終的には、本棚の下のルータの隣に置いた。ついでに、JACKが問題なく動いているので、グライコ(DEQ2496)を仕舞って、本棚も少しすっきりさせた。

(長らく掃除をしていなくて埃が溜まっているので)写真は載せないが、光端子の付近がとてもすっきりして、大変気分がいい。ONUがなくなった以外に、光通信自体には電源は要らないので(というのはまやかしで、実際には光を出すのも受けるのにも電源は要る。この光は局から直接来ているのだろうか? それとも近くに中継点がある?)、電源アダプタなどを置く必要がなくなったのも大きい。あと、光ケーブルが細くてLANケーブルより目立たないのもいい。

PS. ちなみに、通信速度を測ってみたら、Fast.comで"140Mbps"と出た。これが速いのか普通なのか、値が正しいのかそうでないのかは全く分からないし、普通に通信できればいいから気にしないがw、とりあえず、光ケーブルに問題はなさそうだ。

(7/27 2:44, 6:48, 7:36 写真を載せ、少し加筆)

  •   0
  •   1

その後もSpotifyに飽きることはなく、Google Play Music (GPM)の支払いの継続を止めたので、移行済みとなった。前回も書いたが、あれからも手持ちの曲は掛けていない。連続2週間になる。ビートルズなんて手持ちで聴けるのに、わざわざSpotifyのプレイリストで聴いたりしたこともあった。GPMとは違って、なぜかは分からないが、随分居心地がいいようだ。個人用のリコメンド("Your Daily Mix")などの選曲がいいのが大きいのではないだろうか。

Spotify制御ツールの改良にも飽きることがない。もう、大きな改良はない(やりたいことはあるが、面倒なので保留している)が、細々とした改良や突然見つかるバグ修正を(慌てて)している。

昨日は、ちょっと思い付いた機能を追加した。先日、クラシック音楽の演奏者名が作曲者になっていたら、それを除外して2番目の演奏者名を表示するようにしたのだが、その機能を発展させて、曲名やアルバム名に作曲者名が入ってなかったら、曲名に追加するようにした。面倒な割には誤動作もあるだろうから止めとこうとは思ったのだが、知らない曲で気になるものの作曲者を一目で知ることができれば便利だと思ったのだ。

まず、除外した時点で作曲者(の可能性の高い人)は分かっているから、それを保存しておく。ただし、フルネームを出すと長くなってしまうので、姓(モーツァルトなら"Mozart")だけを抽出するようにした。もちろん、AIのような最先端技術を使った訳ではなくw、泥臭い方法でやった。単に、名前の最後の単語が姓だとみなしている。なお、演奏者名を作曲者であるかを調べるための「作曲者リスト」には姓は大文字で記載されているので、それと組み合わせればもっと精度を上げられそうだが、今はやっていない(そもそも、姓が複数の単語ということはあるのか?※ "="で繋がっている人はそう?)

読み返していて、問題に気付いてしまった。作曲者が最初の演奏者になっていなかったら、この機能は起動しない。しかも、この場合は作曲者が分からないから、本当にAIが要りそうだ(実際にはDBでいいが)・・・ やっぱり止めとけば良かったなw まあ、Spotifyのアプリだと作曲者が見られるので、どうにかして、それを取り出せればいいとは思う。

(13:32追記) が、そうは問屋が卸さなかった。仮に、作曲者がない時は検索などをして出すとすると、ポップ音楽にも付いてしまうことになって、それはかなりイタい。ポップスには付けないようにするには、曲のジャンルを正確に知る必要があって、やっぱりAIの出番?w ちょっと思い付いた「名案」は、実際にはなかなかうまく行かない(うまく行くようにすると本末転倒になってしまうこともある)ってのは良くあることだが、これもそうだった。この件は、今の「ちょっと残念」な仕様が一番いいようだ・・・

(14:25追記) ※かなり脱線するが、「姓は必ず一語か」という件は、きっと違うだろう。この機能の主な対象にしている欧米のクラシック音楽作曲家なら、その確率は高いだろうが、そんな決まりはないはずだ。今、作曲家リストを見たら、「ヴォーン・ウィリアムズ」(Vaughan Williams)は姓であることが分かって愕然とした(さあ、どうしよう)。他にも、リムスキー=コルサコフもそうだし(作曲家リストでは"-"で繋がっているので、こちらは問題にならなそうだ)、作曲家ではないが、カラヤンの"von"は姓の一部なのかも知れない。姓がない地域もあるし、逆に長い姓を使うところだってあるだろう。日本だって、姓は複数の単語が空白なしで繋がっている場合があると考えることもできる。そういう余計なことを考えるのも、結構おもしろい。

次に、既に作曲者名が曲名やアルバム名に入っていたら(例: "Mozart: Piano Concerto No.21")、改めて追加するのは無駄なので、それを検出するようにした。そして、どちらにも入っていなかったら、曲名の頭に"Mozart: "のように付ける。

苦労したのは、名前に言語特有の特殊な文字(例: ドヴォルザーク: "Dvořák"。そういう文字を一般的に何というのか不明)の記述の仕方がいろいろあって、検索がうまく行かなかったことだ。いろいろ試していたら、iconvというコマンドに、そういう文字をASCII(普通のアルファベット)に変換する機能があることが偶然分かって、使ってみたらすごくうまく行った。無事、ドヴォルザークは"Dvorak"になって、検索でマッチするようになった。

作曲者名をタイトルの前に追加

改めて書くが、このプログラムは、Pythonのような最新の言語なんて使っていない。古臭い、シェルスクリプト(bash)とTck/Tk(wish)だ。道具は(ある程度のものなら)何だっていいんですよw でも、OSがLinux(UNIX)だからできたのであって、Windowsでは決してできなかっただろうし、やる気も起こらなかっただろう。それほどWindows(Microsoft)は酷いものなのである。

更に余談だが、上のように、今は"Dvořák"のようなおかしな文字列を何も考えずに表示できているのを見ると、何とも感慨深い。昔は苦労した。フォントがないとかエンコーディングがどうのこうのとか、プログラミング言語だって、そのままではエラーになったり文字化けして処理できないとか・・・

(13:51追記) 上記の「言語特有の特殊な文字」を一般には何というのか調べたら、結論は出なかったが(おそらく「特殊文字」だろう。人名なら、多くは「ダイアクリティカルマーク」だろう)、おもしろいページ「特殊顔文字に使われている謎の文字よ、お前は一体何者なのか」を見つけた。僕はまだまだ甘ちゃんだったよ。そんな変な文字(例: "ਊ")を曲名や人名に使われたら、このプログラムは一体どうなってしまうのかと、ちょっと不安になったw

別件だが、確か上の機能の確認中に、思わぬバグに悩まされた。ある曲の情報が表示できなかった。調べたら、曲名に"が含まれていたせいだった。そればかりか、その曲には'も入っていて、かなり極悪だった。ちなみに、その曲は初めて聞いた曲だったのだが、タルティーニという人の

Violin Sonata in G Minor "Devil's Trill"

だった。まさに悪魔の仕業だったw 特にシェルスクリプトでは、同じ文字列に"と'が同時に入っていると、小手先の対処では済まないので面倒なのだが、泥臭い手法でどうにか対処した。

「悪魔のトリル」に悩まされた。

細かい話だが、どう面倒なのかとどうやったかの説明を書く:

シェルスクリプトでは文字列は"または'で囲む(例: "Amadeus Mozart")。だから、文字列の中にそのいずれかが入っている場合は、記述が面倒になる。どちらか一方なら、もう片方で囲めばいい(例: 'Piano Concerto No.26 In D Major, K.537 "CORONATION"')からいいが、今回のように両方入っていたら、「どうしましょう?!」になってしまうw

一般的には、""の中では\を前に付けて\"のようにすればいいのだが(例: "Piano Concerto No.26 In D Major, K.537 \"CORONATION\"")、それも一筋縄では行かず、\を何個も書く羽目になることがある。おまけに、シェルスクリプトでの文字列は、代入などをすると、どういうわけか\"が"に戻ったりするので(この辺りの仕組みはちゃんと調べれば分かるのかも知れないが、ちゃんとした言語ではないので、そこまでまじめに接していない)、気が抜けない。

今回は、曲名などは特定の記号に囲まれていたので、それを別の記号に変換し、更に、曲名などの中の"は別の記号に変換して、処理中に変わらないようにし、表示の直前に"に戻すようにした。我ながら大変泥臭い。きっと、もっとスマートな方法があるのだろうが、僕は分からない。そもそも、PHPで書き直そうと思っているくらいだし、そうでなくてもシェルスクリプトはプロトタイプ用とか「ちょっと作る用」の扱い、靴で言えばサンダルのようなものなので、ちゃんと動けば泥臭くてもいいと思っている。

それから、プログラムの名前を変えるなら"minispot"にしようと思ったが、調べたら既に2件あったので、"minisp"がいいかなと思っている。でも、変えるのは面倒なので、本当に変えるかは未定だ。そもそも公開するつもりがないので、何だっていい。単なる自己満足だ。

(12:33 修正・加筆、14:11 加筆など)

PS. Spotify制御ツールの規模が予想外に肥大化していた。サイズは108KB、3049行にもなっていた。まあ、現代のアプリに比べれば雀の涙、「なにそれホコリ?」程度だが、最初は軽い気持ちで作ったのに、うーむとしか言いようがない。そして、そんなシロモノがまともに動いているのだから、大したものだw なお、他に、Tcl/Tk(wish)の初期設定プログラムもあり、そちらは27KB、850行程度だった。 (14時)

  •   0
  •   1

(題は英語ではない。「力技はいいよね(いや、本当は駄目なんだけどさw)」のような意。 たまたま"Power of love"が掛かっていたので思い付いた。)

先日のSpotify制御ツールV2はその後も止まらずに進化を続けて、今日、概ね、今までの不満が解消できた(内部的にはとんでもないことになっているのだが、それでもちゃんと動いて問題なく使えているので、暫定的に良しとしている)。とりあえず、外観を。

大幅改良後のSpotify制御ツール V2 (別名: 「Spotifyミニプレーヤー」?)

もう、「Spotifyミニプレーヤー」と言ったほうが適切かも知れない(が、名前を変えるのが面倒で、そのままにしている)。いったい、前回から何を変えたのかすっかり忘れているのだが、調べてみると、以下だった。

  • 細かい見栄え(例: 行間、文字サイズ、ウインドウサイズ)の調整
  • 起動時にSpotifyアプリが起動してなかったら、自動で起動する。
  • ジャケット画像をクリックすると、Spotifyアプリを前面に表示する。
  • (リモコン経由でなくても)アイコン(ウインドウ内のボタン)を押せば、「この曲の後に停止」を設定できるようにした。
  • 曲情報欄の高さが狭いことがある問題の修正。
  • ウインドウの表示位置を起動時に指定できるようにした。
  • 「正しい演奏者名」の表示
  • 再生位置(時間)の表示

今日までは、ずっと細かい調整が主だった。そして、今日、最後の2つをなんとか実装できた。

その前に、外観(UI)について少し書く。(画像中央右辺りを)ちょっと見ると、ESPカードを思い浮かべそうだが、かなりの試行錯誤の結果だ(もちろん、苦労したから結果がいいと言うつもりは毛頭ない。駄目なら駄目で仕方ない)。この辺りは、再生状態("♪")と、「この曲の後に停止」("∥")と、音量正規化("≂", 従来は"RG"だった)のインジケーターとボタンがある。

音量正規化のボタンは、ON/OFFの区別がしやすいように色を付けていた(→ )のだが、その色が問題だった。どんな色も気に入らない(しっくり来ない)のだ。その理由は分からないのだが、ウインドウ全体がモノトーンなのに、一箇所だけ色が付いているのと、アルバムのジャケットの色とかぶったりするからかと思う。さまざまな淡色を試したのだが、これという色がなかった。が、「この曲の後に停止」をボタンにする時に、ふと気付いた。色は不要だ(黒の濃さにすればいいのだ)と。

同様に、ボタンの外観は、最終的に、画像(アイコン)ではなく、文字にした。Linuxに入っているいろいろなアイコンを試したが、これというのがなかった。作ればいいのだが、それは面倒だったので、文字を探した。Unicodeの文字コード表でさんざん探して、押した時の動作、あるいは、現在の状態を予想できそうなものにした。

意図せず林檎系の意識高さを醸し出してしまっているのが悔しいが、我ながら、まずまずだと思っている。

ついでに、曲情報欄の高さが狭いことがある問題とその解決方法について書いておく。曲情報(題名、演奏者名、アルバム名、年)は、転載する時に全部を一度にコピーしたいので、一つの領域(textウィジェット)に書いている。そして、読みやすくするために、タイトルの文字の大きさを大きくしたり、行間を増やしたりしている。各テキストを書き込んだあと、曲情報欄の高さを丁度良くするために、実際に表示されている高さを求めて設定する。ところが、文字の修飾(特に行間)は高さの計算に含まれないようで、普通に高さを求めても低くなってしまう。それが狭くなった原因だった。それを解決しようと、ちょっと高目にしようとしても、textウィジェットの高さは行数でしか設定できないので、丁度良くはできない。1行多くするといい時もあるが、高くなり過ぎる場合もある。

そこで、苦肉の策を生み出した。textウィジェットのデフォルトのフォントサイズを1px(またはpt。どちらかは不明)にしたのだ。そうすると、1行の高さは1画素程度(とにかく小さい値)になるので、高さを細かく指定できるようになる。もちろん、そのままでは読めないが、書き込む都度、本来のサイズを指定すれば良いのだ。これも一種の力技だろう。表示に使っているTck/Tkの内部のことを考えると、極小フォントに対応させるために何か無駄な処理が起こっていそうだが、とりあえず、大きな問題は起こっていないので、良しとしている。

「正しい演奏者名」の表示は、Spotifyの数少ない問題点の一つへの対処だ。どういう訳か、Spotifyがクラシックの曲の作曲者をその演奏の演奏者にしてしまうのが、ずっと気に入らなかった。例えば、モーツァルトのピアノ協奏曲の演奏者を"Wolfgang Amadeus Mozart"にしていたりするのだ。涼しい顔して! これだけは全く許せない。

さっき思ったのだが、SpotifyのDBには「作曲者」の格納領域(フィールド)がないからこうなっているのかも知れない。今からでもいいから、直して欲しい!

それをどうにかしてみた。細かい話は飛ばすが、最後は力ずくでやった。まず、前回も書いた、"xesam:url"というプロパティから取得できる曲情報ページで、その曲の演奏者リストを取得してみた。当然、その最初も作曲者になっていることが多かったので、それを何とかするためにいろいろ考えたのだが、次のようにした。

演奏者が「(有名なクラシックの)作曲家」なら、無視する。

噴飯物ではあるが、まあ、他の方法(例: アルバムアーティストを使う)よりはましだと思う。そして、ある人が「(有名なクラシックの)作曲家」かどうかは、あるwebページに列挙されていた作曲家一覧からデータを作った。

道義的にどうかとは思うが、確か、データ自体には著作権はないので、法的な問題はないだろう。

正しい演奏者を調べる(推測する)手順は、以下である。

  1. その曲の曲情報ページから演奏者リストを取得する。
  2. 演奏者リストの最初の人から順に(有名なクラシックの)作曲家一覧内にあるかを調べ、あったら、その人は無視する。
  3. 最初に残った人が、その曲の「正しい演奏者」だとみなす。

この方法だと、作曲も演奏もする人(例: ラフマニノフやバーンシュタイン)が演奏した曲の結果がどうなるか恐ろしいものがある(「想定外」)のだが、それよりも、僕が普通に聴く曲(演奏)で演奏者が正しくなる確率の方が圧倒的に高いはずなので、この方式を使ってみることにした。やっぱり実装には苦労したが、以下のようにうまく動いている(赤枠内を比較すること)。

正しい演奏者名を表示するようにした。(左: 本ツールでの修正後("Richard Goode")、右: Spotifyアプリ("Ludwig van Beethoven"))

 

最後の、再生位置(時間)の表示は、一見、飾りのように思えるのだが、僕には意外に重要だ。「この曲の後に停止」を作ったのと関係があるが、例えば、曲を聴きながら何か(例: 出勤、家事)をする必要が起こった場合、残りの長さに応じて、最後まで聴くかすぐに止めるかを判断するのに必要なのである。

実装は面倒だった。しかも、大変醜くてものすごく気に入っていないのだが、曲がりなりにも動いているので、「今は良し」としている。が、いつか、問題が起こりそうなので、あとでちゃんとしたいと思っている。

何が良くないかというと、Spotifyのアプリは、Dbus(MPRIS)経由では、現在の再生位置(時間)を取得できない(いつも0が返って来る)ので、別の方法でそれを取る必要があって、その方法が汚いのである。

いろいろ調べて、Spotifyのアプリに含まれている、HTTP(web)での制御機能を使って、現在の状態(その中に、現在の再生位置(時間)も含まれている)を取得することができることが分かり、実際に取れた。が、制御ツールはシェルスクリプトなので、再生位置(時間)を更新するたびに、wgetという、webコンテンツを取得する外部コマンドを呼び出すのである。今は1秒に1回呼んでいる。それがとてもおぞましい。。。 (が、そもそも、シェルスクリプトなんて外部コマンドを呼びまくりなのだから、この程度で苦しくなったら即座に窒息してしまって生きて行けないだろうから、気にしなくていいのかも知れないw)。

その点では、本体をシェルスクリプトで書くのを止めて、PHPに移行したい気持ちもある。上の件以外にも、JSONなどの解析を全くテキトーにやっているし、大規模になったせいもあって、プログラム自体を書くのにも結構手間が掛かるので、僕としては心苦しいことだらけなのだ。PHPを使えば、HTTPでの通信は自分でできるし、外部コマンドの呼び出しはかなり減らせるし、文字列の解析・処理はお手のものだし、プログラムだってかなり書きやすくなるから、いいことずくめだ。が、今動いているものを作り直すには結構な勇気とパワーが要るので、なかなかできないだろうな・・・

てな訳で、最初や下の画像のように、プログレスバーで再生位置を表示することができた(数値(現在位置/全長)でも表示したいが、標準の機能ではできないし、今は疲れてしまったので、あとでやりたい)。めでたしめでたし。

再生位置はちゃんと合っているよ。

再生位置の数値も入れられた。ただし、文字の背景を透過にするのは面倒なのでやっていない。そこがちょっと不満ではあるが、まあいいことにする。

再生位置(時間)の数値も入った。

余談: 「ゴールデン・ハーフでーす」って題は今でも古く感じない(今の若い人も言いそう)のだが、彼女たちが先進的だったのか、まあ世の中なんてそんなものなのだろうか?w そもそも、当時、こんなふざけた題のレコードなんて出して、風当たりがすごくなかったのか、ちょっと心配になるw

いろいろ調べたら、丁度いいプログラム(リンク先の"Based on frame and label"の"a progress meter")が見つかり、ちょっと改造して使ってみたら、すごくいい感じになった。

再生位置(時間)の文字の背景を透過にできた!

それにしても、そのプログラムも「力技」でやっているのだが、ほんのちょっとしたものなのにすごく良く働くので、感心している。 (6/17 19:55)

 

(6/17 8:06 加筆・修正, 10:37 再生位置の数値を入れられた件を追記, 19:55 再生位置の文字の背景を透過にできた件を追記)

  •   0
  •   0