Posted by & filed under debian, Linux, RAID, tips.

前回の投稿からかなり経ったが、続き。

あれから難なくRAID5の構築自体は完了したのだが、GRUBからの起動時にちゃんとinitが実行されないという障害にドハマりして、記事の纏めに時間が掛かってしまった。

とりあえず前回作成したRAID5の癖にディスクが2本しかないアレイに、もう一つのディスクを追加する。

# fdisk -H224 -S56 /dev/sda
前回sdbとsdcをアレイ構築に使った。パーティションIDを'fd'に指定するとmdadmが自動識別してくれるので、やっておくと絶対によい。作ってしまったsdb, sdcのパーティションについても、後から変更できる。

# mdadm /dev/md0 --add /dev/sda1
スペアとしてディスクが追加される。

# mdadm --grow /dev/md0 --raid-devices=3
RAID5のアレイが3本になり、パーティションサイズが拡張される。操作はバックグラウンドで実行されるが、ディスクのサイズによって非常に時間が掛かる。ちなみに自分の古いPCでは操作の完了まで20時間かかった。

# cat /proc/mdstat
この結果で状況が監視できる。

# resize2fs /dev/md0
サイズ拡張。自動でパーティション最後まで拡張してくれる。
ここ以降は/(root)をRAID5にした場合に必要な操作
# dpkg-reconfigure grub-pc
障害時に起動しないトラブルを避ける為、アレイに属するディスク全てをgrubのインストール先ディスクとして選択し、再構成しておく。

# update-initramfs -u -k all
initrdを更新する

本来はここまでの操作で再起動すれば普通に立ち上がってくるのだが、自分のケースではRAID5アレイをROOTに使っていたために、GRUBでブートができなくてハマった。
原因はカーネルがディスクドライバをロードする前にinitrdスクリプトのmdadmコマンドが実行されてしまい、initrd中にROOTが発見できないということであった。
以降はinitrdでrootが見えずフォールバックしてしまう人向け。

# cp -a /usr/share/initramfs-tools/scripts/local-top/mdadm /etc/initramfs-tools/scripts/local-top
# vi /etc/initramfs-tools/scripts/local-top/mdadm
viで編集し、冒頭にsleep 5を挿入する。アレイ認識の実行前にディスクドライバがロードが完了するようにする。

# update-initramfs -u -k all
設定弄ったら、initrdは忘れず更新する

今日はここまで。

Posted by & filed under 未分類.

先日Chinachuサーバで愛用していた2TBのWD20EARSが2歳半という若年で他界したので、反省を生かし、今回はRAIDを組む事にした。
マザーボードに組込まれているRAIDコントローラはマザーボードが逝ったときに詰むことがあるので、ソフトウェアRAID(5)を利用する。

これまでWD20EARSを2本所有しそれぞれにmpegを満タンに近い状態まで保存していた。
よってデータを整理するにしてもRAID構築の為に3本購入することは避けられないかと考えていたが、実はそんな必要はなくRAID5をスモールスタートさせることができるという記事を見付けたので、それに従って操作をした。

参考 Convert Linux Software RAID1 to RAID5

# fdisk -H224 -S56 /dev/sdb
パーティションを切る…

# apt-get install mdadm
# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=2 /dev/sdb1 /dev/sdc1
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Jan 5 02:20:38 2014
Raid Level : raid5
Array Size : 1949087232 (1858.79 GiB 1995.87 GB)
Used Dev Size : 1949087232 (1858.79 GiB 1995.87 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Sun Jan 5 02:20:38 2014
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1

Layout : left-symmetric
Chunk Size : 512K

Name : debian:0 (local to host debian)
UUID : d2ce37ab:e16aa688:79e4e309:90078281
Events : 0

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 0 0 1 removed

2 8 33 - spare /dev/sdc1
detailの内容を出力するとraid5になっている
これで、データの移行が完了したところでmdadm –growを使いディスクを追加すると、リバランスが実行されて3本になる、らしい。

今日はここまで。続きは後日。

Posted by & filed under 未分類.

久々にdebianにSun JDKを入れようとしたら、知らん間にパッケージがなくなっていた。
ググると、日本語サイトではOracle本家からダウンロードして色々ガチャガチャする手順しかみつからなかったので、英語で見付けた以下ページを参考に実施した。

上記サイトが運用しているUbuntu向けパッケージリポジトリに、OracleJDKのインストーラ(のラッパー)が登録されているので、それを追加する。
ちなみに参考ページではsources.listを更新しているが、この手順ではsources.list.dを使っている。
sources.list.dの方が、イジったところが明確になるし、移行の時もマージの面倒がなく、使いやすいと思う。

$ su -
# cat <<EOF > /etc/apt/sources.list.d/webupdjava.list
> deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main
> deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main
> EOF
# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
# apt-get update
# apt-get install oracle-java7-installer
# exit
これでOK。
環境によっては、update-alternatives が必要になるかもしれない。

Posted by & filed under 未分類.

前回のエントリの続き

前回、重複を除去したディレクトリに8万のファイルがあった。
ここから、exif情報を元に、どのカメラで、どのサイズで、いつ撮影したか、という順で写真を無理矢理オーガナイズする。
前回同様、実施は自己責任で。あと、今回は時間の都合上、あまり整形をしていない。

2. exif情報のぶっこ抜き

debianのパッケージexifをインストールする。

# aptitude install exif

写真からexifを抜いてみる。

# exif #349650584.JPG
Corrupt data
The data provided does not follow the specification.
ExifLoader: The data supplied does not seem to contain EXIF data.

Oh. これアカンやつや。

# exif #208627408.JPG
EXIF tags in ‘#208627408.JPG’ (‘Intel’ byte order):
——————–+———————————————————-
Tag                 |Value
——————–+———————————————————-
X-Resolution        |72
Y-Resolution        |72
Resolution Unit     |Inch
Exif Version        |Exif Version 2.1
FlashPixVersion     |FlashPix Version 1.0
Color Space         |Internal error (unknown value 65535)
——————–+———————————————————-
これもあかんぽい。
# exif #183527616.JPG
EXIF tags in ‘#183527616.JPG’ (‘Intel’ byte order):
——————–+———————————————————-
Tag                 |Value
——————–+———————————————————-
Manufacturer        |FUJIFILM
Model               |FinePix F401  
Software            |Digital Camera FinePix F401   Ver1.00
Date and Time       |2004:10:07 15:22:37
YCbCr Positioning   |Co-sited
Copyright           |[None] (Photographer) – [None] (Editor)
X-Resolution        |72
Y-Resolution        |72
Resolution Unit     |Inch
Exposure Time       |1/250 sec.
F-Number            |f/2.8
Exposure Program    |Normal program
ISO Speed Ratings   |200
Exif Version        |Exif Version 2.2
Date and Time (Origi|2004:10:07 15:22:37
Date and Time (Digit|2004:10:07 15:22:37
Components Configura|Y Cb Cr –
Compressed Bits per |3.2
Shutter Speed       |8.00 EV (1/256 sec.)
Aperture            |3.00 EV (f/2.8)
Brightness          |5.23 EV (128.59 cd/m^2)
Exposure Bias       |0.00 EV
Maximum Aperture Val|3.00 EV (f/2.8)
Metering Mode       |Pattern
Light Source        |Unknown
Flash               |Flash did not fire, auto mode
Focal Length        |5.7 mm
Maker Note          |274 bytes undefined data
FlashPixVersion     |FlashPix Version 1.0
Color Space         |sRGB
Pixel X Dimension   |1500
Pixel Y Dimension   |1386
Focal Plane X-Resolu|4348
Focal Plane Y-Resolu|4348
Focal Plane Resoluti|Centimeter
Sensing Method      |One-chip color area sensor
File Source         |DSC
Scene Type          |Directly photographed
Exposure Mode       |Auto exposure
White Balance       |Auto white balance
Scene Capture Type  |Standard
Sharpness           |Normal
Subject Distance Ran|Unknown
——————–+———————————————————-
やっとまともそうなのがでてきた。
ということで、今回3パターンあるということがわかった。
  • ちゃんと復元できた
  • 完全にぶっこわれている
  • あやしい
上記を踏まえパスの構造は以下のような感じにする。

[status]/[source]/[pixelsize]/[date]/[timestamp]_[name].jpg
nameは元の数字スタイルのファイル名。
他は推測ください。
ちなみに、上記の1500×1386というのが正にそうだったのだが、ピクセルサイズの計算方法が違うためか実際に開いてみると1500×1050というサイズだった。どこかで対応できるかググってみたがあまり良い情報が出ず、断念してそのままEXIF情報を鵜呑みにすることにした。

3. 実装

awk(今回はnawk) と exif の合せ技で適当に作る。。。と思ったが、まず冒頭に#が入っていると色々扱いにくいので、取り外す。
$ find ./ | xargs rename ‘s/#//’
スクリプトの実装
めっちゃ長くなった…
#!/bin/sh
FILE=$1
exif $FILE |
awk -v SRCN=${FILE} ‘
BEGIN {
 FS=”|”;
 STAT=0;
 SRC=”null”;
 PX=”nan”;
 PY=”nan”;
 DATE=”00unknow”;
 TS=”00unkn”;
}
/^Model/ {
 STAT++;
 SRC=$2;
 gsub(/^ +| +$/, “”, SRC);
 gsub(/[^-a-zA-Z0-9_+=.]/, “_”, SRC);
}
/^Pixel X Dimension/ {
 STAT++;
 PX=$2;
 gsub(/ /, “”, PX);
}
/^Pixel Y Dimension/ {
 STAT++;
 PY=$2;
 gsub(/ /, “”, PY);
}
/^Date and Time/ {
 if (DATE==”00unknow”) {
   STAT++;
   DATE=substr($2, 1, 10);
   gsub(/:/, “”, DATE);
   STAT++;
   TS=substr($2, 12, 8);
   gsub(/:/, “”, TS);
 }
}
END {
 if (STAT>=5) {
   STAT=”good”
 } else if (STAT) {
   STAT=”bad”
 } else {
   STAT=”corrupt”
 }
 DSTN=SRCN;
 gsub(/^.*/|.[^.]*$/, “”, DSTN);
 printf(“%s %s/%s/%sx%s/%s/%s_%s.jpgn”, SRCN, STAT, SRC, PX, PY, DATE, TS, DSTN);
}
上記をorganizer.shとして保存、実行。
$ find ./jpg/ -type f | head -5 | xargs -l1 sh organize.sh 
./jpg/147391416.JPG good/FinePix_S5000/2048×1536/20060919/154827_147391416.jpg
./jpg/685164448.JPG bad/null/nanxnan/20110922/160607_685164448.jpg
Corrupt data
The data provided does not follow the specification.
ExifLoader: The data supplied does not seem to contain EXIF data.
./jpg/71972166.JPG corrupt/null/nanxnan/00unknow/00unkn_71972166.jpg
Corrupt data
The data provided does not follow the specification.
ExifLoader: The data supplied does not seem to contain EXIF data.
./jpg/165420104.JPG corrupt/null/nanxnan/00unknow/00unkn_165420104.jpg
./jpg/145980200.JPG good/FinePix_S5000/2816×2112/20050816/131321_145980200.jpg
あとは、これを使って適当にファイルをコピーする
$ find ./jpg/ -type f | xargs -l1 sh organize.sh > organized.txt 2> /dev/null
$ grep corrupt organized.txt | wc -l
26079
$ grep bad organized.txt | wc -l
2818
$ grep good organized.txt | wc -l
53355
$ cut -d’ ‘ -f2 organized.txt | sed -e ‘s//[^/]*$//’ | sort | uniq | xargs mkdir -p
$ sed -e ‘s/^/mv /’ organized.txt | sh
ここまで処理して気付いたが、日付が空白で入っているものがあった。
それらについては手で処理した。
以上、また機会があれば整形して公開する。

Posted by & filed under 未分類.

父親が撮り鉄で、WindowsのPCで大量の写真をUSB外付けディスクに保存して管理していたのだけれど、その親父がマルウェアに汚染され倒して遅くなったPCに根本的な解決策を施した。

Windows8.1のクリーンインストールという核スイッチはUSB外付けディスクでさえ初期化してしまうらしい。(たぶんリテラシのない親父がメニュー間違えただけだと思うけど)
Baiduやなんかで色々問題になっているけれど、パソコンが不調になったときに自分で対処できない人はフリーソフトやその類は使うべきでない。どんな仕込みが入っているかすぐにはわからないからだ。

ということで、綺麗にフォーマットされてしまった2TBのハードディスクを渡され、大量の画像ファイルの復旧をすることになった。

debianでも利用可能なntfs-toolsのundeleteコマンドを利用するも、ファイルシステム上で削除されたファイルしか検出できず、フォーマットされる前のものの復元はできなかった。

そこで検討したのは EaseUS Data Recovery Wizard と Finaldata 10

両者ともセクタスキャンが可能で、時間が許せば2TBを全部読み込んで可能性のあるファイルを見付けだしてくれる。両方とも試供版でどれくらい助かりそうかまでは確認することができた。いずれも売価は7000円前後。

前者のEaseUSは2TBを読み込む途中で不正終了するのでFinaldata10で復旧することに決め、12万枚もの画像を救出することができた。
ちなみに2TBのディスクをUSB2でスキャンすると150時間かかる。ちょっと遅すぎちゃうかなどとボヤきつつ毎晩進捗を見ていたが、80時間目くらいにオフになったディスプレイをスペースキーで復活させたところ、中断されてしまった(中止にフォーカスが当たっていた)。自分のせいやけどやはりWindowsは嫌いや。Finaldataにも中断された再開する機能を実装してもらいたい。もはや数時間で解決できるような問題は少ないんではないかと思う。

フォーマットされてしまうとファイル名などの情報が復旧されないため、なにがなんだかわからない状態になってしまう。ちなみに12万枚の内、かなりの枚数が複製によるものということも眺めてわかった。
ということで、ここからは重複除去をする方法、および取得可能なものについてはEXIFから情報を抽出して名称を付け替える処理を検討した。

処理はdebian上で行なった。Redhatなどでも問題なく実施できるはずだ。
毎度のことではあるが、この文章による障害や事故については保証しないので、参考にして作業する場合も自己の責任において実施していただきたい

1. 重複ファイルの検出

ロジックを作成するのも面倒なので、sha1sumでハッシュを作成し、重複するフィンガープリントのファイルをがさっと消してしまうことにした。
(/mnt/disk/restore にファイルがある想定)
ファイルのフィンガープリントを作成(対象件数が多過ぎるのでfindで実行する)
$ cd /mnt/disk/restore
$ find ./ -type f -exec sha1sum {} ; | sort > files.sum
$ less files.sum
0000d38fc76834f913908593cb5fad48c20662ce  ./jpg/#259538616.JPG
0002e55243fbab6a766d93db65ad7eb7fa81b2ff  ./jpg/#255201456.JPG
0003143aa02a2639069bd26ca912d70d27b79dcc  ./jpg/#353345088.JPG
0004470e8587ed1acdd1c8c18c4bed5146da2d63  ./jpg/#612002424.JPG
0004470e8587ed1acdd1c8c18c4bed5146da2d63  ./jpg/#658702376.JPG
0004caf37836025c3e51da70cd95aa067f22531d  ./jpg/#350668848.JPG
0005420f45557d92976f2db2dd35c3a0c7385faf  ./jpg/#71054968.JPG
0005eb438ea950e4364f029db31a53a3f793eaef  ./jpg/#208824752.JPG
フィンガープリントの文字列順にソートした状態で出力する。これで上の行と自分の行のフィンガープリントが同じであれば、重複していると見做せる。

$ awk -e 'BEGIN {H=0;} {if (H == $1) { printf("%s %sn", $2, F); } else { H = $1; F = $2 }}' files.sum > dups.list
$ less dups.list
./jpg/#658702376.JPG ./jpg/#612002424.JPG
./jpg/#208825160.JPG ./jpg/#208824752.JPG
./jpg/#237570712.JPG ./jpg/#129325576.JPG
./jpg/#177345584.JPG ./jpg/#113059880.JPG
./jpg/#180130104.JPG ./jpg/#113059880.JPG
./jpg/#212403320.JPG ./jpg/#113059880.JPG
./jpg/#608047712.JPG ./jpg/#113059880.JPG
./jpg/#303852336.JPG ./jpg/#113615624.JPG
./jpg/#39478832.JPG ./jpg/#113615624.JPG
./jpg/#651855912.JPG ./jpg/#113615624.JPG
右側は比較元のファイル。左側カラムを適当にカットしてxargsに喰わせる。
$ mkdir trash
$ cut -d' ' -f1 dups.list | xargs -I '{}' mv '{}' trash
ちなみに何が起こっているのか確認したい場合は、mvの前にechoを挿入してみよう。

$ ls -1 jpg | wc -l
82252

$ ls -1 trash | wc -l
41176
ねむくなったので、今日はここまで。

続きはこちら。

※ 2017/8/16日更新
EaseUS日本法人さんからの指摘で、製品名とURLを変更(ちなみにfinaldataを使った)

Posted by & filed under 未分類.

最近コプロセッサというキーワードに興味を持っていて、その周辺を少し調べ回っていた。
2000年代前半あたりからコプロセッサとしてFPGAを使った分散処理などが試されるようになっているらしく、今ではIBM PureDataやオンライン株取引用のLANカード、Bitcoinの採掘機など、色々な製品が出回っている様だ。

IBM PureData System
FPGANETWORKING
FPGA mining x6500(現在はカスタマイズされた専用チップが主流→ASIC)

HDLという言語でFPGAの機能をデザインすることが可能で、上手く組めばCPUよりも高速にストリームの計算が行えるようになる。試してみたい!と衝動的に計算用FPGAボードを捜してみると、AlteraやXilinxといったブランドのFPGAチップが載ったボードが5万くらいからある様だが高すぎて趣味では手がでない。
好きな人は専用の評価ボードでビデオゲームのエミュレータなんてことをやっている様だ。

Artix-7評価ボード(凄くこだわりがあってよさそうやけど高い。5000個とか売れたらもっと安くなりそう)


上記のようにOpenCLでもプログラミングができるようになってきているらしいので、GPUでも使えるOpenCLから入ってみたいと思う。

今日はこれまで。

Posted by & filed under iphone, physical.

2015/1/8追記: ディスプレイの上側にあるバックライト周辺に補修液が浸透すると画面が暗くなり、逆に悪化する場合があります。(2度目のガラス割れで発覚しました) 十分に注意してください。また、この記事は無保証です

Apple careとか、安心パックとか、そんなの自分には必要ないと思っていた時期が僕にもありました。

買ったばかりのiPhone5cがこんな姿になるまでは…
Appleの正規代理店(appleで検索してね)で修理する方法があるが、全交換となり27800円と高額。そしてサードパーティの修理店もまだ対応が十分にできない状況であるから、苦肉の策としてケミカルでの修理を試みた。補修後が下の写真となる。
割れ自体が消えることはなかったが、当初文字も見えない程に割れていた右下あたりが、ある程度見えるように改善された。
筆者のような同じ悩みを持つ貧乏人の為に、これより使ったものや具体的な手順を示すが、この手順を真似したことにより生じたあらゆる損害について、筆者は一切の責任を負いません自己責任で行うことに同意できない人は、絶対に真似をしないこと
使ったのは飛び石などで欠けた自動車のフロントガラスの修理剤であるWindshield repair kit(amazonの商品名は「安くて役立つ!ひび割れ補修!! フロントガラス リペア キット 2ヶ所分」) 。ちなみにデザインが変わったようで届いたのは右のパッケージだった。
  
補修後はiPhone5用保護フィルムが必須なので、かならず準備しておくこと。数μ程度の凹凸ができてしまうため「強化ガラス製」などといった硬いフィルムはおそらく向かない。

なお、作業において強い紫外線が必要となるため晴れた午前中から着手することが望ましい。
紫外線ライトがあれば代用になるかもしれない。

1. 補修面の清掃

まず割れたガラスの破片やゴミなどを取り除く。
筆者はiPhoneを裏返してトントンと叩いたあと、セロテープでゴミを取り除いた。
小さいガラス辺が落ちるので、怪我をしないよう後始末すること。

2. 補修キットを準備する

補修キットをあけ、レジン(左上端の黒い小瓶)と長方形のフィルム、カミソリの刃を取り出す。
添付の英語で書かれた手順書は自動車の修理を想定している。手順書では注射器のようなポンプと土台を使うように書いてあるが、これらは使わない。筆者も最初、自動車用の手順を試みたが、亀裂が土台よりも大きいとポンプの空気が漏れるため失敗した。しかもガラス板と液晶の間に気泡が入ってしまった。

3. レジンを垂らし、フィルムの上から揉む

レジンを割れが激しい場所に垂らし、その上からフィルムを貼る。故障(ガラスが割れた時点でもう故障してるけど)の恐れがあるためホームボタン、上部のスピーカ周辺にはレジンを垂らさない。ガラス保護フィルムを貼るような要領で空気を逃がしたあと、ガラスを少し力を入れて押さえ、揉む。なお、ガラスは下の液晶と密着しており、力を入れすぎると液晶が割れて一巻の終りとなるので、慎重に行うこと。

4. レジンの浸透を待つ

少し揉んだあと、フィルムを貼ったままにしレジンが亀裂に自然に行き渡るのを待つ。筆者は日光が当たらない室内で20分程放置した。

5. 日光で硬化させる

フィルムを貼ったままiPhoneを日光の下に20分程放置する。レジンが紫外線により硬化する。

6. 余分なレジンを除去する

iPhoneを天日干しからおろし、フィルムをはがす。
亀裂に入らなかったレジンが表面に残るので、それをカミソリで削り落とす。ガラスを削ってしまわないように慎重にしなければならないが、亀裂からはみ出たレジンが残ると保護シートが乗らなくなるので、丁寧に削ること。説明書にはコンパウンドを掛けると良いと書いてあるが、iPhoneのガラスは表面が化学処理されているはずなので、やらない方が良いだろう。

7. 表面の清掃

削り落したレジンを手順1の要領でもう一度取り除く。

8. 完成

亀裂全体にレジンが入るまで(≒気が済むまで)手順3から7を繰り返し、上から液晶保護フィルムを貼って、完成となる。

2014/10/27

年に何度かこのページで商品を買われている方がいらっしゃるようなので、もし「ダマされた!」というような結果になった方はコメント頂けると幸いです。



Posted by & filed under 未分類.

chinachuちゃんを動かしている録画サーバ。先日rtcalarmで自動起動するようになったが、未だに電源オフは手動。(電源ボタンを手でクリックしてハイバネートさせている)
どうも電源ボタンイベントを2つのプロセスが監視しているらしく、タイミングが合うとアラーム起動によってハイバネートから復帰したとたんにまた電源オフってなって困っている。

電源ボタンにはhibernateを関連づけているが、このhibernateの冒頭で処理を止める方法がないか考えていた。(2個イベントを飛ばす原因を潰した方が良いかもしれないが、どのみちこの途中でわかることだと考えている)
どうもpm-utilsのドキュメントを漁っても出てこないあたりからして、色々作る必要があると思われる。

すこし発想を変えて、電源ボタンへのイベントを独自のスクリプトにして、都合が悪いタイミングではハイバネートをしないという方法ではどうかと考えた。

acpi-eventの関連付けを独自スクリプト(a)に設定し、他のボタンイベントを監視しているソフトウェアの設定を解除する。

(a)には以下の条件を組込む

  1. chinachuの録画開始5分前以内ではハイバネートしない
  2. chinachuのステータスを監視し、epg取得中などの状況下ではハイバネートしない
  3. 他、ffmpegなど止めたくないプロセスが動作中の状況ではry
  4. 上記の心配がなければ、ハイバネートさせる

(2はそんなAPIあるんか?というところから要確認)
今日はここまで。

Posted by & filed under 未分類.

とりあえず。
普段はハイバネートしておいて、録画5分前になると起動する構成。

chinachuは github より取得できる。

参考URL https://github.com/kanreisa/Chinachu/wiki/REST-API

$ cat /usr/local/bin/chinachuNext
#!/usr/bin/env python3
# -*- charset: utf8 -*-

from urllib.request import urlopen
import json
import io
import time


class Reserves:
def __init__(self, url):
response = urlopen(url)

self.o = json.load(io.TextIOWrapper(response, response.getheader('content-type').split('charset=')[1]))

def getNextTime(self):
now = time.time()
for e in [ int(ent['start'] / 1000) for ent in self.o if ent['start'] / 1000 > now ]:
return e

if __name__ == '__main__':
url = 'http://localhost:10772/api/reserves.json'
print(Reserves(url).getNextTime() - 300)

$ cat /etc/pm/sleep.d/81chinachu
#!/bin/sh
PATH=/sbin:/usr/sbin:/bin:/usr/bin
SHUTDOWN_HELPER=/usr/share/unattended-upgrades/unattended-upgrade-shutdown

case "${1}" in
hibernate|suspend)
if /usr/local/bin/chinachuNext > /sys/class/rtc/rtc0/wakealarm; then
echo Wakeup schedule has been set successfully.
fi
;;
resume|thaw)
echo 0 > /sys/class/rtc/rtc0/wakealarm
# TODO: update epg here
;;
esac

2013/9/5 追記:
pm-utilのスクリプトに誤りがあったので修正 : アラームをセットした場合、再セットする前にリセットする必要がある。 参考
chinachuNextスクリプトも、jsonの冒頭が必ずしも次の番組になっていない場合があるので、実行時よりも後の値を選択するロジックを追加。

Posted by & filed under 未分類.

とりあえず。

libCEC

libcec HDMI経由でPCを、またはテレビを操作するライブラリ。元々専用のデバイス向けに作成されているようだが、RadeonなどのHDMIに流用できるか?というところは宿題にする。

idle detection on linux

ググってもなかなか良い情報が出てこない。
How to check if screen saver is running? とか、detecting user idle (no user input) time globally on Linux or better cross platformのあたりを見て自分で作る必要がありそう。