2011/05/03(火)PT2 0byte録画対策
2011/05/03 13:15
[発生条件]
色々実験して、条件を確定した。以下の条件を満たすときに確実に発生するようだ。ただし、全0byteがこれに該当するかどうかは不明。
(1)休止(S4)・スタンバイ(S3)からの復帰後に発生。
(2)休止(S4)・スタンバイ(S3)に入る直前にRecTest.exeがtvrockターゲットとして起動している。
(3)休止(S4)・スタンバイ(S3)復帰後に、残存するすべてのRecTest.exeを終了させずに録画開始。
(1)を満たさないとそもそも発生しない。(2)はRecTest.exeが起動してない限り問題がなかった。TVTest.exeに関しては未テスト。(3)はすべて終了させると問題がなかった(ただし、タスクマネージャやTskillなどの強制終了ではダメ。devconなどでPT2を再起動してもダメ。)。
[原因?]
以下予想。PT2は元々複数プロセスからの共用は禁止ということだが、4つのチューナを個別に扱えるように(たとえばRecTest4プロセスから)dllが吸収している。だが、ドライバ、あるいはボード側仕様により休止・スタンバイした際にはすべて別プロセスと見なすようになっている。そうすると、使用中のインスタンスがある限り起動中のRecTest.exeも、新しく作ったインスタンスも別プロセス扱いでチューナを使用できない。
正規の終了手順の際には、RecTest.exeがデバイスにインスタンス解放コマンド(UNREGISTER_STOCK_INSTANCE?)を送っている。これで使用中のインスタンスをすべて解放すると、改めて復帰後のプロセスがインスタンスを取れるようになる。
と想像すると、tskillしたあと、dllから全インスタンスを解放するようなプログラムを書いて復帰時に実行すればいいような気がする。が、今回時間が無くちゃんとdllの中を読めていないので暫定対策をしたい。
[対策]
(1)RecTestの起動コマンドに/recexitを付けたところ、録画終了後にプロセスが残る頻度が減ったようなのでこれでまず暫定対策とする。
(2)上記でダメなら、(かなり終局的な方法だが)録画開始前の復帰時刻に余裕を持たせて「復帰後必ず再起動」を実行する。ここら辺はrestarterとかsuspenderとかが実績ありそうなのでやるなら簡単そうだ。
とりあえず対策(1)で様子を見ることにする。
実際、デスクトップ機で通常運転する限りRecTest.exeが残存している状態で休止・スタンバイするのは異常ケースではあるはずだ。従って、頻度はかなり落ちるはずだがどうだろうか。
2011/04/24(日)Win7 -> WinXPファイルコピー問題
2011/04/24 11:01
環境は、
[コピー元]
メインPC: Windows7(64bit)
[コピー先]
サブPC: WindowsXP SP3
デフォルトsmb経由。
[症状]
・エクスプローラからなら、ネットワークエラーダイアログが出て「アクセス中に問題が発生しました」となる。
・fire file copyからなら、「指定されたネットワーク名は利用できません」となる。
[発生時期]
メインPCをWin7(64bit)に入れ替えた時期か、サブPCのM/Bを替えてNICをRTL8111Eにした時。
さて、確定で切り分けまでしなかったのだが、どうも【解決】ファイル共有での遅延問題
これと同じ問題のようだ。
現在メインPC・サブPCともNICをRealtek RTL8111Eにしたので、ジャンボフレームを共通でMTU=9KB(MAX)としていた。だが、例の問題を思い出すと(Win7でもsmbの仕様が変わってないのなら)、9KBをデフォルトブロックサイズ4356byteで分割すると、奇数回となり最終応答が帰ってこない。Win7のコピー・移動の手順内でリモートディレクトリのブラウジングが走り、その際にパケットが返ってこないとそのネットワークプレースを使えないと見なすのでは？(ちゃんとパケットキャプチャしなかったので想像)
そんなわけで、4536byte分割で必ず偶数回になるようなMTUを設定してやることにする。今回はジャンボフレーム指定できるNICなのでメインPC、サブPCともMTU=8KBとしてみた。
ワオ、解決。
ほかに試したのは、セキュリティソフト全落としで、これは特に変化無し。
ちゃんと検証するならジャンボフレーム4KBの時にどうなるかやればいいんだろうけど…… まあ今回はいいや。ジャンボフレーム指定できないなら、SizReqBuf指定してやればいいよね、きっと。
私が知る限り、これWindows SMBの実装中でもワーストクラスの仕様なのでいろんなところで引っかかってる人出てる気がするな。
[2011/05/10 追記]
上で色々書いたが、そもそもREALTEK RTL8111Eのジャンボフレーム周りの挙動がなんか変。Win7側への転送が極端に遅い。
■Win7(64bit) RTL8111E->WinXP(32bit) RTL8111E
(両者ジャンボフレーム=7KB MTU)
***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
Drive X:Drive Size 10MB
Disk Read Write RRead RWrite (KByte/s)
13650 451 46545 476 7130
Copy 2k 32k 256k 1MB (Operations/min)
0 0 0 0 0
Copy 2k 32k 256k 1MB (Kbyte/Sec)
0 0 0 0 0
■WinXP(32bit) RTL8111E->Win7(64bit) RTL8111E
(両者ジャンボフレーム=7KB MTU)
***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
Drive T:Drive Size 10MB
Disk Read Write RRead RWrite (KByte/s)
18551 32715 1446 39613 430
Copy 2k 32k 256k 1MB (Operations/min)
0 0 0 0 0
Copy 2k 32k 256k 1MB (Kbyte/Sec)
0 0 0 0 0
■Win7(64bit) RTL8111E->WinXP(32bit) RTL8111E
(両者ジャンボフレーム=無効)
***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
Drive X:Drive Size 10MB
Disk Read Write RRead RWrite (KByte/s)
13939 969 46757 901 7130
Copy 2k 32k 256k 1MB (Operations/min)
0 0 0 0 0
Copy 2k 32k 256k 1MB (Kbyte/Sec)
0 0 0 0 0
■Win7(64bit) RTL8111E->WinXP(32bit) RTL8111E
(Win7ジャンボフレーム=無効, WinXPジャンボフレーム=5kB MTU)
***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
Drive X:Drive Size 10MB
Disk Read Write RRead RWrite (KByte/s)
33864 62439 19284 46829 6904
Copy 2k 32k 256k 1MB (Operations/min)
0 0 0 0 0
Copy 2k 32k 256k 1MB (Kbyte/Sec)
0 0 0 0 0
ここで気づいた、再現性すらない。てことはドライバだな。
[現状Driver Ver]
Win7: 7.37.1229.2010
WinXP: 5.782.114.2011
調べてみたらWin7用の新しいドライバがあるようなので差し替え。
Win7 Driver Ver:7.37.1229.2010 -> 7.43.321.2011
■Win7(64bit) RTL8111E->WinXP(32bit) RTL8111E
(両者ジャンボフレーム=8kB MTU)
***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
Drive X:Drive Size 10MB
Disk Read Write RRead RWrite (KByte/s)
34890 47925 46757 38568 6309
Copy 2k 32k 256k 1MB (Operations/min)
0 0 0 0 0
Copy 2k 32k 256k 1MB (Kbyte/Sec)
0 0 0 0 0
何度か計り直したが、ある程度安定したようだ。蟹め。
2011/02/12(土)DN-UVC252C@Win7(64bit)
2011/02/12 21:57
ここら辺が詳しい。
iTブログ DN-UVC252C USBコンポーネントキャプチャ 購入レビュー
USBキャプチャーユニット「上海問屋DN-UVC252C」で【MHP3体験版初心者向け解説】狩りに生きる。ロアルドロスvs片手剣編アップしてみました: Log_南信便り(SeesaaBlog)
ここのドライバでいけるようだ。
VideoHome Technology Corp.
今のところ、PeCaTV2で快適に動いている。
2011/02/06(日)NASの255文字問題
2011/02/06 24:38
理由はWindowsXPとNAS(Linux, samba, VFS, ext3)のファイル名制限の違い。この制限とは以下のようなもの。
・WindowsXPは、Unicode255"文字"まで
・Linuxは(VFS制限が厳しく)、255"bytes"まで。
sambaの設定がunicode(UTF-8だったかな？)になっているとき、日本語ファイル名をそのままコピーするとLinux上では１文字3bytes扱いとなる。
そのため、比較的容易にWindowsで命名可能かつLinux上で255bytes制限を越えるファイルが作れてしまう(日本語のみであれば86文字以上～255文字以内)。このファイルがコピーに失敗することになる。
本録画システムでこのようなファイル名が生成される条件は、EPGでサブタイトルに番組のあらすじが入ってきた場合。今のところこれ以外の条件では発生していない。
しかし、こういうEPGが結構あるのでとりあえず何とかする必要がある。
さて、できればNAS側のファイルシステム側で吸収させたいのだが、どうも芳しい情報が得られなかった。fuse+NTFS-3gなら255bytes壁を越えられる可能性が0ではなさそうだがはっきりしない。VFS自体をどうにかしたいのだが、こちらは全く情報がない。うーん？
しかたないので今回はこのような長いファイル名は余計な情報が入っているものとして、拡張子前を切り捨てることにした。末尾に録画日付・日時が入ってるものは残して、その前を切る。
それをエンコード用のスクリプトに実装してとりあえず暫定対応。
Windowsのこの255文字ファイル名にはいろいろ悩まされる。UDFでもオーバーするから、DVD/BDにやけないとかもしょっちゅう。UDFはまあしかたないにしてもNASではなんとかしたい。解決方法はあるだろうか。
１案としては、Linux上にVMWareを走らせてその上でWindows+NASを立てる。しかし大仰すぎるし、そもそもHDDがホストOS透過して見えるのかどうかわからないし、このためだけにライセンスを消費するのはいやすぎる。
次案としては、Linux側の対応を待つ。VFSの対応が今まで行われていない以上、2.6のうちはかなり薄い気がするけど、いくつか255bytes overを許容するファイルシステムが出てきてるからある程度の時期にExperimentalなオプションとして提供されそうな気はする。
３案としては、Windows NASを立てる。低消費電力じゃないときついけど、ARMでよければすでに5W程度の端末はあるし、次代のWindowsはARMに対応するという。x86でもATOM, Fusionの次とか、nVidia APUあたりはかなり低消費電力になることが期待される。それでNASにする。
なんか大変なとこに触っちゃったなあ。
2011/02/06(日)リモートデスクトップ後、B-CASカードを認識しなくなる
2011/02/06 23:04
調べてみたら以下のようなことらしい。
「あったまいいねＴＶＲＯＣＫ」 - PT1 pt2仕様+FAQ
要するに、リモートデスクトップでつなぐと(仮に同じユーザでのログオンし直しであろうが)カードリーダを切断してしまうらしい。ホスト側ユーザの権限などには依存しない。また、クライアント側にも同じカードが刺さっていればこの問題は起こらない。自宅環境では今まで親機と子機両方にカードが刺さっていたので気づかなかった。
ノートPCにB-CASカード刺すのも厳しいので、とりあえずしばらくはUltraVNCで代用する。リモートデスクトップでつないでしまった場合は再起動で対応。
ローカルLANだとリモートデスクトップの方が圧倒的に快適だが、遠隔制御だとそこまで差はつかない。
他の方法だと、リモートデスクトップにパッチを当てるという裏技もあるようだ(複数ユーザが同時にログオンできるようになる)。ただし、ライセンス的にどうなのって話とtvrock自体が予約リストなどをユーザレベルで管理しているので、別ユーザログインもちょっともめんどくさい。
同一ユーザでログオンするのはさすがに難しいらしく、serverを使わないのであればかなりのハックが必要になるらしい(logon.exeをいじる？)。それこそライセンス的にどうなのって話になるのでこれは基本除外。
あとはうちの場合だとBonCasLinkでB-CAS配信サーバをLinux上に立てるあたり。これもライセンス的にどうなんだろう…… まあ検討はしておこう。時間かかりそうなので、実験的にやるにしてもかなり先の話とする。
2010/12/23(木)Reflex USB v2 -> SCR33XX
2010/12/23 15:35
Webに情報がたくさんあるので、下記通りにやればよい。
人の褌(仮): Reflex v2購入->SCR331に書き換えてみるテスト
[etc] Reflex USB v2を64bit Windows対応にしてみた 主にねとげにっき(･ω･)/ウェブリブログ
特にコメント無し。
2010/10/15(金)DMR-E85H -> PC(*.MPG化)
2010/10/15 21:12
DMR-E85Hは1層のDVD-R/RAMしか焼けない。したがって、VROかVOBかを取り込む必要がある。手元にRAMがあったのと、VROが比較的素直そう(実績有り。->.MPGリネームで再生問題を生じたことがない)なのでRAM経由で。
[DMR-E85H側]
- DVD-RAM１枚のサイズに収まらないものは分割をかける。
- 全ファイルをDVD-RAMに焼き、ファイルコピーでPCに移す。(VR_MOVIE.VRO, VR_MANGR.IFO, VR_MANGR.BUPで１セット)
- 焼いたファイルは消す。
- 複数のファイルをまとめた.VROはvro2split+vro2feで、自動的に->.MPGへ。
- 単独ファイルの.VROはvro2splitの結果を見ながら、手動で.MPGにリネーム。
- 分割後の.VROは手動で.MPGにリネーム後、TMPGEnc MPEG Editorで結合し、vro2splitの結果を元にリネーム。
- 作業後、VR_MOVIE.VRO, VR_MANGR.IFO, VR_MANGR.BUPのセットを消す。
vro2split, vro2feはこちらから。注意点として、vro2feはこの記事の作成時点でvro2split ver0.4の出力結果には対応していない。また、フロントエンドとしてはかなりしょっぱい動きなので、量があるなら自作する、少量なら手動でリネームを考えてもいいと思う。
2009/07/19(日)電源による消費電力差
2009/07/19 19:10
メインPCはサブPCよりも消費電力が大きいだけに、サブPCの時よりも消費電力の低減効果が期待できる。同効率値だとしても低減量の絶対値が大きいはずで、また電源は出力W数の1/2程度で効率最良となるように設計されることが多いため効率値自体も良くなることが予想される。
測定は恒例ワットチェッカー。
■換装前(DECA FSP400-60GLN) IDLE 109-110W PRIME95 FULL load 152-154W 起動中最大 149W 起動中平均 120-140W
■換装後(玄人志向 KRPW-V500W(Enhance ATX-0250GA)) IDLE 98-99W PRIME95 FULL load 132-132W 起動中最大 136W 起動中平均 100-120W起動中の最大値とか平均値ってのは、ワットチェッカーの更新周期とか主観に依存している部分もあるので注意。も一つ残念なことに、繋いでいるファンと止めているファンのちゃんとした接続構成をメモしておかなかったため、若干換装前後で構成が違うことがある。一応動いているファンの数が少なくなっていることはないはずだが、比較としてはよろしくない。
そこら辺さっ引いても、やっぱり違うなあという印象だ。
さすが80Plus銅クラスというか。平均10W、フルロードで20W近い差が出ている。サーバノートが12W位で動いてるわけだからほぼ１台分の差だなあ。
2009/03/27(金)電源を換えたので消費電力チェック
2009/03/27 23:27
その過程で、ちょいちょい消費電力を測ったので、メモ。
多分あとで追記する。
さて、計測対象としたのはファイルサーバや重いバッチ（つかエンコ）用に使っているマシンだ。消費電力を抑えられるようにそこそこ気を遣って構成している。欲張ってパフォもある程度持たせられるように、CrystalCPUIDで倍率傾斜もかけている。
まあデスクトップとしては低めに出来てる方かな。かつては、Unix OSをインストールしまくって遊ぶマシンだったのだけれど、最近そっちはあまりやってないのでx86である意義が薄れて…… まあいいやそれは今度。
さて本題。計測は全てsanwa supplyのワットチェッカー。とりあえず、Watt読みの値をそのまま信用する。タップ経由だけどまあそこら辺は無視できるでしょう。
[初期状態] CPU: Athlon X2 BE-2300 M/B: M2A-VM Memory: DDR2 2GB(UMAX) x1 HDD: WD WD5000AACS(500GB) DVD: Benq DW1640 Power: FSP400-60GLN VGA,LAN: On Board他には大きく電力食うものは無し。
さてこの状態で、
起動中最大: 80W タスク無し: 45-46W[CPUが0.8V 1000MHz駆動]さて電源を換装してみる。換装電源は、玄人志向 KRPW-V500W。Enhance ATX-0250GAのOEM（あるいは単に販売名称を変えただけ）品だ。元のFSP400-60GLNも一番得意な電力エリアでは80%以上の効率がでるという話なのだが、なにせこのマシンでは出力が低すぎる。ATX-0250GAは、
80 Plus PSU - Detailsを信じるなら低電力帯でも高効率、しかも80plus Bronzeだ。
で、換装後の計測結果。
起動中最大: 73W タスク無し: 39-40Wううむ絶対値ならわずかだが、割合で見ると結構差が出た。
input40Wエリアの効率に関してはスペックシートにもないのだが、
FSP Green PS FSP400-60GLN 400W PSU | silentpcreview.comこの記事を引くと、FSP400-60GLNのinput58Wでは効率69.8%。
この数字をそのまま当てはめるならDC側消費電力は、46W*0.698=32W。
逆算して、このエリアでのKRPW-V500Wの効率は32W/40W=0.80
うん、とりあえずいいんじゃないでしょうか。
ワットチェッカーの有効数字が２桁なのでこれ以上は詰められないや。
2008/10/25(土)復旧しました
2008/10/25 22:40
お恥ずかしながら、一部バックアップと＋Googleキャッシュよりの復旧と相成りました。
一応文字データは全て復旧したと思います。記事IDもほぼ以前の状態になっていると思います。ずれてるところはあるかもしれないですが……
文書の構造化や、画像の抜けはおいおい直していきます。
情報探してサーチエンジンから来た方、いつも読んで下さっている方にご迷惑をお掛けしたことをお詫びします。
顛末はまあ時間が出来たときにでも書きます。
といっても今回は大して面白いことはなかったのですけど。