本日早朝にどうやらwindows updateの更新があった様子。
xpにvista、７と更新していて思い出した。
確か、知人はエンコ中にセキュリティアップデートが適用され途中で再起動していた、という話。
同じく７でエンコ中の身として気になったので、朝方PCを覗いてみたが再起動無くエンコの最中であった。
ふぅ。 
こちらでは今のところ確認できていないので必要有るかわからないが、エンコでフル稼働中のPCには下記は対策をしておいた方が良いのかもしれない。
Windows Update適用後の自動再起動を抑制する
一台はproなのでgpeditで対策がとれそうだが、それ以外の７はhomeなのでレジストリ変更で対策する必要があるそうだ。
今回必要なのはhomeに対してなので、レジストリでの対応を考えてみる。
<2012.03.15追記>
どうやらwindows7のエンコマシンには上記設定が必要なようである。
今朝の自動更新時には再起動がかかったらしい。 
TMPGEnc Video Mastering Works 5（以下TMPGE）の話。
推測であるが、編集画面でサムネイル表示を遅延無く速やかに行いたいのなら、ramあるいはSSDが必須では無かろうか。
メインで使っていたmurdoc cutterをram disk上のファイルに対して使うとすこぶる快適だったから。
しかしスピードは速くても比較的容量の少ない両者では少々現実的ではない。
ならばと、HDDでも早くなるようにと通常のTSファイルとTssplitterでHDのみを分離した物を適当に比較してみた。
２０分強の生TSファイルで3.5GB。
同上HDのみのTSファイルで2.8GB。
比較は最速送りで、先にサムネイル表示が途切れる、あるいは拡大画面が完全なコマ落ちを示すのを目視で確認という手法。
すごくアバウト。
まぁそもそも編集作業が感覚仕事なので、それで十分ではあるのだが。
コマのサムネイルといえども描画には違いない。
そもそものファイルサイズが違えばHDDの性能上違いが現れるはず。
実際、3.5GBの方は１０分あたりでサムネイルがフェードアウトした。
一方2.8GBの方は、ほぼ終わりの頃にフェードアウトした。
念のため再起動して改めてテストしてみたが同じ結果。
最速送り多用の場合、実用に耐えるのは推測通りHD化してファイルサイズの小さい方が良いことになった。
たぶん、ファイルサイズが極大化とか、ビットレートがより大きいほうが顕著にその違いが現れると思われる。
というより、最速送りが使いづらくなる。
さて、それはよしとして。
ところが、最近HDファイルを扱いだしてから、たまにマーカーを置いたとたんにハングするようになった。
生ファイル編集のときには無かった現象である。
必ず同じファイルの同じ場所で固まるというわけでなく、再現性がない。
コアアンロック中という要素はあるものの、それすら以前と環境は同じなわけで…。 
原因を求めるなら、やはりHD化かなぁ（自信なし）。 
さんざん生ファイルを扱ってフリーズしなかったのに、HD化を扱いだしたとたん止まるとなればやはり疑うのはHD。
仕方ないので、ファイルを読み込む際、編集せずに全て読み込んでから、一個一個編集が終わったたびに「プロジェクトを上書き保存」をするようにして、対処とした。
自動保存があれば良いのだが…。
まぁショートカットがあるので苦にはならないが。
HD化というのも善し悪しである。
<2012.03.14追記>
先日初めて生TSファイル編集でハングした。
となれば、HD化に問題があるとはいえない。
そもそもコアをアンロックしているからかもしれないし、ソフトの問題かもしれない。
ともかく、現状では読み込み時に編集作業なしにすべてを一度読み込み、「ctrl+S」で保存しながら１ファイルずつ編集作業しているが、これだとまだハングしていないし、例えそうなっても被害は最小で済む。
これが定石だな。
radeonでもgeforceでも結局ドライバというのが何かと問題を持ってくる。
以前にあったnvlddmkm.sysによる起動時のブルースクリーン。
スリープ使用の環境だと特段問題ないのだが、今日久しぶりに再起動をかけるとやはりほぼ半数回でブルースクリーンになる。
数日前に最新ドライバの通知が来ていたのだが、更新するつもりはなかった。
スリープなんだからしなくても良いのだが、心地よくないので一応クリーンインストールで最新ドライバ(295.73)を当てることにした。
適用後に５回再起動を繰り返してみたがブルースクリーンにはならず。
とりあえず問題解消だろうか。
３枚ディスプレイだとnvidiaの場合２枚差しになると思うのだが、これがいけないのか？
同じような環境のメインマシンも部品は似たような構成。
windows７だとだめでxpなら問題ない現状では、絶対そうだと断言できないものの、OSに関連する事象なのだろうか？
おかしくなったらクリーンインストールというのが今のところ、対症療法として有効か。 
画質の問題でhandbrakeでは満足行かない動画がある。
より良い画質にはより良いエンコードソフトということで調べていたところ、vectorに第１７回Vectorプロレジ大賞というのがあって、そこにTMPGEnc Video Mastering Works 5と究極動画変換 7というのがあった。
試しにやってみると、究極動画変換７（以下究極）の方はTMPGEnc Video Mastering Works 5（以下TMPGE）と比べて、エンコード時間は早くて良いのだが、どうもコマが間引かれているような感じに見えてだめなのだ。
一方のTMPGEは画質がとても良いのだが、設定が初心者には複雑すぎてよくわからない。
ともに画質は良くても、コマを間引いているような印象の究極は、どうせシェアウェアであるなら選択しづらく、結果TMPGEを選ばざるを得ないのである。
携帯プレーヤーでの再生がメインで、TVやPCでは再生しないと割り切れるなら、金額、エンコード時間からして究極を選ぶのであるが…。
ま、そんなんならhandbrakeでいいじゃないか、という話もあるわけで。
ともかくTMPGEを使うことにした。
PCはメインから退いて久しいphenom x3 720BE。
寄せ集めで作ったリビングマシンが、まさかこんな形で使われることになるとは思わなかった。
そんなわけでオーバークロックがどうとか、そんなの関係なくエンコードをしていたのであるが、ふとこれの昔を思い出した。
コアアンロックなしの状態で、3.5GHz常用だったこのCPU。（倍率変更＆電圧のみ変更で、ベースクロックはノーマル）
ならば、クロックアップした場合はエンコードにどれだけ影響があるのだろうか。
カレントクロックで2.8GHzの３コア。
23分の動画を変換。
もちろん条件はすべて同一。（TMPGEのプロジェクトとして登録）
クロックアップはマザーから変更。（倍率のみ）
***
1.デフォルトクロック 2.8GHz → ４０分
2.クロックアップ後 3.4GHz → ４６分
***
びっくりするほど早くなるわけではないが、エンコード対象が多ければその差は大きい。
きっと、HTTをメーカーpegasysが推奨しているので、びっくりするのはcore i7に変更した場合なのだろうな。
ちょうど現在はivy bridgeが出るだろう４月までわずかなので更新するつもりはないのだが、ivyの素性次第では候補になりそうだ。
もちろんそれならメインをi7にするのが順当だろうが…。
なお、以前の常用クロックである3.5GHzではないのは、電圧変更が機能していないため。
マザーが廉価なものであるので、仕方のないところだ。
加えて電源はいつのものかもわからないほどに古い。
何せSATAコネクタが一つも存在していないうえ、ATXが20ピン。
たぶん１０年くらい前のものだ。
エンコの時間短縮を至上命題とするなら、現状、電源とマザーは変えた方が良いだろうし、おごるなら編集の操作時のためにSSDも欲しいところだ。
メインマシンで編集作業時（別ソフト）はramが13GBあって大変快適なので、メモリーの安い現在、同じようにramで編集というのも選択肢に入りうる。
でもやっぱりエンコのためだけに何かを新調するというのは誤りだろうな。 
ちなみに余談であるが、コアアンロックするとprimeが通らないだけでなく、IEも起動できず、エンコードは変換後の動画にノイズが入る。
この720ははずれなのである。
windowsの起動は可能なのにソフトがだめというあたり、たぶんメモリ周りに欠陥があるためと思われる。
他に所有のCPUでアンロックができる物は通常通り使えることを考えると、コアアンロックが祭りを演出していた頃を思い出すにつけ、本当に使えないからx3として売られることになった石なのだと思われる。
＜2012.02.26追記＞
さて、肝心な情報が間違っていることに今気づいたので、追記情報とともに修正。
クロックアップしたのにエンコード時間が増えるなんておかしいだろう
知人のAMD ６コア（型番失念だが、x4アンロックではない）が同じ設定で等速よりもほどほどに遅れる程度なので、たぶんそれならばコア数を稼いだ方が早いだろうと思い早速実験。
720BE → Athlon 2 x3 445
これは他マシンで４コア化できていたもので、たぶんこのマザーでもいけるだろうと、その実成功。
primeでのテストも問題なし。
そんなわけでエンコ環境は
３コア → ４コア
になった。
クロックはデフォルトの3.1GHz。
同じ条件で、
***
1.デフォルトクロック 2.8GHz → 46分
2.クロックアップ後 3.4GHz → 40分
以上３コア(720BE)
3.コアアンロック４コア化 3.1GHz → 38分
以上４コア(445)
***
ごくわずかに早くなった。
あまり変わらないが…。
やはり６コアにはかなわない。
しかしメインの６コアをおごるなんてとんでもない。
変わらないなら720BEでいいじゃないかって話だが、クロックアップすると電源の容量とその質が悪いらしく、kernelpowerエラーでブルースクリーンとなる。
電源買うのもなんだかばからしいし…。
結局また720BEは退役の憂き目にあうこととなったのである。
＜2012.03.03追記＞
６コアの情報をいただいたので一緒に掲載。
OSがwindows7 64という以外はほぼ構成が違うので厳正な比較にはならないが、大まかにその傾向がわかると思う。
***
1.デフォルトクロック 2.8GHz → 46分
2.クロックアップ後 3.4GHz → 40分
以上３コア(720BE)
3.コアアンロック４コア化 3.1GHz → 38分
以上４コア(445)
4.1090T デフォルト3.2GHz → 36分
以上６コア
***
え
どゆこと？
あまり時間が違わない…。
＜2012.03.05追記＞
1090TをOCして比較してくれたので、参考まで。
5.クロックアップ3.6GHz → 34分
変わらない…。
前提条件が確認できていないのだが、違うファイルを試したのかもしれない。
よって、一連の結果とは別に記載。
で、一番の違いに気がついたのだが、1090Tにはgeforce 460が乗っている。
そして、cuda有効。
一方のマイエンコマシンは880Gオンボードグラフィックであり、当然cudaは無い。
ここにオーバークロックによる時短効果の無効となる原因があるのではないだろうか？
＜2012.03.09追記＞
使用比率cuda75% cpu25%
今度はGPUをOC 700→875
***
4.1090T デフォルト3.2GHz → 36分
5.クロックアップ3.6GHz → 34分
6.CPU&GPUクロックアップ → 28分
以上６コア
***
以前時短に結びつかなかったのは、cuda設定に不備があったからだそうだ。
これで随分と等速に近づいた。
問題はこれで消費電力がどれほど増大したのかというところだが…。
今度はコアアンロック４コア化445の話。
電源を別に変えてOCチャレンジ。
バススピード(HT自動追従)217 にクロックアップで 3.36GHz。
電圧(メモリ、CPU、HT各々）を若干盛る。
***
1.デフォルトクロック 2.8GHz → 46分
2.クロックアップ後 3.4GHz → 40分
以上３コア(720BE)
3.コアアンロック４コア化 3.1GHz → 38分
7.コアアンロック４コア化 3.36GHz → 35分
以上４コア(445)
***
電源を新調してまでOCするほどに時短の意味はない、コストパフォーマンスの意味で。
結局はコアアンロック４コア化デフォルトクロックでのエンコに落ち着いた。
以上。
＜2012.05.16追記＞
ソフトの使用（負荷）状況に合わせて、メインPCの960Tをエンコードマシンに移植した。
prime95が完走する６コア化CPUである。
エンコードが早くなることを期待してチェック。
いつものサンプル動画を試してみる。
***
8.デフォルトクロック６コア化 35分
***
どうやら時間としては変化がない。
ただし、CPU使用率（負荷率）はこれまでの７０％前後から５０％前後に減少。
であるならば、バッチ処理で二つのファイルを同時にエンコードすればトータルで処理速度アップだ。
このサンプル動画はデジタルでエフェクトも少ないアニメで、色数は多くなくシーン変化も少ない。
似たようなエンコード対象をバッチ処理（２バッチ）で試してみると、時間は38分で終了した。
これは対象が特殊なので最良の結果（約２倍）がでたが、特殊な条件とはいえ早くなったのは事実である。
一方、アナログや映画なども試してみた。
こちらはやはり１００％の使用率で変化なし。
時間の方は１時間２８分から１時間２分とかなりの時間短縮となった。（元ファイルは４５分弱のドキュメンタリーもの）
以上の結果からすれば、CPU使用率を参考にバッチ（並列）処理を活用すれば効率的に時短を達成できる。
これまでは２４時間稼働で電気代無視であったが、これなら夜間電力時間内で処理が完了できそうだ。
電力の上昇分（1.3A→1.6A)を加味しても６コア化の方が効率的と言える。
ちなみに、ワットチェッカーではなくクランプメーター（精度・分解能が低いもの）で計測しているので前回とアンペア数が違うが、大まかな上昇率はわかるので参考値として記載しておく。
Windows 7, Vistaのサポート期間が延長された・・・？
vista ultimate を使っていて、2012年4月サポートが終了するというので半年くらい前ずいぶん悩んだ。
windows8が出てくればちょうど入れ替われると思っていたものの、今現在８の発売は12年後半か13年ということらしい。
正確な時期は流動的だろうが、少なくともvistaのサポート終了後の話になりそうである。
そうなればアップグレードというのは不可能。
というのも、ネット接続や外部とのファイルの交換がなければ、つまりは完全なスタンドアローンであるなら８が出るまで我慢できたろうがそんな使い方は期待できない。
そんなわけで延長サポートが保証されているbusinessに入れ替えたわけだ。
ultimateからbusinessへ入れ替えるのが簡単であれば恨みはないのだが、もし上記の記事が本当であれば…。
何がしたいんだ、MS。
せめて半年前に多少の示唆はくれよ。
まぁ、それとて記事が事実ならね、って話。
<2012.02.20追記>
【速報】米MSが個人向けVistaのサポート打ち切りを撤回、2017年まで延長
さて、真偽のほどはいかに、ってことなのだが。
プロダクト サポート ライフサイクル – 製品一覧
昨今のハード的にvistaで重すぎるということも無くなったわけで、ビジネスだけを延長サポートで残すのならいっそ、ってことだろうか？
OSを強制的に更新させるのではなく、ソフトの対応も考えて好きなバージョンを選んで使ってくださいってことか？
歓迎であるが、それは終了予定２ヶ月前に言うことではないぞ。MS。 
DVDもBDもそうだが、どうにもディスクのままだとソフトの使い勝手が良くないのである。
マウスホイールボタンでのシークは慣れてしまうと、その機能が無い場合どうしようもなく不便である。
そんなわけでもっぱらsmplayerなのである。
その結果が前回の話題、BDに対するmakeMKVなのだ。
今回はDVDの方。
こちらは表題のソフトをもう延々と使い続けてきた。
といってもそう出番のあるわけでもなし、一連のWHS関連によりクリーンなOSとなってしまったXPでいざ使おうと思うと、完璧に使い方を忘れてしまって…。
正確には「使い方」ではなく、「設定」であるが。
DVD Decrypterを使ったDVDのコピー
>オプションを変更
>OptionのFile Splittingをの選択をNoneにします。
>これでファイルのコピー時に、ファイルを一つにまとめてくれます。
上記引用。
ファイルを一つにまとめてくれる方法を完全に忘れてしまっていた。
この設定でfileモードの際に、以前と同じようになった。
そして一つになったVOBファイルをHandBrakeでmkvファイルに変換すれば大変快適な生活を享受できるわけである。
まぁ忘れんぼ対策記事、ですな。
テレビ放送のコピー制限もそうだが、BDの再生も制限があって本当にうっとうしい。
購入したものであっても制限があるなんて、使いづらいというのはなんとかならんですか。
再生ソフトの使いづらさ。
smplayerを常用しているとpowerDVDでの再生が重くて、シークが不便で、もういやなわけですよ。
かといってpowerDVD以外でBDを再生する方法と手段を持たないし。
困った。
で、リッピングできればsmplayerでも便利に使えるはず。
調べてみると現在いくらかソフトが存在するようだ。
ブルーレイをリッピングできる無料ツール：MakeMKV beta
makeMKV。
早速使ってみるとリッピング＆MKV変換ができた。
で、さらに試してみると確かにsmplayerで再生できたのだが、できたファイルのサイズが１０Gオーバーと大きすぎるためか、画面がカクついて、シークも引っかかりがあってどうにも不便である。
生ファイルのままではシークを伴う再生が不都合で、エンコードでファイルを小さくするという対処をする必要がある。
ただ垂れ流してみる分には問題ないし、そもそもそれならBDのまま見ればよいわけだし…。
ここまでしてようやく不満なくみられるようになる。（逆に言えば、エンコなしで快適なシーク＆再生は難しい）
ということはつまり、BDの情報量に対して読み込み時間というのがついてきていないというのが、シークの際の不便であり最大のネックなのだろう。
正直BDというのは不便で仕方ない。
次に本題。
著作権保護といえば何でも許されるのか？という気がしてならないが、ともかくこれでようやく制限であるBDのプリントスクリーンが実行可能となる。
スナップショットがほしいだけなのに、BDを購入しているのにも関わらず不満を強いられるというのは納得がいかない。
色を拾いたいだけなのにこんなにしなければならないなんて、BDは買いたいとは思わせない仕組みだ。
なお、makeMKVは３０日の試用制限があるらしい。
更新のためのキーがあるそうで、下記チェック。
五十六億七千万の夜
さっぱり理由がわからないままであるが、スリープを基本としwhs2011にて自動バックアップされていたwindows7マシン、それが年末に突如スリープしなくなった。
こういう時はとりあえずその前後での違いを調べる。
新たにインストールしたのは、年賀状ソフト（そういうジャンルあるのか？）、他にはwindowsアップデートの数点。
ハードウェア構成での違いはなく、関係あるとすれば上記だと推定。
しかし「プロセス」や「更新」の詳細をみても取り立てて問題のありそうな動作は見つけられず。
次は「電源オプション」。
スリープへの移行時間を１分にして、条件を組み合わせて試す。（以後１分でスリープに入るか検証）
これまで正常動作していたのだし、そもそもここをいじった記憶はない。
そんなわけで当然（？）ながらスリープに入らず。
他に原因は何だろうと考えれば、そういえば年末か年始で無線LANを交換したと思い出した。
既述なので詳しく書かないが、特別必要もなく無線LANを交換したのだが、これの設定が悪かったのかもと思いチェック。
「デバイスとプリンタ」のところで、プリンタの電源がオフの状態で若干変な動作を見せたものの、プリンタを削除してもスリープに入らない。
これも違う。
無線LANをネットワークから切り離してもやはりだめ。
これも違う。 
他パソコンの事象が自マシンと同じというのは少ないと思うが、調査に際して何か有益な情報もあるかもしれないとネットを回る。
すると下記のようなものを発見。
Windows7 スリープへ自動移行しません。__以下に診断レポートを載せましたが、「srvnet」が自動移行しないように制御されている様です。__何か対応策ありましたらアドバイスをお願いします。
powercfg -requests を実行してみる。
稼働中にたびたび試してみるが、srvnetがたまに出てくる程度で、毎回表示されるわけではない。
つまりこれも違うようである。
しかし一方で、デバイスマネージャーでネットワークカードを無効にして様子を見ると、スリープになったりならなかったり。
どうなってんの？
ソフトですか？
そういえば以前から nvlddmkm.sys によるものとおぼしきブルースクリーンがたびたびある。
基本、スリープがメインなので遭遇することはないのだが、再起動の時は約半数（５割前後）で上記BSODが出る。
これは結構な頻度だと思うが、スリープ常用なので気にしなかった。
8600GTとGT210の二枚差しだと問題でもあるのだろうか？
ネット上では古いドライバを書き換えれば良いと書かれていたので以前更新しておいたのだが、相変わらず止まる。
２枚差しがいけないのかと、もはや当初の問題とはずいぶんかけ離れた感があるが、ものは試しと即実行。
一枚だけにして起動。
これだとスリープに入る。
数回しか試してないのでこれで原因確定とはならないのだが、もしGPUであるならばと、ドライバをバージョンダウンしてみることにした。
nvidiaから280.26をダウンロードしてインストール。
今度は２枚差しの状態でもきちんとスリープに入る。
なぜ？
最新の285.62にするとスリープにならない。
なぜ？？
このドライバ、以前から入れていたもので、リリースから２ヶ月程度経っている。
それが突然？
本当にドライバか？
一緒に入るソフトウェアもバージョンアップされているし、もしかしたらこっちか？
もぅ何が何だか。
だが、試しで同PCに新規インストールしてみたが、最新ドライバでも年末のアップデートがあたると何故だかスリープに入らないという同じ状況に…。
他にそんな情報もないので当てにならないが、nvidia関連が悪いのかもしれない。
といっても、それらしいものをプロセスからバンバン止めてみてもスリープには入らなかったし、どういうこと？
windowsの更新か？
最終的には、nvidiaの最新ドライバをインストールするときに「カスタム」でクリーンインストールを選択すると、今のところ最新ドライバでも２枚差しでもスリープに入る。
3D visionが怪しい気もしないでもないが、確証なし。
見えない敵って感じで、もやもや満載。 
<2011.01.13追記>
現状問題なくスリープへ移行するようになっている。
ただ、以前の突入時はモニターが消えると同時にHDDアクセスがあってから、電源ランプ点滅、間を置かずに電源オフとなっていたのだが、今は少し違う。
突入時、HDDアクセスがあるのはあるが、アクセスLEDをわずかに光らせだらだらと１０秒弱動く。
整理すると、突入時電源ランプはまもなく点滅し、その段階でモニターが消えHDDがアクセスし続けると、やや間があって最後に電源オフとなる。
時間的には５秒程度→１０秒強、という感じ。
無線LAN経由でプリンターを使用するケースが関連あるのかと思って、試しに印刷中にpowercfgを試したのがこれ。
srvnetとは異なるのでやはり違うのだろう。
もうしばらくは様子見か。
さて、この話は以前あったxpとwhs2011の話に深く関係するので「whs2011 と xp sp3 その4」とするのが帰結となるので良い気もする。
だが、実際にはデフォルトのxpだと外部(LAN)との接続と再接続に関してvistaや7とは違う挙動を見せた、という結果に至ったので別としたい。
製品レビューや評価といえば商品選びで参考になる内容であり、購入前にはチェックしておきたいことである。
しかし、EADSシリーズのように買ってしまってからはチェックしないというのが、自己の行動をチェックした感想である。
それはまた普遍的なことであるのかもしれない。
一方で、何か不具合があった時は商品に対する再評価が必要だという話。
私は無線に対して絶対の信頼というものを持ったことがないので、無線LANを使い始めたのはここ３年くらい。
必要に駆られての導入であった。
そして当初大変苦労しながら導入したのがプラネックスの超小型ルーターであった。
これがまた設定で大変な目にあったもので、設定を出しても再接続に難があった。
ただルーター電源の再投入で回避できたので、それはそれとして使っていた。
しかし、使ううちに不便に感じ、改めて同じ会社のMZK-WNHというのを買ってみた。
これは前回のものに比べると使いやすかった。
設定も問題なく完了し、しばらく使った。
そして、whs2011導入に前後して、さらにもう一台WNHを導入した。
この時の設定がいけなかったようだ。
ネットワーク上にはバッファローのスイッチングハブ４台とWNH２台がつながり、さらに枝葉のようにPCが連なる。
最後に導入したWNHがwhs2011マシンとの通信を邪魔していたようだ。
これにより、サーバに乗せた動画の視聴に随時切断の不具合、ファイル転送中のコネクション喪失が起こっていた。
というのも、ファームウェアのバージョンアップをしたのがだいたいwhs2011導入の時期だった、はず。（ファーム公開日がwhs2011のローンチとかけ離れて遠くないから）
1.29から1.31へのファームアップで取り立てて問題は起きなかった。
しばらく問題は発生しなかった、はずである。（全く自信なし）
だが、改めて設定を煮詰めてみようとWNHの設定画面に入ろうとすると、認証画面が出たり出なかったり、その後の設定画面が表示されたりされなかったり。
２台とも1.31だが、不調。
実際にネットワークからWNHを取り外すと今までが嘘のようにネットワーク切断が起こらない。
試しに動画を数時間垂れ流しで再生してみたが、不調の時の挙動がみられない。
ファイル転送もばんばん試すがばんばん流れてくる。
再度ネットワークに接続すると確かにファイル転送が途中で止まる。
犯人はこいつだったようである。
スイッチングハブは全てバッファロー製品だったので、すかさず無線LANもバッファローへ変更。
カカクコムで評価の高いWHR-G301Nを導入することにした。
購入してから初めてWNHの評判・レビューというのを見返してみる気になった。
するとどうやら1.31ファームでは問題があるようだ。
WNHのリセットを数回繰り返しなんとか1.28へバージョンダウンして接続すると、設定画面表示も快適で問題なく、またネットワークを邪魔することなくファイル転送も動画再生も使えた。
きちんと動作するならバッファロー製品を購入する必要もなかったわけだが後の祭り。
1.31はほぼ間違いなく黒だと思われる。
WNHの設定画面で表示がすぐに更新されない時はコネクションを喪失している状態なのだと思われる。
1.31は使わない方が得策だ。
パソコンのBIOSでもむやみやたらと最新版へ更新すると不調を来すことがある。
ファームもどうやら同じようである。
初期ではシマンテック、次にウイルスバスターときて、現在はNOD32である。
昔ウイルスバスターでメールのウイルスを検知できず、１台がクラッシュ。
他で使っていたNOD32で試しに読ませてみるときちんとウイルスに反応したので、以来信頼を寄せて使い続けている。
公開日の12/15にメインのXPマシンをv5へアップグレードすることにした。
ところがインストール途中でBSODとなり、これが何度やっても同じ結果に。
0×00000007だったか？（うろ覚え）
他のPCでは問題なくすべてV5へアップグレードできた。
でも、特に問題を感じることもなかった。
ポップアップなどほとんどなく、静かに使えるのがなかなか好印象だったのに、V5ではメディアを挿入したらポップアップするようになり、少々鬱陶しく思っていたから。
それは設定でどうとでもなる話だろうが、アップグレードできないことに対する言い訳としてしばし存在した。
で、昨日HPを訪れてみれば、下記の注意書きがあった。
>2011.12.21 ESET Smart Security / ESET NOD32アンチウイルス V5.0をご利用いただく際によくあるお問合せについて
【ご参考３】 インストール時にEtron社製USB3.0ドライバとの競合にてブルースクリーンが発生する
まさにこれだ。
asrock 870 extreme 3 R2.0 を使っているのだが、usb3.0がETRONのチップである。
同じような現象が相当数あったのだろう。
usb3.0のドライバを更新すれば良いらしい。
だが、ETRONのサイトには表記がない。
というか、firefoxではうまくページが遷移しない。
ドライバダウンロードのページに行けば、「no file」みたいなことを言われる。
pdfの方にv0.105.zipが入っていたので試しにダウンロードしてみたものの少々心配。
改めてasrockのサイトで調べるとリンクがあって、v0.104.zipが張ってあった。
しかもちゃんとWHQL版である。
よくあるご質問と回答
そちらをインストールした。
つうか、わかりにくい。
製品の方の「ファイルダウンロード」から落とせるようにしてもらいたい。
しかし、これでアップグレードは問題なく終了。
なんのこっちゃない話。