起きて雪かき→メシ→寝る→
起きて雪かき→メシ→寝る→
2010/1/2(完)
という感じのようです。いま2周目のメシ待ち。
ちなみに起きた時点で朝メシは終了。
...いい年になりそうだ。
起きて雪かき→メシ→寝る→
起きて雪かき→メシ→寝る→
2010/1/2(完)
という感じのようです。いま2周目のメシ待ち。
ちなみに起きた時点で朝メシは終了。
...いい年になりそうだ。
蕎麦を食べたのでやっと年末という雰囲気に(基本、TV見ない人間なので)。
時間も押してますので手短に。
今年を振り返りますと、父との死別に尽きる一年でした。
そのなかで家族・親戚・友人の存在のありがたみ、関係のあり方を再認識した年でもありました。
また、未知の経験との戦いでもありました(主に家のことで)。たくさん書類を書きました...。結構テキトーなんだなと思う一方でうるさい場面もあり、もうやりたくないですねアレは。
おかげでいろいろ勉強しました。数年で揮発しそうな知識ではありますが。
いろいろ壊れた年でもありました。DAP、HDD(サーバ、メイン機)、OS(サーバ、メイン機)、冷蔵庫(旧)、ボイラー、ガステーブル、etc、etc...。
マンガもたくさん買いました。あんまり表に出しませんでしたけども(つーか更新あんまりしていない...)。この不況で収入激減しましたんで、もうあんまり手広くできませんけども!
あんまり更新しない年でした。ブログでさえ更新意欲をそがれるってどんだけ...。
来年は、今年と比べて経験分余裕(主に意識的なものとして)がありそうなので、いろいろ徹底できなかった事項を片付けていかないとなーと思っています。
プールも本格的に再開したい(そして腰周りを...)ですね。ブログももう少し更新頻度上げたいとこです。イラストは...ない、かな~。
まずはとりあえず経済的に安定してくれることが一番ですがね。
それではみなさま、よいお年を。
HDDやらOSやらよく壊れる年でありましたが、極めつけが登場。
ボイラーが壊れました。
orz
Aソーラーのヤツなので電話して診てもらったところ、もう補修部品すら全国のどこにもない状態ということで...他を見繕うような余裕もなかったため、同社の新しいやつを入れることにけって~い。
ウン十万...orz
前回のふすま貼りに続き、今度は障子の張り替えです。
正直、乾き切るまでどうだかわかりませんが、たるみが見えまくりの仕上がりにがっくり感満点です...。疲れた。
後は元の場所に戻すだけ、というタイミングで角を他のヤツにぶつけて穴あけるというお約束もやりましたよ、ええ。
ということで、とある日に帰宅するとブルースクリーン吐いてwindows2000君が死んでいました(注:パソコン使用していない時間はスタンバイ状態です)。
「またか」とたいして気にもせず再起動しましたが、いつまでたっても起動画面にたどり着きません。ここで初めて「え?」となりまして、いろいろ試して調べたところ、システムのレジストリが破損したらしく読み込めないで止まっているようでした。
NortonGhostで書き戻すのが常套な状態だったのもあり、レジストリのバックアップなんかはさすがに取ってませんでしたし、回復コンソールでの修復例も試して見ましたが見事にいろいろなくなってる状態にしか戻らなかったため、お手上げ状態に。かといってGhostでスナップショットを取ったのももう2年前の状態で、その間いろいろ適当に追加してたこともあり、戻しては見ましたが収拾がつかない様子で、しょうがない(というか前から覚悟してた)ので再インストールからやり直しました。
すでに3度ほどかけて再セットアップの計画書をテキスト保存&必要ファイル群収集していた実績があるため、差分/修正個所を検討するだけして再インストール開始。少し前にhfslipというツールで修正パッチやらいろいろと統合してインストールディスクを作っていたのも幸いして、以前よりもスマートなシステムになって帰ってきました。
この機会に旧来からの問題点が何点か解決/理解できたのもあり、まあそう悪くはないことではありましたが...急にレジストリが壊れるってなんじゃい!
ここ1年足らずでHDDは何度か壊れる、システムは壊れるとずいぶんな年ですね!
そんなこんなで、「さみだれ」8巻買ってますが、エントリは後日。
今日、たまたまテレビで目にしたので見たのですが、フィギュアスケートでプルシェンコが出てましたね。フィギュアスケートなんてまったく興味なかったのですが、例のトリノオリンピックのあたりでいろいろ日本人選手が騒がれてたあたりに、「まあどんなもんやろ」と見たのがきっかけで例のプルシェンコを知ったわけですが。
まあ、トリノからずっと休止(調べたらプロとしてアイスショーとかには出てたとかあるらしいですが)してたとかで、大きな大会はブランク明け状態らしかったのですが...まあ、それ込みで「だんち」なパフォーマンスは流石と言ったところでした。トリノで2位に30pt差を付けてみせたのが初見だったので比べるのはどうかと思いますが、素人目にはブランクの影響と言うものもわからず、ただただ圧倒的な演技を見ておりました。
ああいう世界ってのはなにが凄くて得点になってるのかとか、知識があって目が(ある程度)肥えてる人にしかわからないと思うんですよね。さすがに「10回転しました!」とかいえば馬鹿でもわかりますが、必ずしもスコア計算上大きく有利になるとは言えないケースもあるのがこの手の「演技競技」ですから。
そんなことを言っている素人が見ていても、プルシェンコの演技というのがわかりやすいくらい訴えかけるものが違って見えるところに、その実力がどれほどのものかわかるってものです。なんかね、こう、他の選手は単調に感じる&ダイナミズムに欠けるって感じを受ける(素人にはその演技がどれだけ高度なものかなんてわかりません)んですが、プルシェンコはもう全然違うと言っていいくらいでオーラみたいなものを感じます。これが一流の中の一流ってものなんでしょうね。
プルシェンコについては動画とかたくさんありますんで、是非未見の方は探して視聴してみてほしいくらいです。ライバルだったヤグディンって人も半端ないですよ。
最近はどっぷりとlinuxをいじっているわけですが、ようやくファイルサーバ(samba)の構成も整理し終えた感じです。今回からは一部ユーザー認証制にして、プライベートな内容を他からいじれないようにしました。
それに合わせてHDDの使い方も少し変えたため、標準インストール時に気にしていなかったディレクトリ構成に問題を感じ、そちらも合わせて整理を行いました。
具体的にはシステムの入ったパーティションとは別になっていた「home」ディレクトリを、システムパーティションへと引っ越しました。パーティションごと「home」へマウントされていたため(「home」=パーティション状態)、マウントを解除しないとシステムパーティションにホームディレクトリの内容を移せないと考えまして、まずは「home」からアンマウントしました。
しかし規定ユーザでログインしているからか、rootで作業していてもbusyと返ってきて単純にアンマウントできませんでした。busyということはなんらかのプロセスが動いていて、「home」内を参照しているということでしょう。そこで調べたら、
fuser -cu /home
とrootで実行することで「home」以下のすべてのプロセスを停止できることがわかりました。これで無事にアンマウントできました。この時点で「home」ディレクトリはシステムパーティション(ルート)内に実在することになり、次はその新「home」へ旧「home」の内容を移動させることになります。
これはまず、アンマウントしたばかりのパーティションをどこかにマウントしてファイルにアクセスできるようにします。とりあえず/mnt/tmpにマウントして、そこから
tar -cf - * | tar -xpf - -C /home
という感じにデータを移行します。
あとは/etc/fstabを編集して該当パーティションを「home」に自動マウントしないように設定を書き換えまして、
mount -a
で自動マウントの設定で再マウントさせて終了です。
この逆はよくネットでも見かけたのですが、時代に逆行しているのか私のやろうとしている流れは解説が見つからなくて半信半疑での作業でした。無事に終わってホッとしました。
せっかくなので昨日の続きとして、消してもいいファイルの検証を行って見ました。あくまで一番組のみを録画しただけの特殊な環境&バックアップ取得済みという環境でのことですので、何の用意も無く試して泣くことの無いようお願いいたします。
おさらいですが、昨日の結論として
というところまで確認しました。
今日はさらに踏み込んで、「.toshiba~」フォルダの中やメタファイル(meta,rat)を消せるだけ消してみようということです。
まずはさっそく無くても大丈夫との声もあるメタファイルから消してみました(以下結果)。
結果は話どおり、両方消しても再生は可能でした。ただし、番組名など表示されなくなり、英数字のみで構成される動画ファイル本体の名前で表示されるようになりますので、metaファイルは残したほうがよいでしょう。
次は管理フォルダ「.toshiba~」ですが、当方の現況ではこんな構成になっています。
│ bid.bin
│ did.bin
│
├─aeef0000000
│ aee00000000.bin (※~0.binから~6.binまで計7個)
│
├─alkf
│ alc0000000.bin
│ alc0000000.buc
│ ald.bin
│ alk.bin
│
└─almf
alc.bin
これを削除・復元を繰り返して試行した結果、
│ did.bin
│
└─alkf
alc0000000.bin
該当の一番組を再生するのに支障のない最小構成は以上のようになりました。意外だったのは「aeef0000000」フォルダで、録画番組数と同じ数のファイルが存在するわりに、消してもなんら再生に不具合が出ませんでした。
というわけで、思ったよりも存在が不明なファイルが多いようだという結果になりました。まあ、実際はなんらかの問題を抱えているのに、該当番組を見ることに関してのみは表層に現れなかっただけとも考えられますので、くれぐれも鵜呑みにして削除しないことをお勧めいたします。
REGZA「Z3500」シリーズをLAN-HDD環境で使用していましたが、環境変化のため、以前問題なかった番組のバックアップ(退避しておいていざという時に元に戻す)がうまく行かなくなっていました。そこで後学のためにもいろいろいじって見て再度確認をしました。
ちなみに以降原則としてデータと言っているのは「動画本体:dtv」と「メタデータ:meta&rat」、そして「.toshiba~」のフォルダ1つとファイル1つをまとめて「データ」と扱います。
最初に問題になったのはLINUX上で「データ:A」をコピーして「コピー:B」を作成したときのこと。
このときのBは別フォルダを作成してそこへコピー。この場合は不思議とAB共に普通に再生でき、データが二重であっても再生できるという現象を確認しました。そこで次はAを削除しますと、Bは再生不可になりました。それではと、BをAとして(同じ場所に)書き戻しましたが、これでもBは再生出来ませんでした。
以前は確かに同じところに戻せば再生できたので、これは何故だろうと確認していましたところ、LINUX上でファイルコピーなどをした関係から所有権(パーミッション)が変わっていたためのようでした。思い出して見ると、確かに問題なく復元できたときはWindows上からコピーした記憶があります。とりあえずREGZAのデータは所有権がguest(この場合はnobody)である必要があるようです。
次にWindows上から操作して確認してみます。今度はまず「データ:C」を用意しました。REGZA上から新規にフォルダを作成して、そちらへ番組1つを移動させたものです。つまり正規の方法で動かしたデータになります。これをもとに、別の共有ポイントβにデータをコピー、それを「コピー:D」とします。
まとめますと共有ポイントαのサブフォルダにC、共有ポイントβのサブフォルダにDが出来ています。この状態で再生を試しますがCはOKなのに対し、DはNGという結果になりました。
そこで確認しますと、Cのあるフォルダには「.toshiba~」のフォルダのみが足りないようでした。つまりは正規の方法で動かしたデータでも、移動できるのは「dtv,meta,rat,.thoshiba~」の4ファイルのみと言うことなのでしょう。逆に言うならば、「.toshiba~」のフォルダはディスクのルートディレクトリになければならないということです。
とくれば、共有ポイントαのルートに存在する「.toshiba~」フォルダを共有ポイントβのルートへコピーしてやれば再生できるはずです。さっそく試しますと、予想通りCD両方とも再生が可能となりました。それならば、と「.toshiba~」ファイルを削除してみますとこれでも問題なく再生できる様子。
これからわかるのは、
という仕様のようです。まあ3番目については検証してませんので断言は出来ませんが。
それから巷の情報によるとメタデータも無くても大丈夫とのことなので、実質、管理フォルダ「.toshiba~」と「動画本体:dtv」の2つがあればバックアップはOKということでしょうか?(要検証)
あとは管理フォルダ内のファイルがどのような役割を果たしているのかはっきりすれば、特定の番組だけをピンポイントでバックアップできるかもしれませんね(とりあえず録画済番組数に等しいbinファイルができているのは確認できましたから、録画順に対応している鍵ファイルか何かなんでしょう)。
突然ですが我が家のテレビは東芝のREGZA「42Z3500」です。こいつはUSBのHDDに加え、LANのHDD(いわゆるNAS)も接続でき、そこへ番組を録画できるという機能があります。初めはUSBで無難に動かして見たこのテレビも、早々にLAN接続を試し今ではメインをLANに変えています。
そんな中のこと、一身上の理由からNASとして使ってきたLINUX機をOpenSUSEへと変更しまして2ヶ月ほど運用して来たわけですが、ちょっと配置換えを行いまして。OpenSUSE君は隣の居間へとお引越しいたしました。
って、引っ越したの11日のことなんですがね。
そんな新居で彼は再びNASとしてREGZA君とお付き合いを始める...はずだったのに!
REGZA君は彼に録画してもらいたくないようです!(NASが録画先として認識されないんです...)
さて、困ったなといろいろやりながらのトラブルシューティングだったのですが先ほどやっと原因が判明しました。
REGZAには汎用LAN端子とHDD専用LAN端子とがありまして、いままではルーターにぶら下がる形で汎用LAN端子に繋いでいました。この状態だと、IPアドレスやらの通信を管理するのがルーターに任せられるため、あまり問題なく正常動作していたわけです。が、今回の接続形態はHDD専用LAN端子に、直接NASであるLINUX機を繋ぐというタイプで、ルーターは関わってきません。ある意味最も単純な形態で、同一サブネットに配置すれば認識されていいところ、問題が起きたためかなり混乱したわけです。
結論としてはREGZA側の細かい仕様によるもので、汎用端子と専用端子を同一のサブネット(192.168.1.1と192.168.1.2のように)に配置してしまうと問題が発生すると言うものでした(マニュアルの通信設定のところに小さく注意書きとして乗っていました)。通常の利用だとDHCP機能が使われていて問題なく認識するのですが(初期状態は汎用-192.168.1.xxx、専用-192.168.2.xxx)、DHCPによる動的IP割り当てが嫌いな私は固定IPを両端子に与えていたわけです。これがモロに同一のサブネット(192.168.1.xxx)だったというわけです。
この状態だと、REGZA側のDHCP機能でNAS側にIPが割り当てられないようでしたし、IPを固定させてみてもPINGが通らない(REGZA側が見つからない)という始末。結局、初期設定にならい、両者のIPアドレスを192.168.2.xxxと変更したところ、問題なくPINGも通りREGZAからも認識されたのでした。めでたしめでたし。
でも、IP変えたりしまくったせいか、sambaの設定からファイアウォールを再設定してもらわないとREGZAから見えませんでしたけどね。
これ以前の記事を見る >> アーカイブ