あくまで私の推測であるが。
そのまえに、不具合の内容について、再度書いておく。
＊環境：
液晶テレビ SHARP LC-32J9
外付けHDD IO-DATA HDPN-U500K
で、録画機能を使用。
＊不具合内容：
外付けHDDに新しく番組録画すると、ひとつ前の録画番組が消えてしまう。
１：AAA、２：BBB、３：CCC （新しい順に表示）
に、新たにXXXという番組を録画すると、
１：XXX、２：BBB、３：CCC （新しい順に表示）
となってしまう。
ちなみに、さらにYYYという番組を録画すると、
１：YYY、２：BBB、３：CCC （新しい順に表示）
となる。
HDDを再フォーマットすれば直る可能性が高いが、
今ある録画番組はできれば消したくない。
ということで、（１）（２）でいろいろ試したわけなのであるが。
私の考える原因は、というと・・・
＊SHARP TVのバグ？：
録画に使っていて、不具合の出たHDDの中身を見ていて気がついたことがある。
録画番組を管理しているファイルとしては、
HDD1台につき、
AquosDB.db
Aquos.conf
だったかな？というたぶん設定ファイルと目次ファイルがある。
あとは、各番組（録画データ）1個につき、
20140619022955092.xxx
xxxは、拡張子を忘れましたが、3種類ある。たぶん
番組info、チャプタファイル、動画本体
だと思います。
で、問題は、拡張子以外の、その数字のところ。
2014-06-19-02-29-55-092
と分解すると、
[年]-[月]-[日]-[時]-[分]-[チャンネル]-[通し番号]
となっているようだ。
日時は、録画開始時刻。
チャネルが55というのはちなみにNHKBSプレミアムだと思う。
で、問題は、最後にある、３桁の通し番号だ。
これは、録画番組が消されても、通し番号は、どんどんインクリメント（増える）されていく仕様になっているようだ。
で、そうなると気になるのが、
「じゃあ、通し番号が999になったら、その後はどうなるのか？？」
普通は、こういう番号の扱いを含むプログラムを作る場合、オーバーフロー、アンダーフローに対する動作不良が起こらないように対策を講じるのは、F/W開発の定石なわけなのだが、私の所有するTVのプログラムでは、これに対する対策が行われていないのではないかと推測される。
事実として、
録画が勝手に消えるという現象が発生した日付以降、消えている筈の録画ファイル一式（３つセットのことね）が、すべてちゃんとHDD内に残っていたのである。
（その数30番組分以上！）
しかも！
問題の発生したと思われるファイル達の通し番号は、というと、
すべてが、
992
なのである。（なぜか999ではないのだが）
ということで、TV上のソフトというか、おそらくAquosDB.db内での管理を、3桁の数字をインデックスとして行っているのだろうと推測する。つまりこれがそもそもの原因と思われる。
録画の際、新しい番組の通し番号が、上限の数である992になってしまうので、DBの992の所が（というか、おそらくプログラム内のメモリ上につくるデータベースの所が）、古いものから最新のものの情報に上書きされてしまうので、**992という録画番組のうち最新のものしか認識できないということになっているのかと推測する。
最も簡単な対策としては、インデックスが992に近づいたら、録画番組のファイル名とデータベースの再構成を実行し、通し番号を振り直すようなメンテナンスを実行する（これは自動よりも顧客側に促して実行させるほうが良いと思う）というのが良いのではないか。
というのは、あくまで私の推測なのであるが、これが正しいとすると、
DBファイルの仕様が分かれば、自分でファイル名を振り直しして、DB再構成でもすれば良いのだが、仕様が公開されるはずもなく、私のHDDは、空き容量がまだ半分以上あるのにも関わらず、これ以上使う事が出来なくなっているのである。
最後に書いておくが、あくまで私の推測。
古いHDDの動作不良が原因、という可能性も、まだ残っている。
新しいHDDで同じことが起こるのか？？？
これを確認してみたい衝動にかられるが・・・。
いやいや、さすがに、992回も、録画を繰り返すなんて、そんな元気はありません。
0 件のコメント:
コメントを投稿