備忘録。
環境を再構築した関係で、REGZAの録画先HDDもまた変更がありました。
例によって例のごとくファイルコピーでバックアップを移し変えたわけですが、なぜか共有先を検索できないとエラーが返ってきます。「なんか前に見たなあ、この状況」と、記憶をたどりたどり試行錯誤したところやっと思い出したので、今後のことも考えてちょっとメモ。
共有先のディレクトリに「lost+found」フォルダがある場合、REGZA側の検索時にエラーが発生します。問答無用で削除しましょう。
ということで、とある日に帰宅するとブルースクリーン吐いてwindows2000君が死んでいました（注：パソコン使用していない時間はスタンバイ状態です）。
「またか」とたいして気にもせず再起動しましたが、いつまでたっても起動画面にたどり着きません。ここで初めて「え？」となりまして、いろいろ試して調べたところ、システムのレジストリが破損したらしく読み込めないで止まっているようでした。
NortonGhostで書き戻すのが常套な状態だったのもあり、レジストリのバックアップなんかはさすがに取ってませんでしたし、回復コンソールでの修復例も試して見ましたが見事にいろいろなくなってる状態にしか戻らなかったため、お手上げ状態に。かといってGhostでスナップショットを取ったのももう2年前の状態で、その間いろいろ適当に追加してたこともあり、戻しては見ましたが収拾がつかない様子で、しょうがない（というか前から覚悟してた）ので再インストールからやり直しました。
すでに3度ほどかけて再セットアップの計画書をテキスト保存＆必要ファイル群収集していた実績があるため、差分／修正個所を検討するだけして再インストール開始。少し前にhfslipというツールで修正パッチやらいろいろと統合してインストールディスクを作っていたのも幸いして、以前よりもスマートなシステムになって帰ってきました。
この機会に旧来からの問題点が何点か解決／理解できたのもあり、まあそう悪くはないことではありましたが...急にレジストリが壊れるってなんじゃい！
ここ1年足らずでHDDは何度か壊れる、システムは壊れるとずいぶんな年ですね！
そんなこんなで、「さみだれ」8巻買ってますが、エントリは後日。
最近はどっぷりと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」の２つがあればバックアップは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から見えませんでしたけどね。
ぼさっとしていたら、早くもひと月が経過しようとしてます。
どうも懸念事項があると、他に回す精神的余裕がなくなる性質で...こうして常態化して開店休業になるのがいつもの流れなので、気を付けたいものです。
今週は頭からLinuxと格闘していました。
というのも、ファイルサーバー機にTruecryptという暗号化ツールを入れようとしたところ、怪しい挙動を見せ始めたから再インストールを試みていたんですが...結論から言いますとツールのエラーは通常のものだったようで問題じゃなかったようです。ただ、HDDに物理的なのか論理的なのかわかりませんが、致命的なエラーが発生していたようでファイルが読めなくなってたり、再インストールで途中に止まったり、ファイルは存在しないにも関らず表示されていてどうしても消えなかったりと怪しさ満点。
ここまでに
これくらいで2日ほどかかりまして。
仕方ないので3年ほど薄く付き合ってきましたVineLinuxにおさらばをする決意を固めました。
備忘録として。flv動画の画像連番保存方法。
これで画像連番で出力可能。ただしpng形式でもかなり容量食うので注意（512*384の10分動画で8GBくらい）。
