Archive for the ‘Linux’ Category

先日、母がモーツァルトの曲を聴いてみたい※というので、CD-Rに焼いた。手持ちのは仕舞ってあるだけなので、最初は実物を貸そうと思っていたのだが、手荒に扱われると嫌だし、母にしたって気軽に扱える方が良さそうだからとバックアップした。

※「聴いてみたい」と言ったって、音楽の話題になった時に、僕が「CDがいっぱいあるから貸そうか」と言ったからで、あとで帰省したら、送った時の袋に入ったまま放置されているのを見てがっかりするような気がするので、(送料だサイズだで)結構苦労して梱包している時に「僕は何を無駄なことをしているんだ」と思った。が、万に一つでも聴かれる可能性も捨てきれない。が、例え聴かれたとしても、感想は例によって「すごいね。良く指が動くね。楽譜見ないで良く弾けるね」程度なので、やっぱり労には合わないだろう。とはいえ、それでも聴いてもらうのは悪いことではない。もしかしたら、母がモーツァルトの良さに目覚める可能性も0ではないから・・・

ちなみに、モーツァルトや(どうしてか、)日本人の有名なピアニストの話題が発端だったので、以下の曲の入っているアルバムにした。予想では、アイネ・クライネが(一番ポピュラーなので、)一番受ける気がしている。僕としては、もちろんK. 488を推すのだがw

    • 内田: ピアノ・ソナタ集 (K. 333, 545など) (1984-1986)
    • ポリーニ: ピアノ協奏曲 第23番 (K. 488) (1976)
    • ベーム: アイネ・クライネ・ナハトムジーク (1977)

一応、焼いたものが(ちゃんと「普通のCD」になっているか不安があるので)再生できることを確認しようとしたのだが、いざとなると、なかなかいいプレーヤーがない(そもそも、「今、PCでCDを再生する人なんて居るのかっ?」てくらいだw)。CDプレーヤーなんて随分昔から持ってないし、手持ちのラジカセではCDは再生できないし、Linuxに標準で入っていたSMPlayerはバッファリング中は再生が停まるから曲間が余計に開くし、MediaPlayerは動画専用のようだし、(全く問題ないだろうと思っていた)VLCはなぜか音が途切れることがある。参照用とか予備で入れているClementineは、いつもながらイマイチだった(もう消そうかな)。そして、いつも使っているgmusicbrowserではCDは再生できない。

前回別件で焼いた時は、MPlayerとカーナビのオーディオで試した覚えがあるが、さすがに車は面倒だ。そこで、検索していくつかのアプリを試してみた。以下にその一覧と評価(CD再生に関してのみ)を書く。

  • △ DeaDbeef: 開始する時に頭が飛ぶことあり。
  • △ Audacious: UI・操作が若干煩雑。
  • △- Quod Libet: UIがイマイチ。ジャンプが簡単にできない。
  • × Aqualung: 2ウインドウで煩雑。UIがイマイチで使いにくい。CDが高速で回転してうるさい。
  • △- Banshee: 古い(2011)。ジャンプがイマイチ。
  • × Rhythmbox: 大掛かり。CDがCDDBに見つからないと、いちいちメッセージを出して鬱陶しい。再生が手軽でない(いちいちキューに追加する必要あり)。
  • × Exaile, JuK, Kaffeine, Amarok, Musique: 駄目・論外 (まともに動かない・すごく使いにくいなど)

結局、AudaciousかDeaDbeefが良さそうなので、Audaciousで確認し、その二つを残した。でも、次はいつ使うことか? (万が一、母が「別の曲も聴きたい」と言って来たら喜んで焼くが、まずないだろうな・・・ ただ、文中に2回出て来た「1万分の1」を合わせると、確か1億分の1だから、宝くじに当たるようなものだw)

  •   0
  •   0

先日作った、Androidスマフォの画像をLinuxPCにWi-Fiで取り込むプログラム(システム)だが、その後、使ったり試行錯誤したり考えたりしているうちにいろいろアイデアが浮かんで、(まだ細かい確認・調整点はあるものの)最初の要望どおり、以下のようにできた。

スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる

それまで難しいと思っていたのは、元々の要望の重要な点とか使い方とか全体としての流れを整理し切れていなかったからだと思う。

僕の使い方と期待する動作を整理すると、以下のようになる。

  1. 外でスマフォで撮影したり画面をキャプチャして帰宅したら、それほど待たずに(家のWi-Fiに繋がった頃に)PCに画像が取り込まれている。
  2. 家でスマフォで撮影や画面をキャプチャしたあと、そのまま置いておけば(それほど待たずに)PCに画像が取り込まれている。

1は既に前回できた(Wi-Fiの再接続を契機に転送を開始する)。2は、前回はいつ転送(するかどうかのチェック)を始めればいいかの判断をすればいいのか分からなかった。そこで、更に具体的に使い方の流れを考えると、以下になる。

  1. スマフォで撮影やキャプチャする。
  2. 画面をoffにする。

そして、画面がoffになった(→ スマフォがアイドル(使っていない)状態になった)のを契機に処理を開始すれば良いことに気付き、実装した。かなり手こずったが、概ねうまく動くようになった。処理の流れの概要は以下である。

  • スマフォ
    1. スマフォがアイドル状態になったことを検知する。
      1. 画面がoffになるのを待つ。
      2. 数分後(例: 5分)にタイマーがイベントを出すように設定する。
    2. タイマーイベントを待つ。
    3. 前回の転送終了時刻より新しいファイルを探す。
    4. 新しいファイルがあれば、PCに転送開始要求を出す。
  • PC: スマフォから新しいファイルを取得する。

以下に難しかったことを書く。

アイドル(スマフォを使っていない)状態の検出

画面がoffになってすぐ転送を行うと、例えば、画面のタイムアウトで暗くなったなどで、また画面をonにして使い出して画像を追加する可能性があるから無駄である(無意味ではないが、まだ作業が終わっていないものを転送する可能性があるし、新規ファイルのチェックや転送(通信)の回数はなるべく減らす方が良い)。そこで、スマフォがアイドル状態であることを検知して転送を行うことにした。

アイドル状態は、一定時間(例: 5分間)画面がoffになっていることで判定するようにした。また、その時間より早く画面がonになったら、アイドル状態でないとして処理を打ち切る(「なかったこと」にする)。具体的には、画面がoffになった時にタイマーを設定し、タイマーの期限が来たらアイドルとし、それより前に画面がonになったら、(アイドルでないとして)タイマーを解除する。

なお、スリープ中はSSHDroidがうまく動かない(スマフォが完全にスリープしている訳ではないが、SSHDroidがスリープしているようだ)ので、スリープを解除するために画面をonにするのだが、その後の画面offもアイドルの開始と判定してしまう問題があるので、自分で画面をonにした場合には少しの間(例: 30秒間)画面offを無視するようにした。なお、なぜか、自分(このプログラム)で画面をonにした場合には、画面onのイベントは起こらないようだ(将来問題になりそうなので、再確認が要りそうだ)。

「前回の転送終了時刻」の取得

スマフォはPCに(「新しいファイルがあるよ」と)転送開始要求を出すだけで、実際の転送はPCが行うため、PCが本当にファイルを取得したか・できたかは基本的には分からない。しかし、転送に使っているrsyncコマンドはリモート(この場合、スマフォ)に転送のログを書くことができるので、その機能を使うことにした(これは邪道なやり方なのだが、一応、rsyncの機能しか使っていないので、許すことにした)。転送が成功しているとすれば、ログの更新時刻=転送終了時刻なので、新規ファイルの検索に手軽に使える(転送中に画像を作成するなどして食い違いが生じる可能性もあるが、その前にアイドル(放置)状態であることを確認しているので、余りなさそうだ)。

なお、ログから転送が成功したかどうかの判定をして、失敗していたら適切に処理すべきだが、今はいつも成功したとみなしている。そのため、何らかの原因でエラーが起こった場合、転送アイコンを押して(手動で)取得する必要がある。 → ログ中のエラーから失敗を判定する処理を追加した。失敗した場合、下記のログファイルの削除を行わないようにすることで、次回も今回と同じファイルから転送する。ただ、それでうまくいくかは疑問で、通知などが要る気がする。 (3/10 7:20)

また、rsyncのログファイルは毎回追記されるので、サイズが増大するのを防ぐため、転送開始要求を出す前に削除(実際にはrename)している。

 

以上により、基本的には、定期的な新規ファイルのチェックが不要になった(一応、保険として1時間に1回するようにはしている。ただ、アイコンを押せば手動でできるので、そこまでする必要はないのだが・・・ ← 忘れていたが、自動転送要求する時にPCが起動していなかった場合のリトライ用に有用だった(3/10 14:46))。それに加え、前回追加した、PCから最新のファイル名を取得する処理(通信)も不要になり(= 再び転送開始要求だけになった)、電池消費量が(更に?)減ったはずで※、なかなか気分がいい。

※ 8時間のアイドル時の消費電力量は0.4%/hだった。これは先日できたWi-Fiの再接続処理の低い時と同じ値なので、このプログラムの待ち受け時の消費電力は無視できる程度と考えられる。 (3/10 7:29)

そして、結果的にスマフォの転送開始アイコンもPCの状態表示ウインドウも不要になってしまった(後者は、使用中に勝手に出ると邪魔なので、エラー発生時以外は出さないようにしているため)。

 

作った画像転送システムを実際に使っていると、今までは余り興味がなくて魅力を感じていなかった無線や非接触通信がかなり便利に感じる。ケーブルをつながなくていいから手間が省けるし、机の周りがごちゃごちゃしなくて済む(でも、イヤフォンは御免だw)。それで、デジカメの画像もWi-Fiで取り込みたい気分が起こって来た。ちょっと調べたら、FlashAirがなかなかおもしろそうだ。ただ、電池消費量が増えるという情報があるし、そもそもそこまでする必要があるのか(スマフォはあるものでできたから手軽に始められたけど、デジカメだと追加の物が要るのでお金が掛かる)甚だ疑問なので、良く考えたい。

あと、スマフォの充電も非接触にして可能な限りケーブルを排除したいのだが、本体が対応していないので無理そうだ(これもいろいろあるんだろうけど・・・)。

 

PS. 少し話が飛ぶが、日本のメーカーは、ユーザーの要望の真意とか実際に使う手順とかをちゃんと見極めずに、「できるから」、「高機能なら売れる」と思い込んで作り込んでしまったために、機能はてんこ盛りだけど使えない家電とかばかりになってしまったのではないだろうか。挙句の果てに、高いうえに使いにくいから売れずに海外のライバルに負けてしまったという、踏んだり蹴ったり状態だ・・・

PS2. (節操なく宗旨替えするようだがw、)この無線・非接触の時代に、USBは4なんてやり出して、全く理解できない。まあ、あってもいいけど、そこまで高速なのが要るのだろうか。それより、昔諦めたWireless USBを復活させればいいと思うのに。ただ、あれ自体はUWBを使うなんて先進的過ぎて失敗したので、もっと「普通に」やればいいと思うが、そうできないからああなったのだろうか? だったらWi-Fiとかを使えばいいってことだろうか?

(3/10 7:58 加筆・修正)

  •   0
  •   0

ずっとやりたかったけど、面倒で見送っていたことができた。スマフォなどのケーブルが何本も(充電用とPC接続用、他にデジカメ用も)あって見苦しいし、注意しないと間違えるのが嫌になったのだ。しかも、スマフォをPCに繋いでも、いちいち画面で画像転送(PTP)を選ぶ必要がある※のも、イライラを増していた。

※検索すると、この選択は開発者ツールを使えば固定できるようなのだが、なぜか、再起動か何かのたびにリセットされて、いつも選ぶ羽目になっていた。AQUOSの仕様なのだろうか?

やりたかったのは以下のようなことだ。

  • スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる。
  • USBで繋いだ時と全く同じように取り込まれる。
    • 新規画像(例: 前回の取り込み以降に撮影されたもの)画像だけが取り込まれる。
    • 画像は年月日ごとのディレクトリ(例: 2019/2019_01-03/2019_03_04)に仕訳けされる。
    • 画像のファイル名にはカメラ(スマフォ)・トップディレクトリ(例: DCIM/102SHARP)固有のIDが追加される(例: DSC_0301_2345987612.JPG)。
      • カメラ間・カメラ内のファイル名の競合を防ぐため。
    • ファイルの更新時刻が撮影時刻になる。
      • PNGなど、タグのないファイルでも並び順を揃えたいので。
    • 新しい画像であることを示すタグ(例: Subject="New")が付く。
      • ファイルを自動で仕訳けするために画像の場所が分散するので、あちこち探さなくても一目で新規画像を分かるようにするため。

そして、なぜか数日前(調べたら、3/2からだった。簡単にできそうなアイデア(後述の、マウントしてtarコマンドでコピー)が浮かんだので始めたのだった。本当に、「寝食を忘れて」熱中・集中していたので、結構疲れた)からやる気が出て実装し、以下のような感じで動くようになった。

  • スマフォをPCに繋がなくても、スマフォのアイコン(実体はウィジェット)を押すとPCに画像が取り込まれる。
  • USBで繋いだ時と全く同じように取り込まれる。

上に書いたように、操作なしにしたかったのだが、いくつかの問題があるので、今は保留している。 (→ その後改良して、概ね操作なしでできるようになった。: 3/9 12:09)

  • 使っているサーバソフト(SSHDroid)の仕様なのか、画面offの状態では、そのサーバが停止(スリープ?)するために、PCから接続できない。接続していても、画面offになってしばらくすると切れる。
    • → サーバを起動するために画面をonにするのなら、ロック解除してアイコンを押すのはそれほど手間ではない。
  • 仮に常時接続できるようにしても、定期的にPCから新規画像のチェックをするのは効率が悪い(画像が増えることはそれほど頻繁でないので)。頻繁にチェックすると電池を食うし、チェック間隔を長くすると不便だ。
    • → 画像が増えたら、スマフォがPCに通知するようにすれば良さそう。[今後の課題]

なお、PCからも取り込みを開始することができるのだが(最初はそうした)、上記のように、取り込み前に自分でスマフォの画面をonにする必要があるから余り便利でないことに気付き、スマフォから開始できるようにした。

スマフォとPCの画面が写った動画でないと全くおもしろくない(さすがに撮影する気は起こらないw)のだが、以下のように、スマフォのエクスポート(あるいはアップロード・同期)アイコンを押すと、PCで取り込みプログラムが起動し、取り込みウインドウに取り込みの経過が表示され、新規画像が取り込まれる。自画自賛だが、なかなか便利だ。例えば、スマフォで撮影したらアイコンを押すだけでPCに入れられるのはすごくいい(今までだったら、ケーブルを繋ぐかDropboxに入れるなど、結構面倒だった)。今気付いたが、家の中ならどこにいても転送できるはずだ(それに価値があるかは別としてw)。

こういうアプリなり仕組みは既にあるが、いろいろ探してもどうも僕の要望には今ひとつ合わないので(同様な理由でUSBでの取り込みプログラムも自分で作ったので、まず合いようがない)、自分で作った。あと、今はスマフォからクラウドに直接自動的にアップロードするのが主流だが、やっぱり使いにくいし、モバイルデータ量も増大するかも知れないし、そもそも、提供者の都合で仕様が変わったり有料になったり終了になる可能性があるので、なるべく使わないことにしている。

と、さらっと書いたが、中ではなかなかいろいろなことをやっているので、以下に細かい話を書く。

スマフォからの画像取り込み

基本的には、今までのUSB(PTP)での画像取り込みプログラム(の枠とでもいうもの)を使っている。ただ、今回のネットワーク対応ためにかなり追加・変更した箇所がある。

転送の仕組みは、最初は、sshfsなどでPCからスマフォのファイルシステムをマウントし、ファイル一覧を取得し、新規ファイルを抽出してtarコマンドでコピーすることを考えたが、rsyncコマンドの方が便利そうだったので、それを使うことにした。特に、rsyncはマウント不要(自動でスマフォ側のプログラムを起動する)なのが良かった。

スマフォのファイルシステムは大きく、毎回スキャンするのは得策でないから、PCでは新規ファイルの抽出はせず、取り込み済みファイル一覧から除外ファイル一覧を作ってrsyncに指定することにした。実際には、スマフォ内でrsyncによるスキャンは行われるが、PCからNW経由でやるよりは良さそうだ。除外ファイルサイズが大きくなって重くなるのが気になるが、今のところ、デジカメも含む全ファイル一覧(画像数: 8千以上)でさえ300KB未満なので、大きな問題はなさそうだ。

画像取り込みの開始

前述のとおり、最初はPCのプログラムで取り込みを開始するようにしたが、その前にスマフォの画面をonにする必要があって不便なので、スマフォのアイコンで開始できるようにした。

そうするにはいろいろな方法が考えられるが、手軽に作るためにAutomagicを使うことにした。Automagicで可能なのは、Wake on LANパケットの送信、HTTPアクセス、FTPアクセスなどだった。Wake on LANは手軽でいいのだが、ユーザのデータが送れないので、HTTPにしてみた。

なお、AutomagicからOSのコマンドを実行することもでき、ncコマンドもあるのだが、UDPの送信ができない(セキュリティの制限か、エラーになる)ので、諦めた。あと、そもそも、Automagicから実行できるコマンドのパスがシェルとは違っているために実行できない問題もあった。

これだけのためにPCでHTTPサーバを動かすのはもったいないので、socatコマンドで擬似的なHTTPサーバを作って待ち受けることにした。「サーバ」といってもまったく大したことはなく、「のようなもの」だ。基本的なコマンドは以下のような感じで、たった1行(長いので折り返した)で済むものだ。

echo -e "HTTP/1.0 200 OK\r\n\r\nHello!" |
  socat -d TCP-LISTEN:2345,reuseaddr - | hexdump -C

AutomagicからPCのTCPポート2345にアクセスすると(URLの例: http://192.168.1.2:2345)、PCでその要求がダンプされる(→ 要求が来たことが分かる)。また、スマフォ(Automagic)には"Hello!"という文字列が返るので、PCからの応答も分かる。

あと、ものすごく簡単な不正アクセス対策として、Automagicから要求を出す時に、ヘッダに「何か」(普通はない情報、合言葉のようなもの)を追加すると、何もしないよりはよい。そもそも、外部からのアクセスはルータで遮断されるので、外部からPCへのHTTPアクセスは来ない前提だし、PCはデスクトップなので持ち歩かないから、今はこれでいいと思う。それから、Wake on LANは間違って宅内の他の機器から出る可能性があり、ブロードキャストなので宛先で受信制限ができず、上記のようにユーザのデータは送れなくて正当性のチェックができないという点でも、HTTPの方が少し良さそうだ。

スマフォの個体の識別

前述のように、画像のファイル名にはカメラ(スマフォ)・トップディレクトリ固有のIDを追加する。そのIDは、カメラ情報(メーカー、機種、SN)から生成するのだが、当然、NW経由ではそれらは取得できない(スマフォのコマンドを使うとできるかも知れないが、仕組みを特定のOS・機種に依存させたくないので、止めた)。

そこで、スマフォのMACアドレス(HWアドレス)を使うことにした。MACアドレスはその個体に固有で変わることがないので、IDとしては良い。ただ、USBで取り込んだ時とネットワーク経由の時でIDが異なると、別の接続では取り込み済みファイル一覧が異なるため、新規ファイルが異なって、重複して取り込まれてしまうので、画像取り込み開始プログラムで、MACアドレスからUSB(PTP)で取得・生成したIDを検索して(今はプログラム中に書いている)、それを取り込みプログラムに指定するようにした。そうすれば、同じ取り込み済みファイル一覧が参照される。

MACアドレスは、次のように取得する。スマフォからのHTTPアクセスの場合、アクセスを受けたsocatは環境変数SOCAT_PEERADDRにスマフォのIPアドレスを格納するので、要求が来たらコマンドを実行するようにし、その中でIPアドレスを取得し、その後、arpコマンドでIPアドレスに対応するMACアドレスを取得するようにした。次はそのコマンド例である(まだsocatには理解できていないことがあるため、綺麗ではない。なぜか、最後の";"は必要である)。

tmp_file=/tmp/iimg-rss.d
http_resp_line='HTTP/1.0 200 OK\r\n\r\nAccepted.'
socat -T 0.7 TCP-LISTEN:2345,reuseaddr 
  SYSTEM:"/bin/echo -n -e \"\\\"${http_resp_line}\\\"; 
  (date +\"Date:\ %Y/%m/%d\ %H:%M:%S\"; 
  echo \"PeerAddr: \${SOCAT_PEERADDR}\"; 
  echo; cat ) > $tmp_file; "

スマフォから要求が来た場合、一時ファイル/tmp/iimg-rss.d中に、要求が来た時刻(Date)、スマフォのIPアドレス(PeerAddr)、要求の内容が格納されるので、適宜処理すれば良い(上述の正当性チェック用トークンも要求の内容として格納されている)。なお、これを受信した場合、スマフォには"Accepted."という文字列が返る(今はそのチェックはしていない)。

見つかった問題

実装中や試している時に見付かった問題と対処を以下に書く。

  • rsyncの除外・含めるファイル指定の謎
    • 対象ファイルの指定はなかなかの謎で、うまく使えるようにするのがとても大変だった。指定順序がかなり重要らしい。(→ 参考ページ)
  • オーディオファイル(例: MP3)、動画にはタグが付けられない。
    • exiftoolがMP3などの書き込みには対応していないうえに、タグの仕組みが異なるので、画像と同じようには処理できない。
    • → 取り込み後に画像管理アプリXnViewMPに認識させるために、新規画像一覧を指定してXnViewMPを起動しているので、取り込み時にタグが付けられなかったファイルがある場合には、そのウインドウを閉じないようにして新規ファイルが分かるようにした。
  • 時々SSHDroidが停まる。
    • Wi-Fiの鍵更新時に一瞬Wi-Fiが切れるために、SSHDroidが終了するようだ。
    • → 先日できたWi-Fiの自動再接続プログラムで、画面がoffの場合には(onの時はすぐに繋がるから、問題ないはず)SSHDroidを再起動するようにして、解決するか試している。 → 今のところ大丈夫なようだ。
  • ディレクトリ名の問題
    • rsyncと従来の取り込みプログラム間の想定の違いやAndroidで画像のあるディレクトリはDCIMだけでないなどの細かい問題があったので、逐次対応した。
  • 変なファイル名
    • 一部のファイル名に、想定外の"["や"]"が入っているものがあって、「ゲー」っとなったが、PHPにescapeshellarg()というすごい関数があることを知って、何とかなった。
  • 余計なファイル(Android下のキャッシュなど)の除外
    • 上述のrsyncの除外パターンに指定して、なんとか除外できるようになった。
  • tarはエラーをうまく返さない?
    • 普通に使う分にはちゃんと返すのだろうが、パイプで繋げた場合にはエラー状態が消滅してしまって、失敗がちゃんと分からなくて不便だった。これは、rsyncに換えた最初の理由である。

その他

今、以下のようなことを思った・思っている。

  • 転送がすごく速い。
    • USB(PTP, gphoto2)での時よりずっとキビキビしていて、速くて気分がいい。今は転送ファイル数が少ないだけかも知れないが、rsyncの処理が高速な気もする。
  • 外からの帰宅時に自動取得できると便利かも。※
    • AutomagicでWi-Fiの接続イベントが取れるので、その時にエクスポート開始すればできそうだ。これを作れば、帰宅してすこし経てば自動的に取り込まれているので、ロック解除してアイコンを押す手間すら省けて、なかなか良さそうだ。が、帰宅時にPCが起動していない可能性もあるので、そううまくは行かないことに、今気付いた。 → 外部サーバを使うといいかも知れない(大げさになってしまうが)。
  • スマフォの物理ボタンを押したら転送開始できると便利。
    • が、使えるボタンが少な過ぎて無理(音量しか使えない)。
  • デジカメでもこうしたいが、無理かも。
    • 仮にWi-Fi付きモデルだとしても、rsyncが動くとは思えない(別のファイル共有が使えれば、それに対応させれば、可能性はある)。
  • Automagicはすごく便利! もっとしゃぶり尽くしたいw
  • そして、こんな芸当(というか、Linuxでは当たり前だが)はiPhoneではまず無理だっ! (ネイティブアプリを作ればできるかも知れないけど、そんな面倒なことはしたくない)

※ その後、帰宅後の転送を操作なしにできるように、Wi-Fi接続時に自動的に画像転送を開始するようにした。PCが起動していない可能性については、開始前にpingでPCが起動しているかを確認するようにした。また、Wi-Fiの接続が安定するのを待つため、少し(例: 3分間)待つようにした。

更に、スマフォが電源に接続された時も、同様に自動で転送開始するようにした。この場合は無駄な転送になる可能性があるが、電池は消費しないので、大きな問題ではない。

なお、自動的に転送を開始する場合は、エラーがあった時以外はPCの画面に画像取り込みウインドウを出さないようにした。なるべくPCの操作を邪魔されたくないからである。これは、上記トークンと同様に、スマフォからの転送開始要求のHTTPヘッダに取り込みの動作モードを指定することで実現した。 (3/5 8:58)

その後、アイドル中(画面消灯後、約3分経過以降)はSSHDroidが停まっている(アプリがdoze状態?)ためにPCからのrsyncでのアクセスが失敗することが分かった。いろいろ試したところ、直接的にアプリを起こすことはできなかったが、画面を点灯させるとSSHDroidも動き出すことが分かったので、自動転送開始の契機がWi-Fiの接続時の場合には(電源接続時はスマフォ全体のスリープが解除されてSSHDroidも動き出すので、必要はない)、短く(1秒程度)点灯させてから転送開始するようにした。消費電力の増加が気になるので、しばらく様子を見たい。 (3/6 9:43, 13:35)

Wi-Fi接続時に自動転送したいのは帰宅時なので、長時間(例: 10分以上)Wi-Fiが切断された後に接続した時だけ転送を開始するようにして、長時間アイドル中のWi-Fi鍵の更新時に無駄に画面点灯と空の転送が実行されて電池が減るのを防ぐようにしてみた。

ソフトというのは、最初は単純なものでも、こうしていろいろ工夫・調整すると複雑になってしまう。そういうのの成れの果てがWindowsのようなものだ。なかなか加減が難しい。。。 (3/6 14:14)

更に、自動転送の場合、スマフォ内に前回PCが取り込んだ(PCに転送した)ファイルより新しいものがある時だけ転送開始要求するようにした。これで、無駄に画面が点くことはまずなくなるだろう。ただ、新規ファイルの検索と画面点灯とどちらの電池消費量が多いかは不明だ(点灯させるとスマフォ全体が起動するから、そっちの方が多いとは思うが)。

PCへの要求を送るのにHTTPを使うようにしたおかげで、スマフォからPCへの命令(前回転送したなかで最新のファイル名を取得する)を追加できたのは良かった。

これで、この件に関しては概ね気が済んだ。ただ、想定が狂って、転送開始要求の前に、前回転送した最新のファイルを取得する必要があるために転送回数が増えてしまったのは、ちょっと気に入らない。本当に必要なのか、もう少し考えてみたい。

当然ながら、プログラムは更に複雑になってしまった。 (3/7 11:53)

 

(18:52 若干加筆; 19:49 題を変更; 20:28 若干加筆; 23:42 2番目のsocatの例が誤っていたので修正)

  •   0
  •   0

先日、画像管理アプリをXnViewMPに変えた。digiKam5(以下、digiKam)は重い(起動が遅いことがある、メモリを食う(メモリリーク)、いろいろな処理(特にDB関係)が重い)のと、UIの使い勝手が微妙にイライラするうえに変更できないからだ。移行先のXnViewMPは、以前試した時に比べて大分良くなったので、移行しても問題ないと考えた。とはいえ、いくつか問題があったので対処したら(→ 投稿1, 投稿2)かなり良くなったのだが、digiKamとコメント・カテゴリの格納場所(タグ)に違いがあってちょっと不便なので、その対応をした。なかなか手間が掛かったので書く。

そもそもの問題は、digiKamとXnViewMPがコメントとカテゴリを格納・取得するタグが違うため、digiKamで付けたコメントやカテゴリがそのままではXnViewMPでは表示・書き込みできないことだ。それらの違いを以下に示す。なお、digiKamのタグは、それ以前にWindowsで使っていたACDSeeが使用する(ACDSeeで設定したか、digiKamに移行する時に設定したか)タグも含んでいる可能性が高い。

コメントのタグ

  • digiKam: UserComment, Notes, Caption-Abstract, Descriptionの全部またはいずれか
  • XnViewMP: Comment, Description(補助?)

カテゴリのタグ

  • digiKam: Keywords, Subject, Categories(階層化して格納)の全部またはいずれか
  • XnViewMP: Keywords, HierarchicalSubject(階層化して格納)

コメントについては、XnViewMPではIPTC/XMPの編集機能を使えばdigiKamと同様に書き込むことができるが、標準的な扱い(例: サムネイルの下に表示する、コメントの編集で表示・編集する)ができないので不便だ。カテゴリも、カテゴリを付けるペーンでは表示されるのだが、標準的な扱い(例: サムネイルの下に表示する)ができないので不便だ。おそらく、将来のXnViewMPではできるようになると期待する(が、いつになるかは分からない)。

digiKamは結構柔軟に使用するタグを設定できるのだが、XnViewMPはそうではないので、標準的な扱いをしようとしたら、XnViewMPが使うタグに値を入れる必要がある。そこで、digiKamのコメント・カテゴリをXnViewMPにコピーすることにした。まず、XnViewMPの機能でやろうとしたのだが、変更ができないタグが多くて無理だった。今にして思えばdigiKamでやればできたかも知れないが、そうはしなかった。というのは、既にXnViewMPに乗り換えた後だったので、「もう使いたくない」という気持ちが大きかったからだと思う(digiKamが重いのが大きな理由だ)。それに、以下に書くように、単純なコピーでは済まなかったので、digiKamでやったら手作業で間違いが多くなっただろうし、対象の画像の数が多くてかなりの時間が掛かっただろうから、使わなくて正解だったと思う。

作業の前にいろいろな画像のコメントを調べたら、digiKamの前に使っていたACDSeeのせいなのか、UserComment, Notes, Caption-Abstract, Descriptionの全部に入っている訳ではなく、どれか3つ(確か前の3者)とか1つだけ(Description)の場合があった(おそらく、DescriptionはACDSeeが付けたのではないか)。更に、元々のコメントに気付かずに(コメントがないと思って)XnViewMPでコメントを付けてしまった画像が数十枚あり、そういう画像は2つの異なるコメントが付いている状態になっていた(この移行作業をしようと思った大きな切っ掛けだ)。

そこで、以下のような処理をした(試行錯誤したので、最初から一気に分かった・した訳ではない)。

コメントの移行処理

  1. 画像にCommentがなかったら、
    • それにUserComment, Notes, Caption-Abstract, Descriptionのいずれか(digiKamのコメント)が付いていたら、最初に見付かったものをCommentにコピーする。
  2. 画像にComment(XnViewMPで付けたコメント)とdigiKamのコメントが両方付いていて、双方が異なっていたら、
    • 後者(digiKam)の後にセパレータを挟んで前者(XnViewMP)を追加(digiKamのコメントを先に付けたため)したものをCommentにする。
    • 以下に処理の例を示す(時間的順序とは逆だが、その画像の元々のCommentタグはXnViewMPのものだったので、そのようなセパレータにした)。
      • digiKamのコメント
      • --- Orig. Comment ---
      • XnViewMPのコメント

カテゴリの移行処理

  1. 画像にKeywordsがなかったら、
    • Subjectが付いていたら、Keywordsにコピーする。

カテゴリは、上記の処理以外にCategoriesに従ってHierarchicalSubjectを設定しないと完全ではないのだが、書式の変換が要るから間違う可能性があるのと、数が多い(約1.5万個)ため諦めた(数が多くても時間を掛ければ処理できるが、クラウドバックアップの変更データ量が数十GBにも及ぶため、バックアップ時間が長くなるのとしばらく料金が増えるのが嫌だった。とは言え、1か月50セント未満でしかないが)。HierarchicalSubjectを設定しなくても、カテゴリ設定ペーンやマウスオーバーでは表示できるので、(画像の下に表示するのは諦めて、)それで代替することにした。

マウスオーバーでは表示できるけど画像の下に出せないのは、単純にXnViewMPの未実装な点なので、将来はできるようになりそうな気がする。

書いたあとで、ちょっと確認しようとしてexiftoolでCategoriesを出したら、"(none)"になってしまった。いろいろ試したら、exiftoolのオプションとして、普通に"-Categories"でなく、"-XMP:Categories"や"-All:Categories"のようにグループを指定しないと駄目なようだ。理由は不明だが、仮に階層化カテゴリのコピーもやったら、多くが"(none)"になって、とんでもない処理をするところだった。危ない危ない。。。

タグの操作には主にexiftoolを使った。基本的な処理はexiftool単体(コマンド1行)でできた(ただ、上述のように処理が複雑なためにコマンド文字列がかなり長くなったので、スクリプト中で一時的なスクリプトを作り、それでexiftoolを実行するようにした)※。なお、exiftoolはsymblic linkの実体(リンク先)を処理せず、通常のファイルに変更してしまうため、あらかじめ除外した(多くの場合には、-overwrite_original_in_placeを指定すれば問題ないと思う)。

※exiftoolの機能の豊富さには驚くし便利だとは思うが、進む方向がなんか違うと思う。

処理後に、exiftoolを使う別のスクリプトで、全画像に対して移行処理ができているかの確認をした。こちらは、上記処理に不足や問題がないかの確認もしたかったので、exiftoolでタグの値を取り出して判定する別のスクリプトで行った。

※今回作ったスクリプトやexiftoolのコマンド文字列は有用ではあるが、機能が特殊なうえに、そもそもユーザー(使いたいであろう人)がほとんど居なさそうなので、例によって公開はしない。要る方がいらっしゃいましたら、お知らせ下さい。

 

PS. それにしても、なぜ同じ意味を格納するタグがこんなにあるのかと思う。ACDSeeも合わせて調べたら、以下のよう仕様になっているようだ。

コメント

  • ACDSee: Description ← digiKamへの移行時にexiftoolで書き込んだ。
  • digiKam: UserComment, Notes, Caption-Abstract, Description, ImageDescription(文字化け): ImageDescription以外は、どれかあれば使われるようだ。
  • XnViewMP: Comment, Description: Comment以外は表示できない局面がある。

カテゴリ

  • ACDSee: Categories(階層化) ← digiKamへの移行時にexiftoolで書き込んだ。
  • digiKam: Keywords, Subject, TagsList, Categories(階層化), CatalogSets(階層化)など: どれかあれば使われるようだ。
  • XnViewMP: Keywords, Subject, HierarchicalSubject(階層化): Keywords以外は表示できない局面があり、HierarchicalSubjectがないと階層が保存されない。

ACDSeeは「マイルール」でやっており(実際にはexiftoolで書き込んだのでタグは関係ないが、exiftoolを使わなくてはいけないほど、汎用性がなかった)、digiKamは節操がない感じ(設定可能なので、実際には互換性を広げるための機能だ)で、XnViewMPはちょっとズレているうえに一貫性や柔軟性がない。こういうのは不便なので、アプリごとにタグをバラバラにせずに統一して欲しい。

まあ、それでも、EXIFでタグの記録フォーマットが統一されているので、exiftoolのようなツールを使えばいくらでも変換できるから助かる。これがもし、独自フォーマットのDBだったら、どうにもならない(コメントなどを移行できない → 打ち込み直し?)事態に陥ることになる。実際、ACDSeeは基本はDBだが、各ファイルのタグに書き込むことも可能で(これがあって助かった)、digiKamに移る時に全部に書き込んだ覚えがある。 ← すっかり忘れていたが、実際にはexiftoolで書き込んでいた

  •   0
  •   0

以前からやっている、PHPを最新版に更新する件。デスクトップPCは問題なくできたのだが、サーバが結構面倒なことになった。

PHP自体は、PPAを使えば比較的容易に更新できるのだが、PHPを使っているソフトの互換性も確認する必要がある。それで、仕様などを調べて、大体は問題なさそうだったのだが、一つ、カレンダーや住所録の共有・同期に使っているサーバソフトBが怪しいことが分かった。検索すると、少し前のPHPのバージョンからいろいろな問題が出ていたようだし、そもそも開発が終わってしまっていて、ずっと更新されていなかった。それでも使い続けたい人がパッチを出しては居るのだが、さすがにもう「騙し騙し」でも使えない、誤魔化しが効かない状態になった。

仕方ないので、別のサーバソフトを調べていくつか試したのだが、なかなかいいものがなかった。以前使っていたOなら実績があるのだが、どうも下火なようだし、その分家(クーデター版?)Nはあるが、O同様にインストールや保守がちょっと面倒そうなので、もうちょっと楽なのを探したのだが、やっぱりない感じだ。インストールがやけに面倒だったり、インストールしてもうまく動かなかったりするものばかりだった。

仕方ないのでNを使うことにした。やっぱりいろいろ面倒だったが(この中で、前に書いたSnapの問題が発覚した)、デスクトップPCでうまく動くようになったので、今朝からサーバに入れて実際に使って試している。ところが、スマフォ(Android)側同期アプリCとの相性が今ひとつで、スケジュールがうまく同期できないことが多い。確かにそのアプリは、以前から最初はうまく同期できないのだが、時間が経つとなぜかできるようになっていた。これももう駄目と考えて、別のを探すことにした。

同期アプリもなかなかいいものがなく、以前試して止めたソフトの後継のDしかまともに動かなかった。これは同期はちゃんとできるからいいのだが、なぜか、スマフォのアラームを停めても1分後に再度出ることがあるのが嫌だ。どうも、PC側でもアラームを停める場合、停める順序やタイミングが関係しているようだ。気に入らないのだが、ないものは仕方ないので我慢することにした。

影響の連鎖

サーバ [PHP → カレンダー・住所録サーバ*] → スマフォ [カレンダー・住所録同期アプリ*]

※PHPの更新のために、*を取っ替え引っ替えする羽目に。

ただ、どうにも諦められないので、また元のCを試したい気もしている。理由は分からないが、気長に一晩くらい置くといいのかも知れない。

(1/25 6:24) なんとか、アプリCで同期出来るようになった感じだ。どうも、最初は予定(データ)の量が多くて全部同期できていなかったようなので(バッファサイズに制限があるのか、1回の転送量や処理量を制限しているのかと推測した)、1度に同期する期間を短くし(例: 過去は1週間、先は4週間)、短い間隔(10分など)で同期するようにして30分くらい待ったら、遠い過去・将来はいざ知らず、直近の予定は全部同期できた(その後、設定を普通に戻した)。これで様子を見てみたい。

 

最後にちょっと意見を書くと、世の中に良くある、古いソフトが更新・刷新できないというのは、こういう風に、そのソフトが使っているソフト(多くはプログラミング言語、あるいはOS)のバージョン間の互換性のなさが原因になっていることが多い。ソフトを作った人が居なくなり、仕様書・設計書などがなかったりすると、動くかどうかも、どう確認すればいいかも、どうやって直していいかも分からない。もちろん、お金(作業時間)だってない。

だから、「動いているからそのままにしよう」という気持ちは分かるが、重要な用途で、サポートが終わったものを使い続けるのは無責任だ。例えば、過去のバージョンに不具合があって、それが原因で間違った結果になることがあるからだ(でも、その不具合も含めて仕様として作っている場合もあるので、話は単純ではない)。一方、作る方にも責任はあって、バージョンを上げる時に、従来のプログラムが可能な限りそのまま使える(動く)ようにするべきなのだ。

個人的な印象だが、PHPは随分いい方だが、Pythonのように、2つのバージョン(2.*と3.*)がずっと混在して使われている(Ubuntuですらそうだ)のは、(僕は何が違うかは知らないが)余りにも醜悪だと思う。実際、Pythonのプログラムで、「これは(2と3の)どっちで動かすのか?」と疑問に思うけど分からないので、両方試さざるを得ないことが結構ある(両方とも別の原因で動かないことも多い)。そして、Ubuntuのように重要なところでPythonを使っている場合は、片方を削除するとシステムがまともに動かなくなってしまうことすらある。時間もストレージも無駄だ。まったく、「何考えて作ったの?」と言いたい。まあ、「使う方はちゃんと更新しろよ。こっちはお前らのために良くしてるんだからさあ」って論理だろうが、使う方は作る側と違って、その言語を使うこと自体が仕事ではないので、それは全然通らない。

 

※個人情報を扱うサーバに関することで、興味本意で攻撃される可能性を減らしたいので、具体的なプロトコルやソフトの名前などは記載していません。読んでも余り役に立たないかも知れませんが、僕のメモとか、問題の原因の推測・対処の例としたいと思います。

  •   0
  •   0

あるソフトをインストールしようとして調べたら、通常の手順でするもの以外にSnap版(必要なものが全部まとまっているパッケージ)もあった。そのソフトはいくつかの別なソフトを使うため、インストールと設定がなかなか面倒なので、Snapなら全部一括してインストールできて、ほとんど設定しなくて済むうえに更新も自動でされて便利なので、試してみたのだが、最終的には止めた。Snapのセンスの悪さ・将来性のなさを実感したからだ。

まず、Snap版アプリをいくつか使っている際の、Snapのものだけを抽出したマウント(OSへのファイルシステムの登録)状態を見て欲しい。

$ df | grep snap | sort
/dev/loop0 91648 91648 0 100% /snap/core/6034
/dev/loop1 91648 91648 0 100% /snap/core/6130
/dev/loop2 90368 90368 0 100% /snap/core/5897
/dev/loop3 177536 177536 0 100% /snap/spotify/26
/dev/loop4 177792 177792 0 100% /snap/spotify/28
/dev/loop5 55040 55040 0 100% /snap/core18/536
/dev/loop6 35456 35456 0 100% /snap/gtk-common-themes/818
/dev/loop7 173568 173568 0 100% /snap/gimp/94
/dev/loop8 178688 178688 0 100% /snap/spotify/30
/dev/loop9 173568 173568 0 100% /snap/gimp/101

Snapは、基本部分とアプリごとにそのパッケージのファイルを仮想的なファイルシステムとしてマウントするようなのだが、アプリをたった2つ(Spotifyとgimp)しか入れてないのに、10個もマウントされている。。。それぞれのソフトが更新されるたびに、これらは増えるようだ(ディレクトリの最後の数字が増えるようだ)。普通はアプリなんて山ほど入れるが、それが全部Snapになって、それぞれが何度も更新されたら、一体どうなるのだろうか。OSは問題なく動くだろうけど、人が見た時に状態が把握できなくなってしまうだろう。Snapのマウントポイントだけならいいけど、他のものが埋もれてしまって不便になるだろう(上とは反対に、Snapのものを除外して表示すればいいが、今まではいらなかったのに毎回指定すのは手間だ)。どうして、Snapのマウントポイントは1個だけ見えるように(あるいは見えないように)しようとしなかったのだろうか?

見た目だけならまだいいが、もっと深刻なのは、それぞれのSnapパッケージは、各々のアプリが自分に必要なモジュールを全部入れていることだ。仮にアプリ間で同じモジュールがあっても共有しないようなので(共有することにすると、依存性が生まれてSnapの目指すところに反するだろう)、同じライブラリが何個も格納され、同じソフト(例: HTTPサーバ, PHP)が複数動く事態になる*。そうすると、ディスクやメモリの使用量が無駄に増えるし※(Windowsと似たような事態ではないか)、CPUの負荷だって無駄に上がるだろう。

* 日常生活に例えれば、お米だけが欲しいのに、なぜか、専用の炊飯器や米びつまで一緒に買わされるようなものだ。当然、そんなの持っているのに、「持ってないかも・合わないかも知れないから」とか言って手持ちのを使わせてくれないのだ。

※ディスク使用量については、上の一覧(3列目がサイズ(KB))を見ても分かるように、各アプリの量は少なくない。Spotifyもgimpも170MBくらいのがバージョンごとに複数あるようだ(普通のパッケージなら共通のモジュールは共有されるから、全体としてはそんなに大きくならないはずだ)。いくらストレージが大きく安くなったとはいえ、アプリを入れるたび・更新のたびに浪費するなんて止めて欲しい。そして、ディスクを多く使うってことは、使用メモリだって増えるのだ。論外もいいところだ。

更に、重複したモジュールはバージョンや設定が少しずつ違うだろうから、間違いなく悪夢を生み出すだろう。確かに、手っ取り早く使い始められて楽なのだが、使っているうちに、同じモジュールを使っているはずのアプリの動作が微妙に違っていて(例えば、Snapと同様の目的のシステムのAppImage版アプリの日本語入力はそういうことがある)、困って検索して調整する羽目になるのだ。そうでなくても、何かあって設定を調整するにしても、普通の場所にはないから、いちいち調べるのが面倒だ。その設定ファイルも、同じ名前のモジュールであっても、それを含むアプリごとに別だから、それぞれを調整する羽目になって、面倒臭いとしか言いようがない。。。 要は、Linuxの良さをぶち壊しにして、Windowsへの道を進んでいるのだが、それでいいのか??

先のことを考えず無駄ばかりの(「腐った」)システムなんて、全く許容できない。だから、通常のパッケージがあるなら、多少面倒でもなるべくSnap版は使わないことにした。

それにしても、そもそも、Linuxに派生が多過ぎるからSnapのような「全部入り」パッケージができたのだが、それすらAppImageとかFlatpakなどのような別物ができてしまっていて、まとまりのなさには全くがっかりだ。本来、OSの派生を減らせばこんな無駄なものは要らないのに、なぜ、そこに目をつぶるのだろうか。

Linuxにもクソなところはある(でも、クソなのは物じゃなくて人だ※)。

※クソなのは人だけど、クソな考えややり方で作られた物は、やっぱりクソになってしまう。結果は作者の属性には無関係と思うが、当然ながら、作者の考えには大きく影響される。

  •   0
  •   0

僕にしては珍しく、一週間くらい書かずにいた。ある方が入院されているので、(自分の禁を犯してw)twitterでやり取りしている。その流れで細かい投稿をそっちにしていたら、こっちに書かなくても満足できていたようだ。何もしていなかった訳ではなく、以下のようなことをやっていたので、詳しくは追って書きたい。

  • 画像管理アプリのdigiKam5からXnViewMPへの移行
    • digiKamに移った時と同様、コメントとカテゴリ(メタデータ)を引き継ぐ(普通に表示できるようにする)のがかなりの手間と苦労だった。 (→ 投稿)
    • ちょっとした(でも面倒な)残件と謎があるものの、概ね終わった。
    • XnViewMPは軽くていい。が、将来もまた何かに移りそうだw
    • それでも、データ仕様(EXIF)がオープンなので、(Linuxなら)ツールを使ったりスクリプトを作ったりすれば、いくらでも移行できるのがいい。
    • ついでに、過去にし忘れていた画像のカテゴリ分け(タグ付け)もした。そのために更新ファイルが増えて、オンラインバックアップのデータ量が半端ないw
    • ただ、オンラインバックアップの履歴保存のおかげで、XnViewMPで気づかずに上書きしてしまって失われたコメントを復活できたのは良かった。ちゃんと過去の版がリストアできることが分かった。
      • 履歴は頻繁に使うものではないが、いざという時には便利だ。今は3か月までにしているが、1年くらい残すといいかも知れない(お金次第ではある)。
      • ただ、復活させたコメントはどれも大したものではなく、「そこまで頑張る意味あった?」というオチではあったw
  • スマフォの地図アプリのデータ量と電池消費率の最適探し (→ 投稿)
    • 概ね結論が出た。「いつもNAVI」がいい感じだ。ただ、電池消費率はもう少し詰めたい。
  • 生活費の削減方法の検討 (→ 投稿)
    • とりあえず、10-12万円/年(約1万円/月)の削減が目標。手段は分かり、意外に簡単そうだが、実行は難しそう。
    • 更に、年間数十万円減らす策もあるのだが、結構な手間が掛かる。
  • 大掃除 (まだ残りありw)
    • TODOの作成日を見たら、随分長ーーく掃除してなかったのだが、本当なのか? 確かに、あの埃の量はそうだったかも・・・
  • (昔の写真を整理していて思い出した)白黒画像のカラー化手法がすごい。
    • 以前にも書いたが、画像によってはすごく自然にできる。
    • どうやっているのか興味はあるが、(論文を読んで)調べる気は起こらないw
  • 地図アプリの評価にヨドバシへ散歩して
    • 有機ELテレビが紙のように薄くて感動した。「買いますか?」→「まさか!」だけどねw
      • 技術バカの極地と言えよう。気持ちは分かるけど、ほとんど意味がない。
    • (naokiさんに教えて頂いた、)無制限Wi-Fi(ポケットルータ)は大体約5千円/月で手頃だが、3日で10GBの制限が惜しい。あと、電話が使えなさそうなのも惜しい。光回線をなくせるのはもう少し先だ。
    • (モバイルデータ量をケチるために試した、)ヨドバシの無料Wi-Fiが使えなかった。いくらやっても、認証だの証明書だのの文句を言われてwebが見られなかった。プロキシのせい? 全く惜しい。

並べてみると大したことではなく、先進性も生産性のかけらもないが、いろいろおもしろくやって、いい暇つぶしではあった。この調子で50年くらい一気に過ぎると、いいかも知れないw

  •   0
  •   0

先日書いたように、XnViewMPでは日本語入力ができず、OSやlibsslのバージョンによってはウインドウ内のGoogle mapsの地図表示もできない場合があるので、それぞれできるようにしたので書く。なお、XnViewMPのバージョンは0.92を、OSはLinux Mint 18.3 (x86 64bit)を想定する(Ubuntu 16.04 LTSでも同様と思われる)。

日本語入力

現象: コメントなどの入力フィールドで日本語(全/半)キーを押しても、Mozcなどの日本語変換モジュールが起動しない。

原因: XnViewMP添付のライブラリ(/opt/XnView/lib)にQt5の日本語入力関連のプラグイン(例えば/usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts下にあるもの)が不足しているため。

対処: XnViewMPが不足するライブラリを参照できるようにする。

詳細

  • 基本的には、環境変数QT_PLUGIN_PATHにQt5の日本語入力関連のプラグインのディレクトリを追加すればいい。
  • しかし、/usr/bin/xnview(シェルスクリプト)の中でQT_PLUGIN_PATHに/opt/XnView/libを指定(上書き)しているので、単に設定するだけでは有効にならない。
  • そのため、QT_PLUGIN_PATHにOS本来のディレクトリとXnViewMPのディレクトリを設定するようなスクリプトを作るか、xnviewを修正すれば良い。
  • XnViewMPを起動するスクリプト例:

#!/bin/sh

export LD_LIBRARY_PATH=/opt/XnView/lib

export QT_PLUGIN_PATH="/usr/lib/x86_64-linux-gnu/qt5/plugins:\
/opt/XnView/lib"

/opt/XnView/XnView $*

  • 未確認だが、使われていないスクリプト/opt/XnView/xnview.shは設定済みのQT_PLUGIN_PATHを参照するので、それを使えばいいかも知れない(XnViewMPのディレクトリが前に来るので、駄目かも知れない)。

地図表示

現象: 位置(GPS)情報付き画像を選択し、GPSのペーンを開いても、空白のまま地図が出ない(出ることもある)。

原因: XnViewMP添付のライブラリ(/opt/XnView/lib)のQt5は古いSSLライブラリ(libssl1.0.0)を参照しているようで(→ 参照)、新しいOSやPHP 7.3をインストールしたシステムなどでは、libssl1.1がインストールされているためにlibssl1.0.0を参照できないことが多いために、地図表示が不安定になる。なお、システムにはlibssl1.0.0もインストールされているのだが、参照できない(できることもある)理由は分からない。

対処: XnViewMPがlibssl1.0.0を参照できるようにする。

詳細

  • 基本的には、環境変数LD_LIBRARY_PATHに、libssl1.0.0のライブラリのあるディレクトリを追加すればいい。libssl1.0.0のライブラリは以下である。
    • /lib/x86_64-linux-gnu/libssl.so.1.0.0
    • /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
    • /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/*
  • libssl1.0.0だけのディレクトリになっている訳ではないため、親ディレクトリ(/lib/x86_64-linux-gnuなど)をそのまま指定するのでは指定する意味がなさそうだし、XnViewMP添付のライブラリと競合するかも知れないと考え、XnViewMPの追加ライブラリ用ディレクトリを作って、その下に参照させたいライブラリへのsym-linkを作り、そのディレクトリをLD_LIBRARY_PATHに設定した。また、上述の日本語入力用に追加するQt5のプラグインも同様にsym-linkした。
  • その他は日本語入力と同様である。
  • XnViewMP用追加ライブラリディレクトリディレクトリの準備(場所は$HOME/.local/lib/XnViewとした):

cd
mkdir -p .local/lib/XnView
cd .local/lib/XnView
ln -s /lib/x86_64-linux-gnu/lib{ssl,crypto}.so.1.0.0 .
ln -s /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/* .
mkdir qt5-plugins
cd qt5-plugins
ln -s /usr/lib/x86_64-linux-gnu/qt5/\
plugins/platforminputcontexts .
cd

  • XnViewMPを起動するスクリプト例(日本語入力対応も含む):

#!/bin/sh

export LD_LIBRARY_PATH="$HOME/.local/lib/XnView:\
/opt/XnView/lib"

export QT_PLUGIN_PATH="$LD_LIBRARY_PATH"

/opt/XnView/XnView $*

※32ビット版ではライブラリのディレクトリ名が異なる(上のx86_64i386)ので、適宜読み替えること。

動作例

(1/8 9:25 わずかに修正)

 

PS. 本題とは関係ないが、XnViewMPはかなり柔軟にレイアウトをカスタマイズできるのだが、結構惜しいところがある。例えば、ファイル・画像情報のペーンの名前と値のカラム幅が変更できないので、見やすくするには幅を広くする必要がある(そうしないと、左右のスクロールが頻発する)。試行錯誤して、情報ペーンなどをまとめて下部に置いた。本当は左右どちらかの端に置きたいが、使いにくくなってしまうので仕方ない。

筆者のXnViewMPのレイアウト

とはいえ、どうも使い勝手が悪いので、やっぱり情報ペーンなどを左右に置いてみた。結局、ありきたりなレイアウトに落ち着いた感じだ。これはdigiKamにも似ている気がするから、要は馴染みのUIを変えたくないのだろう。 (1/8 9:27)

筆者のXnViewMPのレイアウト (出戻り?版)

PS2. これはもう全くの余談だが、上の2つのキャプチャ画像、幅は同じなのに大きさが全然違って見える。錯覚なんだろうか。全く不思議だ。 (1/8 20:36)

  •   0
  •   1

PCを使っていて、気付いたら空きが半分くらい(= 約16GB使用)になっており、ブラウザをFirefoxに換えたにも関わらず、想像以上に空きメモリが減るので調べたら、Spotifyやブラウザ(Vivaldi)の他にもメモリを大量に使っているアプリがあった。昨夜に分かったのは、NixNote2とdigiKam5である。まとめるため、以前から分かっていたものも合わせて、以下に示す。

  • ChromeとVivaldi: メモリをふんだんに使う作り。
  • Spotify: メモリリーク: 長時間動かすと数GBに増え続け、全く減らない。
  • NixNote2: メモリリーク: データベースのバックアップをすると1GB以上に増えて、減らない。
  • digiKam5: メモリリーク: タグでの検索(例: タグのタブを開いて、あるタグを選択する)をすると数GB程度に増えて、減らない。

対処の方針としては、別のアプリを使うか回避策を見つけるかである。

ブラウザについては、Firefoxに移ることで緩和・軽減した。Spotifyは使用量が一定以上になったら自動で再起動するようにした。

新しく見付かったNixNote2については、データベースのバックアップは頻繁には行わない(定期的なバックアップ時のみ)ので、バックアップ後に再起動するか、(NixNote2ではバックアップせず)Windows版のEvernoteでバックアップ(エクスポート)することを考えている。

同じくdigiKam5(以下、digiKam)については、(自動で再起動するために)外部からプロセスを停めると画像やDBが壊れる可能性があるので、別のアプリとして、以前検討して止めたXnViewMPを再度試した。あれから改良されたのか、今回は結構いい感じだったのだが、いくつか問題があったので以下に示す。

XnViewMPの問題(不満な点)

  1. [済] コメントなどに日本語が入力できない。
    • Qtのライブラリの問題だったので、AppImage版digiKamと同様に追加して入力できるようにした。
    • これは、今まで採用を見送っていた最大の理由である。
  2. [TODO] 画像の日付でのフィルタリングができない(日付などでの検索は可能)。
    • 元々、画像の格納ディレクトリを年月日で分けているので、この機能はほとんど使っていなかったので、大きな問題ではない。
    • 追って、改良できるか検討したい。
  3. [済] 画像内に設定されたカテゴリの反映が自動でない。
    • 新規追加したファイルのカテゴリは、それらのファイルをXnViewMPで読み込まないと反映されない。そのため、ファイルの格納場所が分からないと、カテゴリで検索できない。
    • アプリの作りの問題なので、どうするか検討中。 → 以下のようにして対応した。 (1/7 9:17) → 問題なく動作している。 (2019/1/26 15:40記)
      • 問題となっている、「格納場所が分からない新規追加したファイル」は、自作の取り込みプログラムでカメラなどから取り込んで日付のディレクトリに振り分けたものなので、取り込んだファイル一覧を作成し、それをXnViewMPに指定して起動することで反映されるようにした。なお、既存のファイルを外部プログラムでカテゴリを変更した場合の更新は、この方法ではできない。
      • 以下のような処理のスクリプトを作成し、XnViewMPのツールバーのコマンドに登録して、そのボタンを押せば自動で取り込んだ画像を反映できるようにした。その時使っているものとは別のXnViewMPのプロセスで画像DBを更新しても、ちゃんと反映された。
        1. (画像取り込みプログラム: 取り込んだファイル一覧を作成する。 → img-list.txt)
        2. XnViewMPに一覧を指定して起動する。: xnview -filelist img-list.txt
        3. 少し待ち(0.5秒程度)、XnViewMPを最小化する。
        4. XnViewMPのDBへの反映が終わるまで待ち(余裕をみて3秒程度)、XnViewMPを終了させる。
        5. ファイル一覧を削除する。
  4. [TODO] ファイル・ディレクトリ名での除外ができない。
    • 余計なファイルやディレクトリが表示されて使い勝手が悪いので、どうするか検討中。
    • なお、ファイル名の拡張子では除外可能。
  5. [済] コメントの格納フィールド(タグ)がdigiKamと違う。
    • digiKamで書いたコメントはXnViewMPの"Edit comment"では出ず、"Edit IPTC/XMP"の"Caption"に出る。
    • ただし、サムネイル一覧のラベル("Comment")には出せる。
    • 場所は違うが見られるので大きな問題ではないが、追ってどうするか検討する。
    • → XnViewMPの認識するタグにコピーして対応した。カテゴリも同様にした。 (→ 投稿: 2019/1/26 15:40記)
  6. [済] 画像内に格納された位置情報(GPS情報)で地図が表示されない(地図ペーンが空白になる)。
    • ライブラリのバージョンの問題だったので、対応した。
      • 新しいライブラリ(libssl1.1)では廃止されたと思われる、SSL2やSSL3を使っているようだ。(このままだと、将来はGoogle mapsに接続できなくなりそうだ)
      • なお、libssl1.1はPHPの7.3への更新時にインストールした。
    • なお、外部サイト(GeoHack)での表示機能は問題なく動作する。
  7. [済] 画像回転の処理・結果がdigiKamと違う?
    • (EXIF情報だけで回転させるモードの場合、)画像を(論理的に)回転させても埋め込みサムネイルは回転しないために誤解していた。 → 埋め込みサムネイルを使わない設定にして回避した。 (1/8 9:10追記) それでも駄目な場合があるので、EXIF情報だけで回転させるのは止めた。
  8. [保留] 類似画像検索や顔認識機能がない。
    • これらの機能は使っていなかったので、大きな問題ではない。
    • なお、若干機能が違うものの、類似画像検索はあった。

探すと結構多かったのだが、重要なものについては対処できた。そして、確かに問題は多いものの、XnViewMPには以下のようなメリットがあり、それがdigiKamでは実現できずずっと不満だったので、対処に手間を掛けても移行する価値は大きいと感じた。

  • 起動が高速で操作も軽い。
  • メモリ使用量がとても小さく(起動直後は300MB以下)、使用量の増加速度が小さい。
    • なお、増える場合も減る場合もあり、増減の条件はまだ分かっていない。
    • (1/8 9:10) サムネイルをキャッシュすると、表示した画像(サムネイル)数に応じてメモリ使用量が増え続けて減ることがないようだ。そのため、キャッシュを行わないようにした。
  • 良く使うディレクトリをFavorites(お気に入り)に登録できるのが、とても便利。
  • ESCキーで画像表示が閉じるなど、使い勝手がいい。
  • ウインドウのレイアウトを柔軟にカスタマイズできる。
  • マウスホイール加速への追従性はdigiKamより良い。

なお、日本語入力とGPSの地図表示の対応方法については別途投稿する予定である。

PS. XnViewMPの一番の問題は、ドキュメントやサポートがすごく貧弱なことだ。コマンドラインオプション一覧すら出ない・存在しないし、マニュアルもヘルプもなく、使い方は、想像するかwebやwikiの少ない記述やフォーラムを見るか検索するしかない。フォーラムのlibsslの件を見る限り、不具合を報告しても直ることは少なそうだ(言ってみれば、「悪魔対応」だw)。。。 まあ、それでも他のアプリ同様、自分で何とかできるから良しとしている。

ただ、これでは本当に、物好きとかプロしか使いこなせない。基本的にはいいアプリなのだから、サポートをちゃんとすればユーザーがもっと増えると思うのに、全くもったない。 (1/7 9:33)

(19:54 わずかに加筆; 1/7 9:34 加筆・修正, 15:55 わずかに加筆, 16:03 題に追加; 1/8 9:10加筆)

  •   0
  •   1

今日は、トイレの他にもう一つうまく行った。先日、思わぬ問題が見付かって仕切り直しにした、PHPのバージョンアップである。問題は、最新版PHPをインストールするためのPPA(公式パッケージ以外のソフトを手軽にインストールできる非公式パッケージ)に、PHP以外の余計なパッケージ(→ PPAのページ下部の一覧を参照)が沢山入っていたことだった※。そのPPA(以下、ondrejのPPA)を使うのは一般的なようだが、セキュリティ上のリスクが高いように思えるので避けたかった。

※今考えると、余計に思えたものはいずれかのPHPのモジュールが依存するものなのかも知れない(だから、全部のPHPモジュールをインストールした時には余計なものがなくなるのではないか)。そうならなおさら、自分が使うモジュールに必要なものだけをインストール・更新対象にしたい。

それで、今日までは、OS(Linux Mint)を更新してそれ(公式パッケージ)に含まれるPHPに更新することを考えていたのだが、良く考えたら、最新のOSに含まれるPHPは最新ではないため、すぐにサポート期間が切れてしまうことに気付いた。以下にその関係を示す。

Linux MintとPHPのサポート期間の関係

  • Linux Mint (→ 参照)
    • 18.3(現在使っている版): 2021/4まで
    • 19.1(最新版): 2023/4まで
  • PHP (→ 参照)
    • 7.2(Linux Mint 19.1(Ubuntu 16 LTS)のパッケージで入るもの): 2020/11末まで
    • 7.3(最新版): 2021/12頭まで

OSをLinux Mint 19.1に更新するとPHPは(最新の1つ前の)7.2にできるが、それは来年終わり頃にサポート期間切れになってしまうので、また今回のような状況になる。しかも、それがOSの期限切れまでに何度も起こるので、そのたびに必要もないのにOSを更新することになって無駄だ。それで、代わりの案を考えたら、以下の2とおりになった。

  1. ondrejのPPAの中のPHPだけを抜き出して使う。
  2. 自分でPHPをビルドしてインストールする。

2の自分でビルドするのはさまざまな問題や手間がありそうなので、却下した。1の、PPAからPHPだけを抜き出して使う方法を考えたところ、以下のいくつかの方法が浮かんだ。

  1. OSの設定を調整して、ondrejのPPA中のPHP以外のものを無効にして、PHPだけがインストールできるようにする。 (→ 参考1, 参考2)
  2. ondrejのPPAからPHPだけを抜き出した、「自分のPPA」を作る。 (→ 参考1, 参考2)
  3. ondrejのPPAのサイトからPHPのパッケージファイル(deb)だけをダウンロードして、インストールする。その処理を自動化する。

1番目はPinning(aptの設定ファイル中にPinという設定を記述する)でできそうだが、間違えると、前回のように厄介なことになりそうだ。2番目は、抜き出すだけでなく、抜き出したものをパッケージにするための情報を再度作成する必要があって面倒そうだ。3番目は一見簡単で、やればできるのだが、自動処理するにはOSのパッケージのインストールの仕組みを自分で作るようなものなので、間違いやトラブルのリスクが増えそうだ。

結局、1番目(Pinning)を採用することにした。試行錯誤でシステムを壊さないように、仮想環境で試した。すると、意外にうまく行った。以下のような手順で設定すれば良い。

  1. ondrejのPPAをOSに追加する。
  2. aptの設定ファイルを修正する。(→ /etc/apt/preferences.d/ondrej-php.pref)
  3. PHP 7.3のインストールに必要な依存モジュールを調べて、上記設定ファイルに追加する。
  4. 余計なパッケージがインストール対象になっていないか確認する。

1は、検索するとすぐに出て来る方法で、例えば以下である。

sudo sh -c "export LC_ALL=C.UTF-8; \
add-apt-repository ppa:ondrej/php"

2は、参考ページを参考にして、以下のようにした。

/etc/apt/preferences.d/ondrej-php.pref:

# ondrejのPPA中の全パッケージを無効にする。
Package: *
Pin: release o=LP-PPA-ondrej-php
Pin-Priority: -1

# ondrejのPPAのPHP7.3のパッケージを有効にする。
Package: php7.3*
Pin: release o=LP-PPA-ondrej-php
# 公式パッケージがない時だけ、ondrejのPPAのパッケージを使う。

Pin-Priority: 400

# ondrejのPPAのPHP7.3が依存するパッケージだけを有効にする(下線部は自分が使うPHPのモジュールによって変わる)。
Package: libargon2* libpcre2* libsodium2* libssl1*
Pin: release o=LP-PPA-ondrej-php
# 他にパッケージがない時だけ、ondrejのPPAのパッケージを使う。

Pin-Priority: 50

なお、上のPin指定の"o="に指定する名前(提供者名)は、1の後に以下のコマンドを実行すれば確認できる。

apt-cache policy | grep -i php | grep "o="

3の追加パッケージを調べるには、必要なPHPのモジュールをaptitudeに指定して、インストールをシミュレートするモード(-sを指定)で実行する。以下にコマンドの例を示す。

sudo aptitude -s install php7.3 \
php7.3-{common,cli,cgi,curl,mbstring,wddx,\
xml,xmlreader,xmlwriter,xsl,opcache,json,\
readline,exif,posix}

上のコマンドを実行すると、依存するパッケージlibargon2-0, libpcre2-8-0, libsodium23, libssl1.1が不足していると出るので、ondrej-php.prefの3番目のPackage指定に追加する(下線部。指定にはワイルドカードが使用可能)。

4の、余計なパッケージがインストール対象でないか確認するには、apt-cacheコマンドやアップデートマネージャーを用いる。以下にapt-cacheコマンドでの確認の例を示す。

apt-cache policy | grep -i php | grep -v sury
apt-cache policy | grep -vi php | grep sury

1番目はPPAの説明が出ればOK、2番目は追加した依存パッケージのみ出ればOKである。

実際のPHPのインストールは、3のコマンドに-sを指定せずに実行すれば良い(私はインストールの前に現在のPHPをアンインストールした)。インストール後に、PHPのバージョン(php -v)やモジュール(php -m)を調べて、想定どおりならOKである。その後、既存のプログラムの動作確認や調整などを行う。

書くと長くなったが、意外に簡単にPHP 7.3に更新することができた。作業時間(事前検討などは含まず)は30分程度だった。これで、再来年の頭までは(大きな問題がない限り、)今のOSでも行けそうだ。

PS. OSをバージョンアップする際は、設定ファイルのPackageで追加したモジュール(libargon2など)はおそらくOSに含まれているだろうから、バージョンアップの前に設定を調整(php7.3*だけにする)した方が良さそうだ(バージョンアップ後でも大丈夫だと思う)。 ← その後、PHP7.3や依存モジュールのPin-Priorityを下げることで、仮に公式パッケージが出た場合やOSのバージョンアップ後には公式のものを優先させる設定にした。

(1/5 6:21 ondrej-php.prefの設定を改良)

  •   0
  •   0