検索条件
全26件
(2/3ページ)
2011/11/06(日)春Ｍ(SpringM)のタイムスタンプ仕様の確認
2011/11/06 11:11
春Ｍの「日付の変更」ダイアログで変更できるのは最終変更日時。
さて、FAT32とNTFSでは記録精度が違う。春Ｍは古いソフトなので、FATの仕様を引きずっている。まあ現在でもFATファイルシステムはUSBメモリなど随所にあり、他のファイルシステムでもNASやバックアップ・ファイルコピーツール等々で同様に発生する問題でもある。
[NTFS]
作成日時:100ナノ秒単位で記録
最終変更日時:100ナノ秒単位で記録
最終アクセス日時:100ナノ秒単位で記録(ただし、1時間以内の同種のアクセスは無視)
参考:NTFSの最終アクセス日時 - B-) の独り言
[FAT32]
作成日時:10ミリ秒単位で記録
最終変更日時:偶数秒単位で記録
最終アクセス日時:1日単位で記録
参考:File Allocation Table
記録時間がUTCかローカルかって違いもあるけど割愛。
で、春Ｍの場合、「日付の変更」ダイアログでは秒単位まで入力可だが、内部で偶数秒単位に丸めている。また、表示も偶数秒単位に丸められる。ただし、更新の場合と表示した場合でちょっと挙動が違う。
[更新した場合]
2011/11/06 09:54:26に更新→2011/11/06 09:54:26.0000000で記録
2011/11/06 09:54:27に更新→2011/11/06 09:54:26.0000000で記録
2011/11/06 09:54:28に更新→2011/11/06 09:54:28.0000000で記録
切り下げっぽい動きになる。
[表示した場合]
2011/11/06 09:54:26.0000000→2011/11/06 09:54:26
2011/11/06 09:54:26.0000001→2011/11/06 09:54:28
2011/11/06 09:54:26.9999999→2011/11/06 09:54:28
2011/11/06 09:54:27.0000000→2011/11/06 09:54:28
2011/11/06 09:54:27.9999999→2011/11/06 09:54:28
切り上げっぽい動きになる。
さらにややこしいことに、Windowsのファイルプロパティ(秒まで表示)では、
[ファイルのプロパティ(Win7Pro 64bitで確認)]
2011/11/06 09:54:26.0000000→2011/11/06 09:54:26
2011/11/06 09:54:26.0000001→2011/11/06 09:54:26
2011/11/06 09:54:26.9999999→2011/11/06 09:54:26
2011/11/06 09:54:27.0000000→2011/11/06 09:54:27
2011/11/06 09:54:27.9999999→2011/11/06 09:54:27
切り下げっぽい動きになる。
春Ｍの画面上のソートはナノ秒まで含めて正確に行われるようなので、ちょっと混乱した。
なお、ActiveRuby1.8.7のFile.mtime(秒まで取得可)の挙動とかも確認してみたけど、基本Windowsのプロパティ画面に出てくる値と同じだった。本当はどのAPIを使ってるかも調べるべきなのだが、とりあえず今回はここまで。
調査は
Restamper
とか使った。こっちが信用できないともう知らん。
2011/11/03(木)TVTestで録画ファイル名が文字化け
2011/11/03 17:23
これはTVTestの問題で、条件は録画ファイル名に"%"(半角パーセント)を含むこと。
簡単な再現コマンドはこう。
>tvtest.exe /rec /recfile "test%test.ts"このとき出来るファイル名は"test%test.ts%"とかになる。パースと置換の問題なので、情報が落ちる場合もあり。率直に言うと、
"うたの☆プリンスさまっ♪マジLOVE1000% #12「迷子のココロ」 2011-09-17(土)_2400 _ＭＸテレビ_201109180000.ts"
が
"うたの☆プリンスさまっ♪マジLOVE1000% #12「迷子のココロ」 2011-09-17(土)_240%"
になってしまった。
で、結局のところバージョンアップで改善するようだ。現時点で最新のTVTest0.7.23を入れたところ問題が解消した。
更新履歴を見ても判別できなかったので、どこのバージョンで修正されたかは不明。
2011/11/03(木)ChromePlusで延々エラー
2011/11/03 11:38
TypeError: Error #1009: null のオブジェクト参照のプロパティまたはメソッドにアクセスすることはできません。 at com.amazon.d16g.utilities::JS$/call() at com.amazon.d16g.utilities::Logger$/_consoleAvailable() at com.amazon.d16g.utilities::Logger$cinit() at global$init() at com.amazon.d16g.core::Erm()かなりバカバカしい原因なのだが、自戒のためにメモしておく。
単にこのサイトがIE Tabで開く設定になっていた。
ChromePlusの問題だとばかり思い込んでいたため、Pluginの有効/無効を切り替えたり、Flash Playerを入れ替えたりしていたのだが、いっこうに解決せず？？？だった。そもそも、エラーダイアログのFlash Playerのバージョンが変わらない時点で気がつかなければいけない。
Flash Playerは開発版でない限りエラーを出さない(はず)。
2011/07/21(木)DNSを変えた(ZoneEdit->MyDNS)
2011/07/21 16:34
$whoisがこうなった。
[Name Server] ns8.zoneedit.com [Name Server] ns18.zoneedit.com↓
[Name Server] ns0.mydns.jp [Name Server] ns1.mydns.jp [Name Server] ns18.zoneedit.com経緯としては、Try WiMaxした際にdt8.jpに接続できなかったことに端を発する。WiMaxの自動取得DNSがdt8.jpをタイムアウトしているようなのでざっと調べてみると、ZoneEditの挙動がおかしい。ns18は応答を返すがns8は応答を返さなかった。
ここで色々調べてみたのだが、どうもアクセス元として特定IPアドレスなりドメインなりをns8ははじいているようだ(そうとしか思えない)。下はWindowsのcmd.exe。
>nslookup dt8.jp ns8.zoneedit.com
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 75.125.10.187: Timed out
Server: UnKnown
Address: 75.125.10.187
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
>ping ns8.zoneedit.com
Pinging ns8.zoneedit.com [75.125.10.187] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 75.125.10.187:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
と、こうなる。自宅(so-net配下)ではnslookup, pingともに通っていたので気づかなかった。
もしかしたら今までこのサイト見られなかったりしたのかも。ごめんなさい。
nslookup(dig)テスト【DNSサーバ接続・応答確認】
上記のサイトでもはねられる。
ということで元々zoneeditは挙動が怪しかったこともあり、できれば乗り換えたいと考えた。個人運営ながらMyDNSがそこそこ長期かつ安定的に運営されている(感謝！)ようなので特に挙動が怪しいns8.zoneedit.comを廃し、MyDNSをメインに差し替えることにした。
しかし、調べてみると現在フルドメイン登録可能なフリーのDDNSがほとんど無くなっている。EveryDNSはDynDNSに吸収されるようだし、概して有料化かサービス停止の流れにあるようだ。無料DDNSは広告プログラムとくっつきづらいのもわかるので、仕方ないかもしれない。
MyDNSもいつまでサービスを提供していてくれるかわからない。将来的にどうするか。
ドメインをVALUE-DOMAINに移管すればVALUE-DOMAINのDDNSが使えるのだが、VALUE-DOMAIN自体が今不安定な状況のようなので今回は控えた。VALUE-DOMAINはいつの間にか安くなっていて、汎用jpに関して現在のレジストラ21-domainと値段がほぼ互角のようだ。経営が安定していることが確認できればVALUE-DOMAINへの移管も手ではある(VALUE-DOMAINのDDNSも不安定という噂があるが)。
自前でネームサーバを立て、フルドメインでない適当なDDNSでドメインを取得し(たとえばxxx.dyndns.org)、それをDNSとしてJPRSなりに登録するという手もある(技術的には可能なはずだが認識に誤りがあるだろうか？)。
話を戻す。とりあえず、1月程度問題がないかどうか確認し、問題ないようだったらZoneEditを全廃することとする。
【追記 2011/11/10】
2011/11/07付けでmydnsに一本化した。
[Name Server] ns0.mydns.jp [Name Server] ns1.mydns.jpさらばzoneedit。
2011/07/14(木)Windows Updateのゴミファイルの削除方法
2011/07/14 14:25
頻出問題なので特に説明はいらないだろう。
なぜか消えないし、作られる場所も謎(書き込み可能HDDのドライブレター末尾直下？)。MSは何を考えているのだろうか。
ということで以下を参考。
WindowsXP 「amd64」「i386」フォルダ"アクセスは拒否されました"と表示される - NL - natural life -
フォルダオプションで"簡易ファイルの共有を使用する(推奨)"をオフにする必要がある。これをしないとセキュリティタブが出てこない。
セキュリティタブさえ出てくれば後は所有権をいじるだけである。
自分の場合はこれで削除可能となった。
2011/06/01(水)apache2がOut Of Memoryで落ちる
2011/06/01 18:07
Out of Memory: Killed process #### (****)半月～1月おきくらいで、上記メッセージがコンソールにあふれて操作不能・サーバ落ちとなる。****の部分はcgiの名前が出ているのだが、必ずしも同じものではない(adiaryが多いといえば多い)。
色々調べてみたのだが、
#apache2 -Vでみてみると、Worker MPMが動いている。topでみると255MBくらい仮想メモリを食ってるapache2プロセスが2つある。むむむ。
debianがなぜWorkerをメインに切り替えたのかは不明だが、preforkの方が実績がある上、うちのサイトではマルチスレッドで恩恵を受けるアプリはほとんどない。今回の件からもWorkerの方が考えなければいけない(設定しなければいけない)事項が多そうであるので、preforkに切り替える。
ApacheのMPM、「prefork」と「worker」を切り替える方法 – FlatLabs
まあdebianの場合、これだけでいいようだ。
#aptitude insatll apache2-mpm-preforkこれでmpm-workerが競合として検出され、最初に提示された解決方法がmpm-worker削除のみだったのでそれを選択。
また、設定ファイルもメンテした。httpd.confにはMaxRequestsPerChildが入ってたのだが、apache2.confのディレクティブには0指定されており利いてなかった可能性が高い。メモリリークが積まれていた可能性がある。
#diff apache2.conf.orig apache2.conf 103c103 < MaxRequestsPerChild 0 --- > MaxRequestsPerChild 100100回ごとにプロセス再起動することで、リークの蓄積を回避する。
#apache2ctl configtest #apache2ctl restartして、アクセスなど問題ないことを確認。
しばらく様子見。
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/29(金)rubygemsの挙動が変だと思ったら
2011/04/30 00:16
aptとちょっと違うのね。--remoteを付けないと、デフォルトではローカルのリポジトリを見に行く。うーんhelpに書いてあるんだろうけど、わかりづらかった。
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
何度か計り直したが、ある程度安定したようだ。蟹め。