2011/05/16(月)adiary編集画面のカーソル消失問題(Chrome系ブラウザ)
2011/05/16 10:32
[参考]
中級プログラマの自宅でPHP ブログ Ver.2.25：textarea関連の修正
Chrome狙い打ちのハックがないようなので、
$diff satsuki.css.110516 satsuki.css 622c622 < padding: 0px 4px 0px 0px; --- > padding: 0px 4px 0px 2px;とりあえず暫定でパッチ入れてみました。
直ったけど悲しい。
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上に立てるあたり。これもライセンス的にどうなんだろう…… まあ検討はしておこう。時間かかりそうなので、実験的にやるにしてもかなり先の話とする。