dothikoのカクカクワールド2D REBOOT

プログラミングとかLinux関連(特にOSSのグラフィックツール関連)とかレトロゲームとか色々。

systemdでstopした時にpythonのfinallyが呼ばれない問題について

systemdでsystemctl stop hoge.serviceすると、基本的にSIGTERM -> SIGKILLが送られてdaemonプロセスが終了します。

しかしながら、pythonのfinally節はSIGTERMで終了した場合は呼びだされません。 そのため、pythondaemonを作った時、finallyで必ず呼ばれることを期待して記述された終了処理は呼ばれずに終わるという…

これでハメられた…まぁ具体的にはRaspberry PiのGPIOをお手軽にRPi.GPIOでadd_event_detectしていたのですが、サービス化していたので何も考えずにstopしたら、テストでRuntimeErrorを吐くようになってしまいました。

finallyでcleanup()を呼んでたので、SIGTERMで終了時は呼ばれなかった結果、プロセス終了後も握り続けているのか?こうなった

dothiko@raspberrypi:~/python/usbcamcap $ ./usbcamcap.py -p 12345 -f camsconf.json 
- GPIO pin 4 as Button, 3 as LED.
./usbcamcap.py:296: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
  gp.setup(LED, gp.OUT)
Traceback (most recent call last):
  File "./usbcamcap.py", line 439, in <module>
    camera = Camera(args.cameras, confs)
  File "./usbcamcap.py", line 204, in __init__
    self.init_gpio()
  File "./usbcamcap.py", line 298, in init_gpio
    gp.add_event_detect(BTN, gp.BOTH, callback=self._gpio_callback)  
RuntimeError: Failed to add edge detection

ちな、このusbcamcap.pyというのは自作のUSBカメラキャプチャスクリプトで、カメラを握り続けてhttpでリクエストした時に画像を送るものです。んでもってこの中で同時にGPIOでボタンを見ていて、ボタンが押されるとシャットダウンするようにしています。 普段はラズパイを監視カメラとして使い、整備・移動する時はボタンでシャットダウンして電源断という目論見です。

最近のネットカメラはゴミばかりあまり気に入ったものがなく、スマホでアプリというものばかり。それもお手軽で良いのでしょうが外部のサーバや専用アプリを必要としたりして、しかもそれがOSのバージョンに相性があったりするなど、使い勝手が実に良くない。 もはや自分的には監視カメラはラズパイで自作する他無いという感じです。

話がそれてしまいました。

ともかく、どうすれば直るのか悩みましたがあっさり諦めてリブートしました(^^;

んで調べた結果、対策は2つあって

  • serviceファイルのservice節でKillSignal=SIGINTを記述して、syetemdのシグナルを変える。
  • python側でSIGTERMを捕捉してsys.exit()を呼び出す

後者の方はsignalモジュールでSIGTERMにハンドラを付けて、その中からsys.exit()をコールするわけです。これでsys.exit()がfinallyを呼んでくれるので問題がなくなります。

以下参考用のテストプログラム

import time
import signal
import sys

def termed(signum, frame):
    print("SIGTERM!")
    sys.exit(0)

def main():
    signal.signal(signal.SIGTERM, termed)
    try:
        while True:
            print('loop')
            time.sleep(3)
    finally:
        print("CALL FINALLY")

if __name__ == '__main__':
    main()

まぁどっちでもいいんですけど、後でうっかりパターンを考えるとSIGTERMを捕捉したほうがいいかな?

ubuntu 18.04.1でapt upgradeに失敗

正確には何をしたらおかしくなったのか分かりませんが… また、実際焦っていたのでエラーメッセージなども保存していない。スミマセン。

  • まず普通のデスクトップアプリ「ソフトウェアの更新」で更新しようとした
  • しかし、幾つかファイルがダウンロードできずに更新に失敗
  • そこでサーバを日本からメインに変更(これが悪かったか?)
  • やはり失敗
  • ターミナルからapt update & apt upgrade
  • libgs9-commonのバージョンが合わないのでインストールが出来ないという内容のメッセージが出る。
  • このバージョン番号が末尾が18.04.2なのですが、何かが間違ってないっすかねぇ?
  • apt --fix-broken installしろと出たのでやってみる
  • 無駄無駄無駄ァーッ という感じでやっぱlibgs9がアカンのでダメとなる
  • 以降、apt removeもできなくなる (apt --fix-broken installしろと出続ける)

というわけで困ったのですが、検索して得た以下の情報を元にaptのステータスをいじったところナントカ治りました(汗 そのURLを貼りたいのですがこれまた失念…stackoverflowだったと思ったのですが、ubuntuフォーラムかもしれない。 ともかく。

cp /var/lib/dpkg/status /var/lib/dpkg/status.bak # 念の為、今のステータスファイルを保存
cp /var/backups/dpkg.status.*.gz /var/lib/dpkg # すべての連番ファイル圧縮バックアップがコピーされる
gunzip -d /var/lib/dpkg/dpkg.status.*.gz # バックアップを展開する。
cp -f /var/lib/dpkg/dpkg.status.n /var/lib/dpkg/status # nは任意の番号。もっとも大きい番号のが直前のようだ。
# この状態で、以前は実行不可能だったaptが実行可能になっている。

という情報を得たのでやってみたのですが、apt update->upgradeすると、結局libgs9で同じことに。 そこでふとひらめきました。

「statusファイルを復帰させたらそこでapt remove libgs9-commonする」

という。 あとバージョン番号がなんか18.04.2という、ん〜まだリリース前じゃね?みたいな雰囲気のファイルだったので、もしかしてと思い、upgradeではなくdist-upgradeにしてみました。 結局、やったことは

statusファイル復帰
↓
apt remove libgs9-common
↓
apt update
↓
apt dist-upgrade

そしたら無事終了しました! まぁ偶然サーバのほうで何か修正が入っただけかもですが(^^;

ではでは〜

100均で見かけた電子工作向きっぽい容器

昔は自作の電子工作機器を収納するといえばブルジョワ都会人ならタカチ等のちゃんとしたケース*1、田舎だとせいぜいタッパー類似の食品密閉ケースがありがちなパターンでした。

でも密閉ケースは軟質樹脂で接着もほぼ無理なら塗装もほぼ出来なかった*2んですね…

そんでもって今時は廉価で塗装も可能な硬質スチロール樹脂の容器が簡単に入手できる時代となってますね、100均のお陰で*3

そこで今回は中々良いケースを見つけてきたのでそれを紹介する記事なのでした。

今回探してきた条件は3つ

  • ユニバーサル基板+センサー類が入る大きさ
  • 透明で硬質樹脂
  • 蓋がある

まぁ、蓋はぶっちゃけ無くても良かったのですが(板を貼ってもいいし、同じトレイを2つ向かい合わせでくっつけてもよい)、あるほうが面倒でなくてありがたいですね。

まずはサナダ精工のクリアケース ミニ

f:id:dothiko:20180919232956j:plain:w320

蓋が主張し過ぎの気もしないでもないですが、逆に蓋を底面にしても良いかと思われます。

f:id:dothiko:20180919233124j:plain:w320

ユニバーサル基板*4を収納してみたところはこちら。残念ながら、「ケースを横置きで、基板を縦に入れる」には1mmほど基板が大きいので入りません。まぁ多少削るか、別タイプのユニバーサル基板を使えばいいだけですけどね。

以前はLEDライトケースにこだわって居ましたが別にコレでいいかも…あっ、LEDライトケースには電池ボックス&スイッチ付属という超大きなメリットがありますね。

次は和泉化成のクリアケース ロングです。

f:id:dothiko:20180919233602j:plain:w320

なんとこれ、蓋が一体型で可動式なのですよ〜

f:id:dothiko:20180919233629j:plain:w320

これまた、ケース横置きで基板横置きしか無理です。

f:id:dothiko:20180919233652j:plain:w320

これはもう1mmとかいうレベルではなく完全に無理ということで。まぁ、ケース自体が長いのでいかようにもなるかと。

実は前も書いたかもですが、トイレ照明(&将来的には換気扇も)のセンサー + 赤外線リモコンでの完全自動化を目論んでいまして、タカチ的なABS樹脂ケースは幾つか買い込んであるものの、貧乏性が災いして可能な限り使いたくねえっ!という感じなのでした(^^;

まぁ、センサーや赤外線LED用の窓を綺麗に四角く切り抜くのがめんどいということと、失敗とかすると無駄に穴のあいたケースになってしまったりして悲しいですからね…*5

双方ともスチロール樹脂ゆえ、塗装も接着剤も簡単に効くのはよい*6のですが、耐衝撃性に弱く多少のことで傷つきやすい割れやすい、消しゴムやそのカスが長時間ひっつくと可塑剤のガスで溶けるなどの問題点があります…そのへんを考慮して場所を選んで使えば良いかと思われます。

ではでは〜

*1:ブルジョワの特注とかは無しでおながいしますw

*2:染めQなら行けるのかなぁ?

*3:特にセリアが好きですが、これらの製品は別段セリア限定でもない模様

*4:秋月電子で売っている「片面ガラスコンポジット・ユニバーサル基板 Cタイプ」

*5:250円とかだから別にいいじゃんという感じかもだけど、秋月中毒患者としてはこの250円で他のパーツが買えるとか思ってしまうのですな

*6:なお、今時はセメダインのスーパーXやコニシのウルトラ多用途SUなどの優秀なシリコーン系接着剤もあるので、溶剤系接着剤にこだわらなければ樹脂の選択肢も広がるのですが

セリア100円LEDライトの透明化改造

お絵かき用の左手デバイスとしてテレビの赤外線リモコンを使用しておりますが、中々良いです。 応答速度がやばいほど遅いのではと危惧しておりましたが、試しに作ってみたところ、全然大丈夫。 ローコストで入手性も高く実に良いと思うのですけどねぇ

ちなみに自作受信器の中身はatmega328で受信、MCP2221でUSB-TTL通信し、PC(Linux)側では専用daemonが待ち受けてuinputでキーコードを吐く仕組みにしております。将来的にはこれをPC側のdaemon無しに単体で動くように、大昔買ったまま放置してあるトラ技の78K0オマケ基盤をUSBキーボード化して、それとatmega328が通信してUSB化するという構想なのでした。*1

まぁ普通にビットトレードワンのリモコンキットを買えば廉価かつ確実、しかもこれだけでUSBキーボードになるようです(^^)

ビット・トレード・ワン USB赤外線リモコンアドバンス ADIR01P

ビット・トレード・ワン USB赤外線リモコンアドバンス ADIR01P

が…これはリモコンボタンを押しっぱなしにしてる間、キーを押下したままにしてくれるのだろうか? 例えば、shiftキーを割り当ててそのボタンを押している間、shiftが押しっぱなしになってくれるだろうか?…という疑問が今イチ拭えなかったということも自作に走った一因です。

ちなみに自作受信器では、「同じリモコンボタンが108msぐらいの一定時間内にリピートしない、もしくはリピートコードが来なければ、ボタンを離したという事にしてuinputにキーのリリースコードを生成」という仕組みにしております。

ただ、押下状態を保持したいボタンは極少数。リピートするとパカパカして使いづらい機能のほうが圧倒的多数なのですね。 そこで一部のボタンについてのみ、設定ファイルでモデファイアフラグ「holdable」を指定することで押下状態保持を明示的に指定。 デフォルトでは、「リモコンボタンを一発押したらワンショットですぐにリリースコードを生成し、直後の同一リモコンボタンのリピートを無視する」という仕組みです。*2

ワタクシ、自分の改造版MyPaintではshiftキーを押しっぱなしでペンタブのスタイラスをドラッグするとブラシサイズを変更、という機能に割り当てているので割とキーを押しっぱなしに出来るかどうかは重要なのです。Kritaでも同じです。あとCTRL押しっぱなしでカラーピックとか、これも同じ。

しかし問題がまだひとつあって、それが基板の容器なのですね。

セリアのLEDライトが大きめで余裕があって光を通し、しかも100円と大喜びで買い込みましたが… いざ作ってみるとこのLEDライトのカバーとスイッチを兼ねた半透明の拡散板が、赤外線LEDの信号を送受信ともに多少邪魔してくれる、という…*3

昔の100均ライトはこんな良い拡散板ではなく、透明ドームにブツブツの点があるだけでしたからね。しかし赤外線にはむしろ透明のほうが良い模様。

というわけで結局、ストックしてあった、旧式のブツブツ透明タイプな小型LEDライト容器に入れ替えて使っておりますけどね。もうこのボディは入手できないのだろうなぁという… f:id:dothiko:20180908082421j:plain

まぁ100均ライトにこだわるのをヤメればいいだけなのですが、ライトは電池ボックス付きなのでそこもお得なポイントなのです…

将来的にはESP8266で、留守時にだけリビングに置く電池駆動の遠隔照明操作リモコンとか考えていただけに、ちょっとこの赤外線パワーダウンはなぁと。

んで他の用途にまたまた同じLEDライトを買ってきて、つらつら眺めていてふと思ったのです。

このドームをバキュームフォームで透明プラバンで複製してはどうだろうか?

目の前にバキュームフォームされたような透明の物体があるじゃろ?

f:id:dothiko:20180908082639j:plain:w320

ああっ!! コイツの包装プラがあったわ!!

さっそく切り抜いて

f:id:dothiko:20180908082749j:plain:w320

組み込んでみたらなんと!ピッタリじゃないすか!! いや当たり前なんだけど(^^;

f:id:dothiko:20180908082757j:plain:w320

というわけで、これはただの仮組み。

まぁとりあえず今の動いている左手用リモコン受信器は放置し、 以前、同様に100均ライトボディに組み込んで作ったリモコン発信器*4のカバーを交換してみたところ…

f:id:dothiko:20180908084819j:plain:w320

今まで真下から発射しないと受信してくれなかった天井灯が、斜め遠方からの照射でらくらく反応してくれるように!

これでしばらくは完全透明LEDライトケースに困ることは無さそうです。

うーむ今まで捨てた包装プラを取り戻したい気分ですは…

てかまぁ、「四角いけどフタ付きの完全透明小物収納用硬質プラボックス」をセリアで見つけてしまいまして、これはこれで電子工作のケースにかなり向いてそうに思いましたですね。 普通の食品用密閉容器のような軟質プラではなく、ポリスチレンっぽい感触の接着剤効きそうなプラ容器なのですよ。

ではでは!

*1:78K0の開発環境が独特、かつ自分がなるべくwindows使いたくなく、さらにそのうえ最近のwindowsでは無理があるため、最小限の手数でUSB変換モジュールとしてだけ動くようにする予定

*2:一番最初、作った直後は全ボタン押下可能で使っていましたがピーキー過ぎて俺には無理だよって感じでした

*3:ライトとしてみればこの拡散板はただのプラスチックにしては非常に優秀、かなり光を均一にしてくれます。

*4:ラズパイとUSB接続して防犯タイマー的に使ってます

安物マウスを至高の5ボタンマウスに改造

ナカバヤシのDigioシリーズ、個人的にはフォルムがかっこよくて好きなのでした。

そしてこのMUS-UKF148BK

何が良いかってボディに忌々しいラバーコート部品が一切ないことですね*1。 これはメリット激高。 何故、各社ってかロジクールマウスはラバーコートという地雷を踏み続けるのか…?っていうか最近はゲーミングマウスのほうが盛んでもっと様々なメーカーが勃興しているようですが、ゲーミングマウスはちょっと機能が高すぎてお腹いっぱいなので買ったことが無いのです。*2

そしてボディ自体が大きい。以前、Digioの小さいカッコいいマウスを買ってみた時、ホイールの位置が指に合わず腱鞘炎になりそうになりましたが、こいつは大丈夫。

いうまでもありませんが、Linuxでもevdevのおかげでサイドボタンの戻る/進むも何の設定も無しにただ挿すだけで機能しています。*3

しかし弱点が一つ。

静音ボタンなので押した感じが物凄く弱い。 ていうか、もしかしてすぐチャタってぶっ壊れる?という感じなのでした。

購入以来、テキストドラッグで選択中に勝手に解除されることがしばしば。 *4

ワタクシ、デザインと大きさと機能(5ボタン)と有線かつ安価という条件さえ満たせば何でも良かったので、静音性はおまけでした。

そういうわけでこうなったら保証を捨て、改造してタクトスイッチでも乗せてやるぜ!と思って開腹改造に邁進するのでした。

改造について

そういうわけで早速開腹。ネジはこの3つでした。左右と下のソールを剥がさないと行けないので、改造後にカグスベール必須です。

f:id:dothiko:20180903150337j:plain:w320

ていうかこのネジがY型ネジでした。 Y型ドライバーを持っていないとこの段階で詰みます。

ナカバヤシさん(というかOEM元さん)、このグレードのマウスにそんな凝ったネジを使わなくても…(^^;

持ってる奴は普通に持ってるので、弄り防止としてもあまり意味がないかと…

さて、んでもって開けてみると…

ん…?

f:id:dothiko:20180903150739j:plain:w320

こ、この回路パターンは… マイクロスイッチ共用タイプか!!

というわけで作戦を急遽変更。マイクロスイッチに載せ替えます。*5

f:id:dothiko:20180903150821j:plain:w320

とりあえず以前、使わなくなったMSマウスあたりを分解して取ったはずのマイクロスイッチを使用。そのうちもっと良いのを使うかもですがw

スイッチが押し込めるように高さ調整が必要かと思いましたが、載せ替えただけで動きましたな…完全に両用のようです。

なお、ホイールの辺りも割と凝った仕様になっていまして、こんなちっこい部品をマイクロスイッチとホイール受けのスリットにかまして、その上にホイールを載せるという方法になっています。

f:id:dothiko:20180903150902j:plain:w320

f:id:dothiko:20180903150917j:plain:w320

f:id:dothiko:20180903150937j:plain:w320

ホイールが乗った状態のは改造前に撮影したものです(^^;

また、ホイール穴の下に灰色のゴム部品が見えていますが、これは少しでもホイールにティック感や抵抗を出せないかと、その場にあった低反発クッションを小さく切って自分で貼り付けてみたもので、製品には存在しません。

最初はホイールゴムバンドの突起にいい感じで触れてちょっとしたティック感を出してくれましたが、案の定知らない間にはがれたようで完全ヌメヌメホイールに戻ってしまいました。また開腹して取り外すのも面倒なのでとりあえず放置で…

そんなわけで快適マウスが超・快適マウスに変貌。 唯一の不満点といえばホイールのカチカチが無いヌメヌメマウスという点でしょうか…これはまぁ仕方がない。

おまけ:xorg.conf.dの設定

なお自分的xorg.conf.dの設定を以下に乗せておきますね〜

Identifierですが、どうも、aresonとかいうマウスとして認識されてるっぽいので、そういう名前にしました

Section "InputClass"
    Identifier "my_custom_areson"
    MatchUSBID "0c45:7e0d"
    Option "EmulateWheel" "True"
    Option "EmulateWheelInertia" "2"
    Option "EmulateWheelTimeout" "160"
    Option "EmulateWheelButton" "9"
EndSection

進むボタンを160ms以内に放すと進むボタンとして機能し、 それ以上押し続けているとマウスの上下動で超高速スクロールを行います。

ではでは〜

*1:ただしマウスホイールはゴム「バンド」が巻かれているタイプです

*2:高機能製品で何よりも恐ろしいのは、高機能に身体が慣れきってそれ以外では生きていけなくなった所でディスコンされて後継機皆無という状況…

*3:ただし自分的には進むボタンにホイールエミュレーションを割り当て、ごく短時間で離せば進むボタン・押したままマウスを動かすと超高速スクロールという設定にしています

*4:単に、ちゃんと押せて居ないが感触が無いので知らない間に指が離れている可能性もあり

*5:実は最初は左とホイールのだけマイクロスイッチに変えたのですが、右を押した時の違和感が想像以上に高かったので再度開腹して全部載せ替えました。

GtkSourceViewを表示専用にする

GtkSourceViewを表示専用にする、その方法が分からなかったのでメモ

Gtk+3入門

Gtk+3入門

はいアフィ入りました〜w

というか他のGTK関連書籍は正直10年いや20年前のもので役に立たないと思われたからです。ていうか昔は盛んだったんですなぁ(´・ω・`)

まぁそれはともかく、このアフィリンクの書籍とは一切関係ない話なのですが

以下は普通の知能を持っていれば当たり前の話なのですが、GtkSourceViewに対して変更を禁止しようと思ったのですが 自分はgtksourceview read-onlyなどで延々とググり続けてしまった罠。 なにかset_read_onlyみたいなメソッドがあるのかな〜と…無いですね。*1

そしてその方法について誰も言及していない。何故か。その理由はあまりにも基本的だからだと推察します。

つまり…単にGtkウィジェットとしてキー入力を無効化してしまえばいいだけではないか?と思いついたからです。

しかし単純にset_sensitive()でFalseにするとナビゲーションすら不能になるという。 そこで、キーボードイベントをconnectしてナビゲーションキー以外はTrueを返してバブリングを抑制。キー入力を遮断してしまうという方法を取りました。

マウスボタンも右ボタンを許すとメニューが飛び出てしまうので潰しておきます。 ただしこれだとテキスト選択してコピーが出来ないので(いや別に出来なくてもいいけど)何か自前の「コピー」だけあるメニューでも表示するとかしたほうが良いかもですね。

他にスマートな方法があるのかも知れませんが、こんな単純なことを思いつきました的な話でした。

サンプルコード

面倒くさいので、GtkSourceViewテスト用コードの全体をコピペ!

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

import gi
gi.require_version('Gtk', '3.0')
gi.require_version('GtkSource', '3.0')
from gi.repository import Gtk, Gdk, GtkSource, GObject, GLib, Gio

# For reference of GtkSourceView(but 4.0):
# https://lazka.github.io/pgi-docs/GtkSource-4/classes.html

class Myclass:

    allowed_keys = (
        Gdk.KEY_Up,
        Gdk.KEY_Left,
        Gdk.KEY_Down,
        Gdk.KEY_Right,
        Gdk.KEY_Page_Up,
        Gdk.KEY_Page_Down,
        Gdk.KEY_Home,
        Gdk.KEY_End,
    )

    def __init__(self):
        self.win = Gtk.Window(Gtk.WindowType.TOPLEVEL)
        self.win.set_title("title")
        self.win.set_resizable(True)
        self.win.show()
        self.win.connect("destroy",self.destroy)
        self.win.resize(1024,768)

        # widgets baseically added this self.basebox
        basebox = Gtk.VBox(False,8)
        basebox.show()
        self.win.add(basebox)
        self.basebox = basebox

        # Building:
        # You need `from gi.repository import GtkSource`, `GLib` and `Gio`

        # Coding:
        # Buffer : You need buffer for actual text contents.
        #          The source-view is only `view`, actually you must use
        #          buffer to load or set file type or something like that.
        #          it can be get from source.get_buffer() (empty one)
        #          or, create from GtkSource.Buffer().
        #
        # LanguageManager : To specify the `programming language` for `buffer`.
        #
        # FileLoader: To load file into buffer. Need GLib module to set priority
        #             when use async load.
        #             Also Gio for File (filename) object.
        #
        source = GtkSource.View()
        self.buffer = source.get_buffer()
        # Use Language Manager, to set language (i.e. file type) to buffer.
        self.lm = GtkSource.LanguageManager()
        self.buffer.set_language(self.lm.get_language('python'))
        
        # Set readonly 
        # To make view read-only, prohibit all key inputs except for navigation keys.
        source.connect("key-press-event", self.view_key_handler)
        source.connect("key-release-event", self.view_key_handler)
        source.connect("button-press-event", self.view_button_handler)
        source.connect("button-release-event", self.view_button_handler)

        # Load text contents

        # FileLoader does not accept string filename. use GtkSource.File object.
        filename = GtkSource.File()
        filename.set_location(Gio.File.new_for_path('srcviewtest.py')) # This Needs Gio module.

        fileloader= GtkSource.FileLoader.new(self.buffer, filename) # Not use constructor, use this class method. 
        fileloader.load_async(GLib.PRIORITY_LOW, None, None, None, None, None)

        source.set_show_line_numbers(True)
        basebox.add(source)
        source.show()
        self.source = source

    def view_key_handler(self,widget,data):
        if not data.keyval in self.allowed_keys:
            return True # Prohibit bubbling

    def view_button_handler(self, widget, event):
        if event.button != 1:
            return True # Prohibit bubbling

    def destroy(self, widget, data=None):
        Gtk.main_quit()

    def main(self):
        Gtk.main()

if __name__ == '__main__':
    m=Myclass()
    m.main()

*1:もしあるのなら教えて欲しいガチで…割と困っています

ソニーBDプレイヤーS5100をUbuntu 16.04から操作

何故か16.04なのは気にしてはいけない…というかドラフト記事のまま公開するのを忘れていました(^^)

さて、レビューしたかどうかすら忘れてしまいましたが実はソニーのネットワーク対応BDプレイヤー、S5100を購入したわけであります。もう3年ぐらい前でしょうか。

SONY ブルーレイディスクプレーヤー/DVDプレーヤー BDP-S5100

SONY ブルーレイディスクプレーヤー/DVDプレーヤー BDP-S5100

残念なことにこのマシン、早送りぐらいはできるんですが任意位置への再生位置指定ができないのです。 コマーシャルをバシッと飛ばすことも、前回見た部分を飛ばすことも容易ではない。 PS3の快適な視聴環境から考えると退化以外の何者でもありません。

さて、そんなS5100。 全く知らなかったのですが気まぐれにマニュアルを読みなおして見ると、DMC*1という機能があり、それでスマホなどから操作できるというではないですか。

もしかして、再生位置を指定できちゃったりするのかも? と思いつつ、調べてみるとなんとUbuntuでもDMC対応ソフトがあるというではありませんか。 それがgupnp-av-cpです。

このソフトを使うには、gupnp-toolsパッケージを入れます。

sudo apt-get install gupnp-tools

そしてターミナルからgupnp-av-cpで起動します。

さて、これでBDレコーダーが見えるようになりました。*2

しかし、もちろんS5100の方の設定も行わねばなりません。 メディアバーからネットワーク設定を選び…「レンダラーアクセス制御設定」で、UbuntuマシンのMACアドレスを許可します。

さて!再生!なんですが…その前に。 サーバとなるレコーダ側の設定でUbuntuマシンを許可していないと、レコーダーの部分をいくらクリックしても

(gupnp-av-cp:15362): WARNING : Failed to get metadata for '0': Forbidden

みたいなエラーメッセージがターミナルに出てしまい、無反応です。

今まで再生位置指定できねーと思ってたんですが、これで出来るとはね。 しかもUbuntuから出来てしまうわけで、感謝の涙が止まりません。

だがしかし。 ひとつだけ言うとすれば

やっぱプレイヤー単体のリモコンだけで再生位置指定できたほうが便利だと思うわ…

と思う、元PS3ユーザーの感想でありました。まぁ、常時PC起動状態だからこれでいいといえばいいんですけどね。ちなみにスマホiPod touchとかからも出来るらしいんで、そっちを使う手もありかも。

しかし、S5100は動画垂れ流すだけならばPS3の爆音爆熱とは比べ物にならない快適さです。

今の最新プレイヤーはこれらしいですが、同じことをこれで出来るかどうかは知りません。誰か試して!

*1:デビルメイクライではなくDLNA Media Controllerの略らしい

*2:勿論レコーダーの再生映像が見えるわけではなく、存在が確認出来るだけ