site logo
新規投稿
*オープンクローズ
 + 
#
thilmera project - forum
不具合
[Closed] 0ch 0b176 Rev.1 DEV5が時々落ちる
2022/12/07[2]ANACOSTIA
不具合
[Closed] 0ch 0b176 Rev.1 DEV4で応答なしになる
2022/12/01[5]ANACOSTIA
不具合
[Closed] Display Setのメニューに不具合があります
2022/11/09[9]ナセル=フェレロ
報告
[Closed] サウンド系表示が乱れる
2022/11/07[1]-m-
不具合
[Closed] cpu温度
2022/10/30[5]HD
質問
[Closed] 0b176 更新後のCPU使用率増加の要因について
2022/10/19[12]Gonbe
報告
[Closed] 通信量カウンタのByte設定
2022/10/17[2]AKA
報告
[Closed] Ryzen 9 7950X + X670Eでの動作報告
2022/10/16[11]327
不具合
[Closed] thilmera7のCPU CPUマルチの使用率
2022/10/10[3]フォス
質問
[Closed] CPUの平均温度が感覚と合わない
2022/10/03[9]sleepyF
質問
[Closed] スリープについて
2022/09/07[9]retsam
要望
[Closed] 月齢グラフィカル部の向きについて
2022/09/05[2]ぼんこり
要望
[Closed] 月齢表示部の文字かぶりについて
2022/09/04[5]ぼんこり
要望
[Closed] シルメラのウインドウについて任意位置での固定設定の追加
2022/09/04[7]Ginbe
報告
[Closed] 温度監視について
2022/09/03[4]Ae4
テスト
CPUスレッド数128環境でのテスト

Gakuto Matsumura - Developer CPUスレッド数が65以上のCPU(AMD threadripperの128スレッド)のテスト 該当のCPUをお持ちの方、テストをお願いします。 テスト項目: ・設定のその他>ストレスCPUをオンに

2022/08/24[0]Gakuto Matsumura - Developer
要望
[Closed] トッププロセスのコミットサイズ表示 / メモリ不足時のアラート
2022/08/20[10]グリーン
要望
[Closed] 月齢が欲しい。
2022/08/13[10]りんりん
不具合
[Closed] 度々、固まってタスクマネージャーからしか終了できない
2022/08/13[30]ひょい
報告
ディスクI/Oの%表示が変?

ANACOSTIA (自動アップデートにより、)いつからか、PC自体がアイドルに使い状態の時でも、[ドライブ]→[ディスクI/O]の%表示の数値(ディスク(ドライブ)のアクティビティ率。転送速度ではなくビジー状態の割合

 Gakuto Matsumura - Developer とりあえず2002-2005年くらいのデータはでてきましたが、やっぱり中身が殆ど私の作曲した曲の話とかですね。 しかも整形スクリプト書かないととてもではないがどこからどこまでが本文かわからん… 20

 Gakuto Matsumura - Developer 認知される切っ掛けになったvectorの初登録が2009/07/20なので、2009/07/20から2009/10/14の3か月弱の間は多分vector上の掲示板が本体ですね。 vectorのコメント

2022/07/27[18]ANACOSTIA
*オープンクローズ
 + 
#
thilmera project - forum
[Closed] 不具合 0ch 0b176 Rev.1 DEV5が時々落ちる
#894
ANACOSTIA - 2132@PPwZZ1Pw2g1wPPgtmfX1f/uGXugfPGfJ 返信 2022/12/05 13:21
 0ch 0b176 Rev.1 DEV5です。
 DEV5になってからthilmera7が突然落ちる(ウィンドウが消え、タスクトレイのアイコンも消える)ようになりました。
 落ちるきっかけは不明です。

 落ちた時のイベントビューアのログ2回分を添付します。
 [SystemTime]と[EventRecordID]から判るように、それぞれ3個のイベントが一連になっています(それぞれ1個目のイベント([EventRecordID]が120637と120725)は関係無いようにも思いますが、念の為入れてあります。)。

[appended] 7z

Gakuto Matsumura - Developer 返信 2022/12/06
お待たせしました。

エラーログを見る限り、ヒープ破損のようです。

実は記憶があいまいなのですが、DEV5にした後か前かあたりに、177previewバージョンにてヒープ破損の原因になる場所ができていたのを修正しているので、さっき更新したDEV7にて、突然落ちるのが解決するかどうか確認をお願いします。

ANACOSTIA - 2135@PPwZZ1Pw2g1wPPgtluPJu/wufPmwZJmX 返信 2022/12/07
対応ありがとうございました。
これで様子を見ます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 0ch 0b176 Rev.1 DEV4で応答なしになる
#893
ANACOSTIA - 2132@PPwZZ1Pw2g1wPPgtfGXwmXJGJll/2l0u 返信 2022/11/30 18:37
 0ch 0b176 Rev.1 DEV4です。
 起動後、[重要なお知らせ]ウィンドウ下の[このお知らせを再表示しない]にチェックを入れようとしたり、本体ウィンドウの上にマウスカーソルを合わせたり、タスクトレイのアイコンをクリック(左右とも)すると、[応答なし]となります(という訳で、データ収集部の並列化についてのアンケートに参加できず)。
 Windowsのイベント ビューアーのログを添付します(エラーログ4回分をcsvで。)。
 Win 10 Pro、21H2、CPUはi7-4930MXのPCとi9-9980HKのPCの両方とも、thilmera7s64.exeとthilmera7_64.exeの両方とも同じ症状です。

[appended] txt

Gakuto Matsumura - Developer 返信 2022/11/30
報告ありがとうございます。

問題が発現している状態のiniファイルをください。
こちらで再現できないと特定が難しそうです。

Gakuto Matsumura - Developer 返信 2022/11/30
おそらく0b177 previewで追加されている排他処理によるデッドロックなので、まずは発現する設定の組み合わせから、こちらで再現できるか試したいです。

ANACOSTIA - 2132@PPwZZ1Pw2g1wPPgtfGXwmXJGJll/2l0u 返信 2022/11/30
PC2台分のthilmera7.iniを添付しました。

[appended] 7z

Gakuto Matsumura - Developer 返信 2022/11/30
ありがとうございます。
デッドロックの原因は「最善表示 - 常時」の配置換え箇所でした。

こちらテストをお願いします。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221130-234720.zip

ANACOSTIA - 2132@PPwZZ1Pw2g1wPPgtfGXwmXJGJll/2l0u 返信 2022/12/01
応答なしになることは無くなりました。
これで暫く様子を見ます。
データ収集部の並列化のON/OFFの判断も進めようと思います。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 Display Setのメニューに不具合があります
#891
ナセル=フェレロ - 2130@t3z6EJ/S 返信 2022/10/30 21:18
いつも大変お世話になっております。
0b176になってから、設定画面上部にあるDisplay Setのボタンが動作しておらず、ホットキーでの切り替えのみが可能な状態になっています。
また、Display Setの切り替え時に、一部の設定で瞬時の切り替えと再描画が正常に行われていない現象が発生しています。
現在確認できている症状を下記に箇条書きにてまとめましたので、ご確認いただき、可能であれば対応をお願いいたします。

■Display Setボタンが動作しない
・現在のセットを湿すマーカーは正常に表示されている
・マウスの左クリックでメニューが表示されず、操作できない
→設定画面上で切り替え、初期化、保存、名付けなどの操作が一切できない
・ホットキーに登録すれば切り替えのみ可能

■Display Setの切り替え時に描画が不自然なケースがある
Set0、Set2への切り替えは瞬時に行われるが、Set1への切り替え時は、切り替え後のウィンドウ位置にマウスオーバーするまで、残像のみが残り表示されない。
・「Style Lock」はOFF
・Set0~Set2までしか使用していない
・名付けをしているのはSet2のみ
※設定メニューからの切り替えが動作していないため、ホットキー操作時のみ確認しています

Gakuto Matsumura - Developer 返信 2022/10/30
報告ありがとうございます。
とりあえずこちらで再現できるか試したいので、iniファイルをください。

ナセル=フェレロ - 2130@t3z6EJ/S 返信 2022/10/31
すみません、添付を忘れておりました。
添付いたしましたので、ご確認をお願いします。

PC環境も記載しておりませんでしたので、簡易ですが下記に記載いたします。
■使用環境
OS: Windows10 Home
CPU: intel core i7-7700 3.60GHz
GPU: NVIDIA GeForce GTX 1060 3GB
物理メモリ: 8GB

[appended] ini

Gakuto Matsumura - Developer 返信 2022/11/01
確認し、以下修正してみました。

 ● 0b176の変更により、DisplaySetのメニューなどの13のコマンドが正しく実行されない不具合を修正。
 ○ DisplaySet変更時の処理を調整
  ・メインウィンドウの位置やサイズが、即時にレストアされるように変更。
  ・設定変更時の排他処理を、メイン,stage1,設定,レポートの4つ全てに変更。

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221101-012313.zip

テストをお願いします。

ナセル=フェレロ - 2130@t3z6EJ/S 返信 2022/11/01
迅速なご対応に感謝いたします。

いただいたthilmera7s開発版でテストした結果、下記のような結果となりました。
・DisplaySetメニュー使用不可状態
→左クリックからメニュー表示ができ、切り替え・命名・複写が正常に行われています
・DispkaySet変更時のメインウィンドウ反映と再描画の不具合
→DisplaySetを切り替えた際に、変更が即時反映され再描画が行われています

※いただいたファイルを実際の稼働環境に上書きしてしまうと「ランゲージファイルが破損してすべての文字が異常な表示に変化」してしまうようなので、現状では単体テストのみ実施しています。(開発版であるための現象と理解しておりますが、結合テストが可能であればご指摘・ご指示ください)

ナセル=フェレロ - 2130@t3z6EJ/S 返信 2022/11/01
動作試験中に、偶然気がついた点について追加報告いたします。

■カラーテーマファイルでのカラー切り替えができない場合がある
設定画面の「カラー」でカラーテーマを選択しても、初期テーマと0b176以降で自作したテーマ以外のテーマファイルで色が変更できない状態となっています。(バンドルされているテーマファイルでもカラーチェンジできません)
カラーテーマの保存ファイルに記された項目と値、プリインストールされているテーマ、0b176より前で自作したテーマ、0b176で自作したテーマそれぞれで異なるところまで確認しました。

参考データを添付いたしますので、ご確認のほどお願いいたします。

[appended] zip

Gakuto Matsumura - Developer 返信 2022/11/03
カラーテーマの不具合はどうも汎用のテキストファイル読み込みにバグがあったようです。
以下テストをお願いします。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221103-174945.zip


テスト版を稼働環境へコピーする場合、スタートアップサービスを使っていると、プログラム本体が上書きできないので、リソースデータだけ更新されておかしくなります。

スタートアップサービスを停止してからコピーしてみて下さい。

ナセル=フェレロ - 2130@t3z6EJ/S 返信 2022/11/05
いただいたthilmera7s開発版でテストした結果、下記のような結果となりました。

・0b176より前のバージョンで作成されたカラーテーマの選択
選択すると、対応したカラーテーマの色に変更されることを確認できました。
テーマによってmemory-standbyが変更されないケースはありますが、該当テーマのファイルを見ると、記録された色の項目名が異なるため、仕様と認識しております。

テスト版の稼働環境への適用方法についても、ご教示いただきありがとうございました。
無事、稼働環境でのテストも行うことができ、DIsplay Setの動作、カラーテーマ選択時の動作、稼働環境下への移植でも双方解消していることを確認できました。

Gakuto Matsumura - Developer 返信 2022/11/07
メモリの二項目はあとから追加されたものなので、とりあえず未定義の場合はデフォルト値に戻るように変更します。

次回リリースから適用されますが、ものすごい大改編をしたので、0chでしばらく様子見を想定してます。

ナセル=フェレロ - 2130@t3z6EJ/S 返信 2022/11/09
未定義のカラーはデフォルト値に変更の件、および次回リリースの件、了解いたしました。
お忙しい中、丁寧なご対応ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 サウンド系表示が乱れる
#892
-m- - 2131@uPwZ22Pg1GPP1llg0/wmPG/ZglJfuJ 返信 2022/11/06 03:15
既知、仕様かわからないので報告です。
0b176 Rev1でウィンドウをドラッグすると、サウンド系の表示速度が速くながれます。


[appended] ini

Gakuto Matsumura - Developer 返信 2022/11/07
現行では仕様です。

サウンドアナライザーは速度が大事なため、あえてデータと分けずに描画直前に取得するようにしていました。

ただ、よくよく考えるとデータと描画が完全に分離されていなかったり、メインスレッド以外からの描画が入った場合に挙動がおかしくなる場合があるので、根本的にそのあたりを再編成しつつ、データ収集部を並列化する大改造をしています。

次回リリースで適用しますが、ものすごい変更量なので、0chでしばらく様子見を想定してます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 cpu温度
#890
HD - 2129@ZPwZPPu/wwtmPPZ22tGG/lXw11/wuglX 返信 2022/10/26 21:30
初めまして。
いつもthilmeraを利用させていただいています。
先日の更新以降CPUの温度が表示されておらず、”E2013”となっていることに
気づきました。以前は温度が表示されていました。
対応できる問題でしたら宜しくお願いいたします。


[appended] txt

Gakuto Matsumura - Developer 返信 2022/10/26
重要なお知らせ、およびバージョン情報に書いていますが、0b176からは、セキュリティ上問題のある古いドライバを、標準設定では使用しないように変更しています。

この問題を承知の上で、以前と同様にしたい場合、「旧ドライバの使用を許可する」をオンにして下さい。
Ryzen Masterドライバの使用を強く推奨しています。

HD - 2129@ZPwZPPu/wwtmPPZ22tGG/lXw11/wuglX 返信 2022/10/27
ドライバの影響ということですね。
承知しました。ありがとうございました。

HD - 2129@Hyjwm+BO 返信 2022/10/29
Ryzen Master をインストールしてみました。
Ryzen Master自体はエラーで起動できませんでしたが、thilmeraには
温度表示が出るようになりました。

しかし、今度はCPUクロックが異様に低い値を表示するようになり、タスクマネージャー
とかけ離れた値となっています。

軽負荷時
タスクマネージャー:2.5Ghz付近をふらふら
thilmera:0.4G 等

ほぼ0.2~1.4Gであまり大きな値を表示する事はありません。
以前は1.3~4.2Gで変化しておりましたが、それがタスクマネージャーと一致していたかは
不明です。
ドライバが出す値がそうなったということでしょうか?

[appended] txt

Gakuto Matsumura - Developer 返信 2022/10/29
あぁ、それに関しては推奨するのならばヘルプにも記載しとかないとだめですね。失念してました。

Ryzen Masterドライバ由来のクロックは、標準設定ではEffective Clockという、AMD独自の基準のものになります。

タスクマネージャーなどで見えているのが規格上の数値で、Effective Clockは内部の正味の数値、みたいな感じになります。

Ryzen系CPUでは、基本的に規格の数値はほぼ固定であるのに対し、Effective Clockは内部の負荷により大きく上下します。

非Ryzen Masterドライバ時のClock計算は、旧来のAMD CPUの倍率(Division&Multiplier)を取得して、規格上のクロックを弄った予測の値になるため、実際の内部のクロック数に対しては不正確で、Effective Clockのほうが正確な値に近いです。

例えば、シルメラの設定画面の下部にある、「CPUストレス」による負荷テストを行うと、Effective Clockが上昇するのが分かると思います。

HD - 2129@ZPwZPPu/wwtmPPZ2uwP1/wm1000/PP0/ 返信 2022/10/30
いろいろと複雑なのですね。
解説いただきありがとうございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 質問 0b176 更新後のCPU使用率増加の要因について
#889
Gonbe - 2127@1PwZPPPmPwwZt/llX2GP/JGt2lZ0GJ/ 返信 2022/10/18 03:35
いつも大変お世話になりまして、有り難うございます。
0b175 Rev.2 から0b176 へ更新後、CPU使用率が増加したのでお尋ねします。
添付図は、PC が入力待ち状態で安定した時、シルメラの各バージョンを使用したものです。
0b175 Rev.2 では、シルメラの表示は概ね1%以下で、0.02%以下の表示も多々ありました。
しかし、0b176 に更新後は、概ね2~3%を表示して、1%未満の表示はしなくなりました。
シルメラ自体のメモリ消費は大差ありませんが、この表示値の相違の要因は何でしょうか?
何かデータの提出が必要であれば、お申し付け下さい。

Gonbe - 2127@1PwZPPPmPwwZt/lZgPXwJGGZmGJ0GfJ 返信 2022/10/18
thilmera7.upd.exe を使用して何度もシルメラのバージョンを変更して確認しましたが、
前述のCPU使用率の増加について、再現性は100%でしたので申し添えます。

Gonbe - 2127@1PwZPPPmPwwZt/lZgPXwJGGZmGJ0GfJ 返信 2022/10/18
添付図は、0b175 Rev.2 使用時のものです。
タスクマネージャで「3%」表示の時、シルメラは「0.46%」を表示しています。
0b175 Rev.2 の表示が異常であり、0b176 では改善されたということでしょうか?

Gonbe - 2127@1PwZPPPmPwwZt/lZgPXwJGGZmGJ0GfJ 返信 2022/10/18
添付図を付け忘れていました。

Gakuto Matsumura - Developer 返信 2022/10/18
シルメラ内のCPU負荷表示の方の話であれば、WIn11の22H2には、見た目の負荷がまるでほとんどないかのように見えてしまう魔法のようなバグがあります。
0b176ではそれを補正するモードを追加しています。

詳しくはバージョン情報をご覧下さい。

対応時の詳細は以下にあります。
thilmera.com/s/forum/index.php?board=thilmera#topic886

Gakuto Matsumura - Developer 返信 2022/10/18
ちなみにOSのバージョンが22H2でない場合はこの問題は起こりません。
22H2が壊れているだけです。

Gonbe - 2127@1PwZPPPmPwwZt/lGu1G0lfZtf2J0wPG 返信 2022/10/18
ご多用のところ返信を有り難うございます。
貴サイトのバージョン情報を拝見した上で、質問させて頂きました。
なお、使用OSは、次のとおりなので不思議に感じての質問でした。
Windows 10 Home 64bit Build 19044 21H2

Gonbe - 2127@1PwZPPPmPwwZt/lGu1G0lfZtf2J0wPG 返信 2022/10/18
Windows11(22H2)において、情報元の破損により、CPU、CPUマルチコア、
トッププロセスCPUの値が異常に低い数値になっていたとのこと。
そこで、「22H2対処モード」を追加して補正されたことは理解しています。
また、トッププロセスCPUは、「サイクル計算モード」を追加された効果が
私のPCでも十分に感じられており、有り難いことです。
しかしながら、シルメラのCPU使用率表示値が増加した事象につきましては、
正しい表示になった(近づいた)ということで喜ばしいことでありますが、
私の使用OSが異なるため、何か潜在的な問題が残っていてはいけないと思い、
質問させて頂いた次第です。 言葉足らずであったことは、お詫びします。

Gakuto Matsumura - Developer 返信 2022/10/18
なるほど。報告ありがとうございます。
重要なお知らせと、次回以降のバージョン情報に、以下の一文を追加するようにします。

(22H2ではないWin10などでも発生していた環境があるそうです)

おそらくWin11の22H2がリリースされた後の各アップデートでも同じバグが散布されてる可能がありそうですね。

Gonbe - 2127@1PwZPPPmPwwZt/lGu1G0lfZtf2J0wPG 返信 2022/10/18
「サイクル計算モード」につきましては、とても良い感じです。
0b175 Rev.2 の時には、トッププロセスCPUを「2つ」表示する設定でも、
1つのプロセスしか表示しなかったり、全く空欄になることもありました。
0b176 に更新後は、常に2つのプロセスが表示されるようになりました。
今後とも宜敷お願いいたします。

Gonbe - 2128@1PwZPPPmPwwZt/l22Gf1Zw0XfZ2/ltf 返信 2022/10/19
本日、Windows 10 を22H2(Build 19045.2130)に更新しました。
試しに「0b175 Rev.2」に戻すと、22H1 の時と同じ事象が100%発生します。
従って、私の環境ではWindows 10 の21H2と22H2の両方で不具合が発生します。
0b176 を有り難く使用させて頂きます。

Gakuto Matsumura - Developer 返信 2022/10/19
報告ありがとうございます。
多分予想ですが、Win11-22H2が最初に登場した後のマンスリーアップデートで同じ不具合(仕様?)が広がっているのではないかと思います。

Gonbe - 2128@1PwZPPPmPwwZt/l22Gf1Zw0XfZ2/ltf 返信 2022/10/19
私はハード屋なのでソフト関連に疎いのですが、勉強になります。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 通信量カウンタのByte設定
#888
AKA - 2126@GPwZl2Pw2XPPGgfPll0/Zm1JgZtlw 返信 2022/10/17 18:58
今年の3月下旬にも同様の事象でこちらに相談させていただいたものです。
恐らくですが先日のバージョンアップ後から同様の事象が再発したようです。
また何かのタイミングで参照先が変わってしまったのでしょうか?
利用バージョンは"0b176"となります。

Gakuto Matsumura - Developer 返信 2022/10/17
確認したところ、1000単位の自動単位の計算で、100,000,000以上の桁の判定と割り算の桁数がずれてました。
そこをいじった記憶はないので、元からあった別口の不具合である可能性があります。

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221017-191723.zip
修正されているか確認をお願いします。

AKA - 2126@GPwZl2Pw2XPPGgfPll0/Zm1JgZtlw 返信 2022/10/17
早速確認いただきありがとうございます。
予定通りの数値になってくれました!!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 Ryzen 9 7950X + X670Eでの動作報告
#887
327 - 2125@uPwZP2ZX/tPPflJ1fmul2lJZ20g2w 返信 2022/10/13 04:44
いつも大変お世話になっております。
Ryzen 9 7950X + X670Eマザーボードでの動作についてご報告いたします。
(既出でしたら申し訳ございません)

以下は問題なく動作しています。
・クロック周波数、Package Powerの表示
・NVMe RAIDを構成するSSDのAMD_RC2t7経由での情報取得

CPU名(!AMD E-1との表示)・CPU温度(表示されない)以外は特に問題ないという印象です。
もし対応予定があり、他にテストやレポートの出力等必要でしたらお申し付けください。

【環境】
CPU: AMD Ryzen 9 7950X
M/B: MSI MEG X670E ACE
OS: Windows 11 Pro (22H2, build 22621.525)
thilmera バージョン: 0b175 Rev.2

Gakuto Matsumura - Developer 返信 2022/10/13
報告ありがとうございます。
レポートのCPU情報の内容をtxtファイルとして添付してほしいです。

Gakuto Matsumura - Developer 返信 2022/10/13
レポートのPCIデバイス情報もお願いします。

Gakuto Matsumura - Developer 返信 2022/10/14
すでに出回っている情報から予測して作成してみました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221014-223930.zip

なお、次回リリースからは、「旧ドライバ」はデフォルトで使用しないようになっているので、RyzenMasterドライバでもなく、2021ドライバでもない場合は、「旧ドライバの使用を許可する」の状態でのテストになります。

RyzenMasterドライバに移行していく方針です。

327 - 2125@uPwZP2ZX/tPPflXZ1u2umJwPfw0Zwf 返信 2022/10/16
確認が遅くなり申し訳ございません。
テスト版についてはRyzen Masterドライバのオプションを入れた状態であれば温度が表示されるようになりました。

Gakuto Matsumura - Developer 返信 2022/10/16
すみません、今回はRyzen Masterドライバのオプションを入れない状態での確認をお願いします。

327 - 2125@uPwZP2ZX/tPPflXZ1u2umJwPfw0Zwf 返信 2022/10/16
レポートのtxtファイルを添付します。
①CPU情報

[appended] txt

327 - 2125@uPwZP2ZX/tPPflXZ1u2umJwPfw0Zwf 返信 2022/10/16
>すみません、今回はRyzen Masterドライバのオプションを入れない状態での確認をお願いします。
失礼しました。その状態では表示されませんでした。

Gakuto Matsumura - Developer 返信 2022/10/16
「旧ドライバの使用を許可する」の状態でのテストをお願いします。

次回リリースからは、「旧ドライバ」はデフォルトで使用しないようになっているので、RyzenMasterドライバでもなく、2021ドライバでもない場合は、「旧ドライバの使用を許可する」の状態でのテストになります。

327 - 2125@uPwZP2ZX/tPPflXZ1u2umJwPfw0Zwf 返信 2022/10/16
②PCIデバイス情報
です。

[appended] txt

327 - 2125@uPwZP2ZX/tPPflXZ1u2umJwPfw0Zwf 返信 2022/10/16
>「旧ドライバの使用を許可する」の状態でのテストをお願いします。

>次回リリースからは、「旧ドライバ」はデフォルトで使用しないようになっているので、RyzenMasterドライバでもなく、2021ドライバでもない場合は、「旧ドライバの使用を許可する」の状態でのテストになります。

度々申し訳ありません。
そちらであればCCDごとの温度も含め表示されるようです。

Gakuto Matsumura - Developer 返信 2022/10/16
確認ありがとうございます。

解決しているようなので、正式リリースしたいと思います。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 thilmera7のCPU CPUマルチの使用率
#886
フォス - 2124@JPwZJXP2X2l 返信 2022/10/09 21:07
Windows10の時はゲームベンチマーク等のテスト中のCPUとマルチの使用率はタスクマネージャーとほぼ合っていたのですが、windows11にアップデートしてからほぼ0~5%までしか数値が上がらず正常に機能しないようになってしましました
thilmera7の設定内にあるストレスCPUを使用すると全コア100%にはなりますがそれ以外ほぼ全て情報が拾えてないのかなと思います
CPU i7-8086k ASUS ROG STRIX Z370-F GAMING を使用しております

Gakuto Matsumura - Developer 返信 2022/10/10
22H2はやたらと負荷が低いなと思ってましたが、バグだったんですね…

どうも22H2では基準となるidle時間が壊れてて、既存のメジャーな方法では正確に計算できないそうです。

CPUとCPUマルチはなんとかなりそうなんですが、プロセスCPUが絶望的にだめで、報告を確認してから徹夜でいろんなものを調べてかたっぱしから試してるんですが、解決のめどは立っていません…

Gakuto Matsumura - Developer 返信 2022/10/10
でき…ましたっ!!!
テストお願いします。

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221010-114911.zip

 ● Win11(22H2)のCPU稼働率の破損対応
  ・Windows11(22H2)において、情報元の破損により、CPU、CPUマルチコア、トッププロセスCPUの値が異常に低い数値になっていたのを修正。
  ・CPU, CPUマルチコアは、情報が破損した部分を別の場所から補完する「22H2対処モード」を追加。設定によりオフにした場合は旧モード。
  ・トッププロセスCPUは、「サイクル計算モード」を追加。恐らく22H2以外でも精度は上がる。設定によりオフにした場合は旧モード。Windows7未満のOSでは利用不可。

フォス - 2124@JPwZJXP2X2l 返信 2022/10/10
ご対応ありがとうございます
今テストしてみましたが、タスクマネージャーと比較してもほぼ同じ数値出るようになりました
1個のスレッドだけ使用率が大幅に高い状態も正常に拾えています
ありがとうございました

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 質問 CPUの平均温度が感覚と合わない
#885
sleepyF - 2123@VuWtR321 返信 2022/09/29 09:56
設定 → CPU温度 → 平均 にチェックした場合に表示される、括弧()で表示される
CPUの平均温度に関して質問です。
いつもは漠然と平均値が表示されていると思っていたものの、ふと気づいたら
感覚と違っているようなので。

負荷が掛かっているときはまぁそんなものかと思う値なのですが、瞬間的に負荷を
外したり、負荷がなくなってしばらく経ってからも「平均」の値は徐々に下がって
いくものの、各コアの表示値と比べても高いままです。なぜでしょう?

Gakuto Matsumura - Developer 返信 2022/09/29
現在の平均の定義は、全体を通しての平均であるため、デフォルトでは平均する期間は1.5日程度(2047回分)になります。

どういう感じの平均であってほしいですか?

Gakuto Matsumura - Developer 返信 2022/09/29
例えば現在すでに存在する、CSV出力用の平均値テーブルにある、1分、5分、15分などのチャンネルの値を採用するなどは比較的簡単にできるかもしれません。

sleepyF - 2123@VuWtR321 返信 2022/09/29
なるほど。やはり平均としてのサンプルが多い/期間が長いということですね。
私個人的な間隔としては数分程度の平均が見たいです。
なので提示された例ならば、1分や5分での平均値であれば違和感を感じないと思います。

Gakuto Matsumura - Developer 返信 2022/10/01
お待たせしました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221001-224248.zip

CSV出力用の平均値テーブルは1分単位刻みのため、そのまま使用すると1分間変わらなず、補正しても1分毎に大幅に変わってしまい、そのまま利用はできませんでした。

結局平均するバッファを可変にし、分数指定でフレーム速度などから計算されたサンプル数をとる。という形になりました。

フレーム速度の設定に、平均値サンプル数を分数で指定するオプションを追加しています。
デフォルトは1分にしています。

sleepyF - 2123@VuWtR321 返信 2022/10/03
ご検討いただきありがとうございます。

test_build_s64_20221001-224248 の結果は以下の通りでした。

1:フレーム速度の設定に2つのオプションが追加されていましたが、
  ・平均値サンプル数 - メイン
  ・平均値サンプル数 - 投稿
 「メイン」の数値をいじってみて「平均値」が0b175 Rev.2よりも
 速やかに上昇/下降することを確認しました。
 実動作を見たら、私には1分でも若干遅い印象ではありました。
 20秒、30秒だともっと良いのですが、現状よりは良いと思います。

2:「投稿」の意味/効果は良く分かりませんでした。

3: デフォルトが「メイン」「投稿」とも3分でした。15分と1分にして確認。

4: thilmera7メイン窓の描画の問題なのか、表示が上下にブルブルと
 伸び縮みする現象やチラツキが出ます。揺れる位置は異なりますが
 Win7、Win10の各PCで発生します。 揺れ状況の動画を添付しておきます。

[appended] zip

Gakuto Matsumura - Developer 返信 2022/10/03
すみません、iniファイルをください。

sleepyF - 2123@VuWtR321 返信 2022/10/03
win7, win10環境のiniを添付します

[appended] zip

Gakuto Matsumura - Developer 返信 2022/10/03
ありがとうございます。

グループラインによる高さが一定にならない不具合を修正しました。
新機能関連のバグでした。

「 - 投稿」は「 - ステータス投稿」に名称変更しました。

1分最低だと長いとのことなので、分数指定から秒数指定に変えました。デフォルトは60秒です。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20221003-203044.zip

sleepyF - 2123@VuWtR321 返信 2022/10/03
ありがとうございました。
CPU温度の(移動)平均も希望通りに秒単位で選べるようになりましたし、
テスト版の高さ不定不具合も解消しました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 質問 スリープについて
#884
retsam - 2121@uPwZP1ZPfmXPPtffXG0//1/2fGmG1u 返信 2022/09/06 16:51
Windows11 21H2でこのソフトを使用していますが、このソフトが起動している間はWindowsの電源で設定したスリープ時間が経過してもスリープしなくなったのですが仕様でしょうか?もし仕様ならスリープするように出来ないでしょうか?

Gakuto Matsumura - Developer 返信 2022/09/06
普段スリープを使わないので把握していませんが、そういう場合もあるんですね。

スリープしない原因に関しては、「設定による」としか言えないので、何の機能を有効にしているかによって千差万別になります。

なので、まずはiniファイルをここに添付していただき、それを私の方でテストし、スリープ
(win11の仮想がないのでwin10仮想で)がされないのを確認できたら、何の機能が阻害しているのかを調べてみます。

多分ですが予想ではSMART取得(CrystalDiskInfoコア)あたりかなと思います。

Gakuto Matsumura - Developer 返信 2022/09/06
もしSMART取得が原因である場合は、シルメラからCDIへの差し込み機能であるNo WakeUPをオンにすると解決するかもしれません。

このあたりが原因である場合はハードウェア(物理的なドライブの仕様)により対象となったりならなかったりするので、その場合は全く同じ設定でもこちらでは再現されない場合があります。

retsam - 2121@uPwZP1ZPfmXPPtffXG0//1/2fGmG1u 返信 2022/09/06
iniファイルとはこれで良いでしょうか?

[appended] ini

Gakuto Matsumura - Developer 返信 2022/09/06
頂いたiniを元に、win11実機でスリープ5分のテストをしたところ、正常にスリープされました。

なので、確かめてほしい順に書きます。
① まずスリープを一時的に最短の5分にする。
② 確認1。ドライブ>SMART詳細のNo Wake Upをオンにしてスリープされるか確認。
③ 確認2。確認1で無理だった場合に、
「ドライブ>HDD温度(SMART)」
「ドライブ>論理ドライブ>温度」
「ドライブ>ディスクIO>温度」
の3つをオフにし、スリープされるか確認。
④ 確認3。確認2でもだめだった場合、シルメラを起動した際のUACをキャンセルしてユーザーモードで起動。その状態でスリープされるか確認。
⑤ 確認4。確認3でも無理だった場合、シルメラを起動せずにスリープされるか確認。

以上の確認をお願いします。
どの段階で可能になるか、もしくは最後まで可能にならないかの結果を教えてください。

retsam - 2122@uPwZP1ZPfmXPPtf1lG00/mwJgwGlmw/ 返信 2022/09/06
スリープについて、②、③を試してみましたがスリープに入りませんでした。
④についてはUACのキャンセルが何を指しているのかわからないため試せていません。
⑤については問題なくスリープに入りました。
試しに時計なども含めて全ての表示をオフにした場合(thilmeraの薄いバーだけが上部に表示されている状態)ではスリープに入りました。
ドライブ情報の表示を全てオフにしてもスリープに入りませんでした。
現状確認できているのはここまでです。一つずつ機能をオフにしていけば阻害している項目を特定できそうですが・・・

Gakuto Matsumura - Developer 返信 2022/09/06
UACキャンセルは、実行した際に管理者権限で実行するかの確認があると思うので、それをキャンセルを選ぶということです。

UACそのものを切っている場合はどうしようもないのでかまいません。

③ですが、言い忘れていましたが、設定でオフにした後に、シルメラを再起動して確認してほしいです。
もしすでにやっていたらすみません。

>時計なども含めて全ての表示をオフにした場合
うーん、ドライブ以外で可能性があるとしたらサウンドアナライザーかCPU温度、CPUクロック、CPUワット類くらいかなぁ…

普通このあたりでそんな影響がでることはないはずなんですが…

なにせこちらの環境ではフルの状態で問題なくスリープされるので、特定できずですみません。

Gakuto Matsumura - Developer 返信 2022/09/06
もしかしたらサウンドアナライザーの Render かもしれません。

① サウンドアナライザーをオフ
② シルメラを再起動
③ 確認

④ もしスリープになるようなら、「レンダーなし」をオン
⑤ 確認

こちらを確認お願いします。

retsam - 2121@uPwZP1ZPfmXPPtfPXPZwufgJZ1tXZfu 返信 2022/09/07
ご指摘の通りサウンドアナライザーをオフまたはレンダーなしにすることでスリープに入るようになりました。ありがとうございました。

Gakuto Matsumura - Developer 返信 2022/09/07
確認ありがとうございます!

どうもこのあたり、発生するかどうかはサウンドドライバによるらしいです。

とりあえず次回からはレンダーなしを初期値に変更しておきます。

この件はヘルプのQ&Aに記載しておきました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 要望 月齢グラフィカル部の向きについて
#883
ぼんこり - 2120@0PwZg2gmlPP100J10fPwGffXt/w0t 返信 2022/09/05 18:49
再びお世話になります。
私門専門ではないので、違うかもしれませんが、他サイトとか実際に夜空を見上げると、月齢の満ち欠けが左右逆な気がします。。

Gakuto Matsumura - Developer 返信 2022/09/05
おおぅ…
たしかにそうですね。

変に弄るとおもいっきり崩れたので、グラフ描画に入力される数値を逆数にして対処します。

ついでに直したい所も直しました。
0b175 Rev.2にて。

ぼんこり - 2120@0PwZg2gmlPP100J10fPwGffXt/w0t 返信 2022/09/05
ありがとうございます。修正確認しました。
すごく細かい部分でしたが、ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 要望 月齢表示部の文字かぶりについて
#882
ぼんこり - 2120@0PwZg2gmlPP10/12f21PgGJZfG/Gw 返信 2022/09/04 10:04
お疲れ様です。
v175にアップデートさせていただき、楽しく使っております。
新しく導入されたグラフィカルな月齢部ですが、図の部分と文字の一部がかぶっているように見えます。小数点2桁が月にうまっている状態かと存じます。
(添付では月齢0.25の5の部分が埋まってる?)
カラー変更やスタイル変更等で回避できるならご教授いただきたいのでいいのですが、数字月齢をもう少しお月様から離せられませんでしょうか。

ぼんこり - 2120@0PwZg2gmlPP10/12f21PgGJZfG/Gw 返信 2022/09/04
フォントとか私の独自環境によるものであればご放念ください。。
一応フォントは8x13のドットです。

Gakuto Matsumura - Developer 返信 2022/09/04
すみません、一応その部分は文字幅を計算するようになっていて、こちらでは幅やフォントを変えてもかぶらない状態なので、再現されるiniファイルを下さい。

ぼんこり - 2120@0PwZg2gmlPP10/12f21PgGJZfG/Gw 返信 2022/09/04
あー、やっはり設計では考慮されていたのですね。
いわゆるおま環ですかね。。
ファイルはこちらで大丈夫でしょうか。

[appended] ini

Gakuto Matsumura - Developer 返信 2022/09/04
ありがとうございます!

どうもドットフォントにしている時に、OSフォントの横幅の基準が影響していたらしく、ドットフォント使用時は文字幅の計算を全てドットフォント優先にしました。

0b175 Rev.1 として更新しました。

ぼんこり - 2120@0PwZg2gmlPP10/12f21PgGJZfG/Gw 返信 2022/09/04
v175 r1にしまして、文字かぶりがなくなったこと報告させていただきます!!
ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 要望 シルメラのウインドウについて任意位置での固定設定の追加
#880
Ginbe - 2117@1PwZPPPmPwwZt/lftGtum2w/GXmJGfm 返信 2022/09/01 08:36
毎々お世話になります。 現在、Ver.0b174Rev.8 を愛用しています。
タイトルどおりの要望です。
現状では、「右下固定」「右上固定」「左下固定」の設定がありますが、
私は左端に縦表示したタスクバーの中にシルメラを常時表示しています。
「位置補正」「位置フィット」のお陰で横方向のズレは問題ないですが、
マウス操作で縦方向にウインドウがズレてしまうことが時々あります。
「任意位置固定」があると便利になると思います。

Gakuto Matsumura - Developer 返信 2022/09/01
意図に沿っているかはわかりませんが、「メインウィンドウ移動ロック」というのを作りました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220901-191742.zip
「横幅変更」のオフと「メインウィンドウ移動ロック」のオンで、誤クリックによるメインウィンドウの変化は避けられるかと思いますが、こんな感じでもよいしょうか?

Ginbe - 2117@1PwZPPPmPwwZt/lftGtum2w/GXmJGfm 返信 2022/09/01
こんばんは、早速対応して下さり有り難うございます。
Ver.0b174Rev.8.18 は、私のイメージ(希望)どおりに動作しています。
これで、ウインドウがロックされるので、マウス操作が楽になりました。
ところで、「画面の変更には影響を受けます」という注意メッセージの
意味について、お手数とは存じますが教えて頂けますでしょうか。

Ginbe - 2117@1PwZPPPmPwwZt/lGX1tmg2lXJ2X0Xuf 返信 2022/09/01
私の言葉足らずの面があるかも知れないので、追記いたします。
マウス操作で不本意にウインドウをドラッグしてしまい、ウインドウ表示位置が
ズレてしまう問題は解消しました。
ところで、ディスプレイの解像度を変更したり拡大縮小をしても、それに追従して
シルメラのウインドウサイズが自動的に変更されたり、ウインドウ位置が補正され
たりするような動作は、設定されていないと思われます。
そこで、「画面の変更には影響を受けます」という注意メッセージは、どのような
状況を意図して注意喚起しているのか教えて頂けますでしょうか。

Gakuto Matsumura - Developer 返信 2022/09/01
>ところで、ディスプレイの解像度を変更したり拡大縮小をしても、それに追従してシルメラのウインドウサイズが自動的に変更されたり、ウインドウ位置が補正されたりするような動作は、設定されていないと思われます。
これは「位置補正」というデフォルトでオンの設定がそれにあたります。

Gakuto Matsumura - Developer 返信 2022/09/02
とりあえず「マウス操作以外の変更には影響されます」に変更しておきます。

Ginbe - 2117@1PwZPPPmPwwZt/lwwXZ1uPl2g1G02m1 返信 2022/09/02
ナルホド! 当たり前のように使っていて、考えが及びませんでした。

Gonbe - 2119@1PwZPPPmPwwZt/lf21m2PZw0gfZ0ggf 返信 2022/09/04
今回のロック設定について、Ver.0b175 に反映して下さり有り難うございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 温度監視について
#881
Ae4 - 2118@2PPZXgfZw2XXmJuu2Z1mJf/llw/0mg 返信 2022/09/03 17:23
CPUの温度が高めに出ます、
低いときでも一瞬高くなったりします。
パソコンはDELLのG15 5511です。
CPUは intel Core i7の11世代、intel Core i7 11800Hです。
パソコン初心者ですみません。

Gakuto Matsumura - Developer 返信 2022/09/03
高いと判断された理由は何ですか?

何と比べて高いのかを具体的に教えていただけると助かります。

Gakuto Matsumura - Developer 返信 2022/09/03
温度に関しては今のところ瞬間値なので、一瞬高く示されることは普通にあります。
これに関して、数サンプルの平均化をしてほしいという話(瞬間値よりも上下が少なくなる)なのか、なんらかの他のアプリと比べて常に高く出る(Intelは現在全コアの中での最高値を採用になるのでそのあたりの問題かもしれません)という話なのか。

ただ高めに出ますといわれても、何をもってそう思われたのかが分からないと対応は難しいです。

Ae4 - 2118@2PPZXgfZw2XXmJlmXf2llwmgG22l2Z 返信 2022/09/03
95度をとうに超えていました。
intel は100度を上限としてますが、高負荷状態でも90度を超えるのは稀だと思います。
確かに、hwmoniterでもその時、97度とかだったです。
すみません。

Gakuto Matsumura - Developer 返信 2022/09/03
IntelのCPUは一律100度MAXではないです。
ノートなどのモバイルだと95度が上限の場合もあるし、パワー型の場合は105度とか115度などの場合もあります。

ただ、検索した限りではintel Core i7 11800Hは100度だったので、他の温度計でも同じ結果ならばかなりぎりぎりの状態なので、エアフロー(ケース内の風通し)やヒートシンク、グリスの劣化などを点検したほうがいいかもしれません。

Intelの自分のCPUの温度最大値は、「レポート: CPU情報にある」TjMaxという数値で確認できます。

とりあえずhwmoniterなどでも似たような温度とのことで、シルメラ固有の問題とは考えにくいので、ひとまずコア最大値ではなくコア平均値を表示するモードを追加だけしときました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220903-210904.zip

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

テスト CPUスレッド数128環境でのテスト
#879
Gakuto Matsumura - Developer 返信 2022/08/24 00:31
CPUスレッド数が65以上のCPU(AMD threadripperの128スレッド)のテスト
該当のCPUをお持ちの方、テストをお願いします。

テスト項目:
・設定のその他>ストレスCPUをオンにして、CPU全体が使用率100%に到達するか
・CPUマルチが全て表示されるか
・CPUクロックが全て表示されるか
・RyzenMasterモードのEffectiveClockが全て表示されるか


○ CPUスレッド数
 ・CPUマルチ、CPUクロック、EffectiveClock、Intelコア温度、ストレスCPUの枠数を可変長に変更。
 ・CPUスレッド数が65以上の環境への対応テスト。テスター求む。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220824-002631.zip
update
返信

[Closed] 要望 トッププロセスのコミットサイズ表示 / メモリ不足時のアラート
#878
グリーン - 2116@uPwZl2PtPwPP2Puf/0JtlG/2/lZX 返信 2022/08/14 16:08
こんにちは。ハードとソフト両方の情報を監視できるthilmera7がとても便利で重宝しています。

要望が2つあります。
コミットサイズ(仮想メモリ)が多い順のプロセス一覧を表示したいです。
使い続けるとコミットサイズが少しずつ増えていくソフトがあるので、仮想メモリが足りなくなって問題が発生する前に気づくことができれば便利だなと思います。
トッププロセスCPUのフルバー色反転設定のように、各プロセスの物理メモリとコミットサイズが指定した数値以上になったら背景色を変更できる設定があっても良いかもしれませんね。

もう1つの要望は、物理メモリ使用量と仮想メモリ使用量それぞれにおいて、指定した割合に達したらアラート警告してほしいです。
私の環境では仮想メモリ使用量が100%近くになることが時々あるので、95%くらいに設定しておいてアラート警告したいです。

2つ目の要望だけでも実装していただけるととてもありがたいです。
よろしくお願いします。

Gakuto Matsumura - Developer 返信 2022/08/15
仮想メモリとコミットサイズは全く異なる数値です。
基本的に仮想メモリ(Virtual Size)はあてになりません。
64bitOSのだいたいの環境では、ここの数値が2TBとかになるので、もしプロセスのページファイルの使用バイト数が知りたいなら、ものすごく複雑で重い処理を追加しなければなりません。

一応暫定で作ってみましたが、仮想メモリをランキングするとどうなるかというと画像の通りです。

仮想メモリ使用量というのは便宜上残していますが、これもあてになる数値ではありません。
コミットサイズと仮想メモリとページファイルは別物となります。

Gakuto Matsumura - Developer 返信 2022/08/15
この前提を踏まえた上で、何の数値をとり、何の数値と比較したいのかをもう一度考えてみてください。

グリーン - 2116@uPwZl2PtPwPP2wuf1mfugZtuf11mZ 返信 2022/08/15
詳しいことは分かりませんが、私が理解しているコミットサイズはタスクマネージャーの詳細タブで見れる「コミットサイズ」の数値のことです。リソースモニターのメモリタブで見れる「コミット(KB)」も同じ数値ですよね。
各プロセスでこの数値が増えるとthilmeraの仮想メモリの数値や割合が増えるのでこれを参考にして仮想メモリ不足になりそうかどうかを見ています。この数値はタスクマネージャーのパフォーマンスタブの「コミット済み」と同じ数値ですよね。

プロセスのコミットサイズ上位3つほどをthilmeraで追加で表示できたらいいなと思っての要望でしたが、重い処理をしなければいけないのであれば要望は取り下げたいと思います。

Gakuto Matsumura - Developer 返信 2022/08/15
ありがとうございます。

必要なのはコミットサイズ、ということですね。
ちょっと管理者権限必須になりますが、可能性のありそうな部分があるので、試してみますが、すこしかかると思います。

共有コミットサイズ、というやつなので、タスクマネージャーの数値と一致するのかは謎ですが。

Gakuto Matsumura - Developer 返信 2022/08/16
ひとまず滅茶苦茶頑張って、OSのリソースメーターと同様の数値が並ぶ状態が作れました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220816-015325.zip
テストにて、設定の「トッププロセスCOMMIT」を試してみてほしいです。
まずは数値が正しく参考になるか見てほしいです。

グリーン - 2116@uPwZl2PtPwPP2lw/mg/lJJl//g2 返信 2022/08/16
試してみました。
右端に表示された2つの数値の左側がワーキングセットで右側がコミットサイズの数値ですよね。
どちらもタスクマネージャーやリソースモニターで確認できるのと同じ数値が正しく表示されているようです。

今までトッププロセスMEMで右側に表示されていた数値が10Gとか1Tとかのよく分からない数値になることもあって参考にすることはなかったのですが、今回のコミットサイズのほうが有用な数値だと思います。

Gakuto Matsumura - Developer 返信 2022/08/19
ありがとうございます。

とりあえず
>10Gとか1Tとかのよく分からない数値になる
これはある時期のOSのバージョン以降、そんな感じになってました。
情報の質はとても上がったと思います。

以下グリーンさんの要望を実装してみたテスト版になります。

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220819-211401.zip

○ 警告アラートに、メモリの4種(物理,仮想,コミット,ページファイル)の使用率を追加。
○ トッププロセス
 ・メモリの第二数値を、OSのリソースモニターにおけるコミットと同一のものに変更。
 ・メモリの第二数値でソートする、トッププロセスCOMMITを追加。
 ・色反転の閾値、およびデータバーの母数の指定を、メモリ、コミット、GPUメモリの3種に追加。

グリーン - 2116@uPwZl2PtPwPP2GGPm1uml0glugtt 返信 2022/08/20
実装していただきましてありがとうございます。
テスト版を試してみました。

トッププロセス設定の閾値に達したときの色反転機能は問題なく動作しているようです。
アラート設定のPhysical MemoryやCommit Memoryは問題なく動作しているようですが、Virtual Memoryは「仮想メモリ表示」ONで表示される割合よりも低い数値にしないと通知してくれませんでした。

Virtualが56%と表示されているときにアラートのVirtual Memory設定を56%にしても通知されず、1%ずつ下げていって43%にしたところで通知が表示されたときのスクリーンショットです。

Gakuto Matsumura - Developer 返信 2022/08/20
テストありがとうございます。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220820-113941.zip
>Virtual Memoryは「仮想メモリ表示」ONで表示される割合よりも低い数値にしないと通知してくれませんでした。
すみません、こちら修正しました。

グリーン - 2116@uPwZl2PtPwPP2GGPm1uml0glugtt 返信 2022/08/20
新しいテスト版で修正されているのを確認しました。
これでメモリ不足になる前に対処することができそうです。
ありがとうございました!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 要望 月齢が欲しい。
#877
りんりん - 2114@wPwZZXtmPwu/PP1lgP0uwZX1tgfG1lGl 返信 2022/08/11 21:30
こんばんは。またはこんにちは。いつもサブモニターでめいいっぱいに表示っさせて楽しませてもらってます!自分的にはほとんど最高な環境なのですが、カレンダーだけ少し不満があって、横に広げると数字の間隔が広すぎてしまうのでそこを調整できる機能が欲しく更に月齢が表示できたらいいな~と最近思い始めてきました。できれば採用よろしくお願いします。!

Gakuto Matsumura - Developer 返信 2022/08/11
カレンダーですが、日付と2枠にするオプションはあります。(左右に配置というチェック)

もしこのオプションが希望通りでない場合は、どんな調整が望ましいか教えてほしいです。
例えば単に右寄せか左寄せで空白できてもいいから広がらないようにしたい。とか。

月齢に関して調べてみたところ、緯度経度で指定する場合に使えるリクエストの中に月齢が含まれるものが見つかったので、実際に表示に落とし込める状態にできるか試してみます。

形式が異なるのでちょっと作り直しというか、それ用の取得ルートなどを作る必要があります。

りんりん - 2114@wPwZZXtmPwu/PP1l122Zt00u0J1G2g1t 返信 2022/08/12
遅くに返信ありがとうございます。
カレンダーについてですが、 「間隔」みたいなパラメータ?(写真のやつ)を用意してもらって微調整できるようにしてもらえるとありがたいです。それで空白ができたところに月齢とか、、もしくはカレンダーと月齢の2枠のオプションを用意してもらうとか、それと月齢ですが「新月」とか「満月」とか文字だけではなく図も表示していただけるとかなりありがたいです。お手数おかけしますがお願いします。

Gakuto Matsumura - Developer 返信 2022/08/12
「左右に配置」は確認していただけましたか?

微調整に関しては、先の質問にもあるように、「右寄せか左寄せで空白できてもいいから広がらないようにしたい」ということでしょうか?

さすがに情報が少なすぎて、どんなものを想像されているのかわかりません。
単純に横の間隔を手動調整する機能をつければよいのでしょうか?

りんりん - 2114@wPwZZXtmPwu/PP1lfwfJPPw2luwtltPw 返信 2022/08/12
言葉足らずで申し訳ございません。
青い矢印の部分の間隔を手動調節する機能をつけてもらいたいです。
お手数おかけします
(「左右に配置」は確認していただけましたか?→はい(けど思ったいるのと違う感じです))

Gakuto Matsumura - Developer 返信 2022/08/12
ひとまず、カレンダーに、横幅の調整と右寄せのオプションを追加しました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220812-194210.zip

月齢に関しては、sunset sunriseの所に一応のっけましたが、まだ0.5が満月(0~1)という数値のままの状態です。
とりあえず取れるには取れたという形になります。

図形は少し時間を下さい。
具体的な仕様を考えます。

りんりん - 2114@wPwZZXtmPwu/PP1lZt10u2GXJG0lPJmu 返信 2022/08/12
おーーーーー!!!
そうです!!これですこれです!!
素早い対応本当にありがとうございます!!
月齢についてはしばらくの楽しみにしときますね♪

Gakuto Matsumura - Developer 返信 2022/08/13
とりあえず、ハードウェア描画にて月齢の図形を作ってみました。
こんな感じでよいのでしょうか?

ソフトウェア描画は…うーん

りんりん - 2114@wPwZZXtmPwu/PP1lwG0fl/00ulff022g 返信 2022/08/13
えーと。。

天才ですか!????

Gakuto Matsumura - Developer 返信 2022/08/13
とりあえず、カレンダーの余白に月齢の数値と図をだすようにしました。

また、天気の日の出日の入りの行にも文字の大きさ分の図形を追加しました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220813-211252.zip

こんな感じでいいのですかね?
あと、ソフトウェア描画(ドット計算)でもなんとか形は保っていますが、ハードウェア描画のほうが断然綺麗です。

りんりん - 2115@wPwZZXtmPwu/PP1lgtwl/gggufw/G1wG 返信 2022/08/13
すごいです!まさに僕が求めていたものです!
こんなに短期間で実装してもらいほんと感謝です!!
僕はいつもハードウェア描画を使っているので全然大丈夫です。
もし、test版じゃなくて本アプデ版に組み込むなら緑矢印の隙間は作らず / でもしくは ・ とかなどで区切ってあげたほうが僕的にはいいと思います。(あとONOFFつけるとか)

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 度々、固まってタスクマネージャーからしか終了できない
#875
ひょい - 2103@pCkdYFsK 返信 2022/07/11 00:29

version 0b173 Rev.3 以降のバージョンで、ソフトを起動した後、数時間ほどで、気が付くと固まってしまい、タスクマネージャーからしか終了ができない症状で困っています。
右クリックしてメニューは開けるのですが、「終了」をクリックしても反応しない状態で固まって動きません。

Gakuto Matsumura - Developer 返信 2022/07/11
0b173 Rev.3 以降、ということですが

・発現するシルメラの正確なバージョンとエディション(フロパティ画面を参照)
・OSの種類とバージョン
・設定ファイル(thilmera7.ini)を添付
・数時間をもう少し正確に。およそ1時間なのか9時間なのか。

の情報を下さい。

また、0b174 Rev.8にして解決されないかを試していない場合は必ず試して下さい。

ひょい - 2103@pCAoxPZX 返信 2022/07/12

・発現するシルメラバージョン
→0b173 Rev.3 および 0b174 Rev.8 ( いずれもthilmera7_64 )

・OS
→Windows10pro 21H2

・設定ファイルを添付
→これでいいでしょうか?

・症状が発現する時間
→ソフトを起動して、12時間以上を経過した辺りで、シルメラの表示が固まってタスクマネージャーからしか終了できない。そのさい右クリックでメニューは開けますが、各項目をクリックしても表示に反映・反応がなく、再起動や終了がソフト自体ではできなくなっています。

[appended] ini

Gakuto Matsumura - Developer 返信 2022/07/12
表示項目がかなり限られているので、そこから原因を推測すると、パフォーマンスカウンターの破損、かなぁ、くらいしか思い当たる所がありませんね…

基本的に私は開発機とサブ機で24時間起動しっぱなしのテストを常時行っているので、ここまで少ない処理内容で高々12時間で何かしらの問題が出るような部分は、外部要因以外あまり考えにくい…気がします。

ためしに一度、管理者権限のコマンドプロンプトを開いて
lodctr /r
と打ってエンターし、OSを再起動して解決するかどうか試してみてもらえないでしょうか?

もしそれで解決されるならば、OSのパフォーマンスカウンター関連をメイン処理とは別スレッドに移すなどの対策を行いたいと思います。

ひょい - 2103@pCAoxPZX 返信 2022/07/12
了解しました。
ちなみに、「管理者権限のコマンドプロンプトを開いて~」のOS再起動と、それ以外のwindows updateにともなう再起動であったり、普通に操作して再起動するのとは、何か違いがあったりするのでしょうか?違いがないのであれば、一応、再起動は0b173 Rev.3 以降何度か試しています。

Gakuto Matsumura - Developer 返信 2022/07/12
lodctr /r
のコマンド実行後に再起動しないかぎり、パフォーマンスカウンターは修復されません。

ただ単にOSを再起動するのと、修復コマンドを実行して再起動するのは全く異なります。

ひょい - 2103@pCE0WX7Z 返信 2022/07/14
教えて頂いた通り、lodctr /rのコマンド実行後に再起動しました。
07/12 (火) 15:00頃に再起動して07/13の間は、何の問題もなかったのですが、
07/14(今日)の五時ごろにまた同じ症状で停止しました。
イベントビューアーによると AppHangB1 というイベントが起こったあとすぐにthilmera7s64.exeもwindowsとの対話を停止しました~となっています。
参考の情報になるかわかりませんが、ご報告いたします。

Gakuto Matsumura - Developer 返信 2022/07/14
AppHangB1で調べてみると、AppHangB1エラーの一般的な原因は、ライブラリ(DLL)ファイルが破損か欠落。

とあるので、お手数ですが、以下のコマンドを問題がなくなるまで実行>再起動を行ってみてください。

fsutil resource setautoreset true c:\
DISM /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-image /Restorehealth
sfc /scannow

ひょい - 2103@JALgPZTc 返信 2022/07/17
お世話になっております。教えて頂いたコマンドを実行したところ、
「エラーがあったので修復したました」という表示がでました。
その上でパフォーマンスカウンターを修復するコマンドを実行して再起動しましたが、
やはり前回と同じように1日と14時間くらい経過した所で固まって応答不可でした。

その際、もう一度教えてもらったコマンドを実行しましたが、エラーなどの異常は検知されませんでした。参考の情報になるかわかりませんが、気づいたことは

①(※クロックを1.00Gまでに固定している設定です。)再起動直後、cpuクロックが設定したフレーム速度(一秒)内で、作業負荷のある時などに1.00G→0.99G→1.00Gと時計のように切り替わるのですが、だんだん上下の振れ幅が大きくなっていき、稼働時間38時間ぐらい経過すると数字が1.00G→0.97G→1.03G→1.00G・・・となっていました。

②イベントビューアーによると、イベントid 1002 Application Hang の停止の種類は、
Top level window is idle とありました。


Gakuto Matsumura - Developer 返信 2022/07/17
うーん。
なんだろう…
汎用的にどの環境でも発現する問題ならもっと多くの報告が即上がってくるはずなので、何が原因かを考えると、多分使用者が少ないオフラインモード特有とかでしょうかね…


発現するシルメラバージョンが、0b173 Rev.3と0b174 Rev.8のthilmera7_64とありますが、オフラインモードでの使用ということで間違いないですか?
(thilmera is offlineが表示されている状態)


また、シルメラがフリーズした際、他のアプリケーションで反応しなくなるものは一切ないですか?

タスクマネージャーでシルメラを強制終了させる際、タスクマネージャー上で見えるシルメラのCPU負荷は0でしょうか?それとも非常に高いでしょうか?

ひょい - 2103@JAbtaWTc 返信 2022/07/18
すいません、オフラインモードについてですが、
現在、0b174 Rev.8のthilmera7_64を thilmera7_64.exe という実行ファイルから起動してオンラインの環境で使っていますが、この状態はオフラインモードでしょうか?
thilmera is offline という表示に覚えがなく、オフラインモードで使用しているというのが、どういう状態なのか、分かりません。

シルメラがフリーズした際、他のアプリケーションは恐らくフリーズしておらず、cpuの負荷は確か0でメモリだけ値があった気がしますが、次のフリーズの際に、きちんと調べて御報告しようと思います。

Gakuto Matsumura - Developer 返信 2022/07/18
設定ウィンドウの上部にx64nとかかれていたらオフラインです。

ひょい - 2103@pCE0EgPl 返信 2022/07/19
お世話になっております。やはり再起動=シルメラ起動後37時間ほどでフリーズしました。その際のことを報告します。

1、シルメラはオフラインではなく、オンラインの状態(設定ウインドウx64s)でフリーズしています。
2、今回だけ?なのかもしれませんが、イベントビューアにエラーやハングの記録がありませんでした。
3、他のアプリケーションは、確認できた範囲ではどれもフリーズしていません。
4、タスクマネージャーでシルメラを強制終了させる際、CPU負荷は、0です。
5、タスクマネージャー上で見ると、シルメラは、普段メモリ20MB(cpuはほぼ0)ほどで常駐していますが、フリーズした際は、6~8MBのメモリ消費をしていました。
6、フリーズした際のシルメラなのですが、ウインドウの位置を変えると、稼働時間だけ、位置を変えた瞬間に更新され、その後は他の表示と同じく数値がフリーズするという状態だと分かりました。

・・・どうやら、メモリと表示のことから、おそらくシルメラの数値表示を定期的に、更新したり、設定から操作するコマンドが効かない状態のフリーズのようです。

Gakuto Matsumura - Developer 返信 2022/07/19
なんかだんだんフリーズまでの時間が増えていきますね…

頂いた設定ファイルでデバッグ状態で24時間稼働させてみましたが、とくに何の問題も確認できませんでした。

フリーズといいつつウィンドウが移動できる状態というのは、AppHangB1にはまず該当しない(反応なしのウィンドウは動かせない)ため、エラーの内容や原因が毎回ころころ変わっている。ということになります。

以下のコマンドは問題ないと出ていても何回か繰り返すと改善される事があるので、今一度何度か実行してみてほしいです。

fsutil resource setautoreset true c:\
DISM /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-image /Restorehealth
sfc /scannow

Gakuto Matsumura - Developer 返信 2022/07/20
48時間連続でデバッグを走らせてみましたが、問題の発現は確認はできませんでした。

「設定から操作するコマンドが効かない状態」とのことですが、フリーズした状態で設定ウィンドウは開きますか?

どこが動いてどこが動かないのかを絞り込まないと原因を探すのは難しそうです。

sleepyF - 2111@VuWtR321 返信 2022/07/21
フリーズに関して、私の環境下でもごく稀にフリーズが発生します(長時間稼働&サスペンドするWin7のみ確認。長時間使用しないWin10, WinXPなどでは未確認)。
サービスの停止&開始では復帰せず、タスクマネージャーからプロセスを落とさないとだめになります(それもうまくいかない場合はOS再起動で回復)。
但し発生したのはこれまでで3回程度であり、何日かしてふと見ると止まっていた…という感じであり、起動後の数時間で起こるという頻度ではありません。
現バージョン:0b174 Rev.8(1つか2つ前のバージョン、多分ひょい酸と同じく0b173 Rev.3前後でも発生)

Gakuto Matsumura - Developer 返信 2022/07/21
報告ありがとうございます。

どうやったらフリーズの再現ができるかを調べていくことにします。

フリーズという状態で現在分かっているのが以下の状態です。
① メインウィンドウの更新が止まる
② 終了できない(メニューは出る?)
③ AppHangB1(なるとは限らない)

不明な点は、フリーズ時に
④ メインウィンドウが動かせて、一部更新される(ことがある?)
⑤ 設定ウィンドウは開くか?(不明)

プログラムの反応がないといわれる場合は、ウィンドウメッセージに反応しなくなっている状態。
メインウィンドウの表示が止まっているだけの場合は、メインスレッドが何等かの理由で止まっている。
ただし、メインウィンドウが動かせて、一部更新されるということは、メインスレッドは動いている。

と、謎は深まるばかりです…

Gakuto Matsumura - Developer 返信 2022/07/21
原因と思われる場所を探して全体を見直してみたところ、ハードウェア描画において、OSからの描画指示の際にデッドロックになる事があるというメモ書きの部分が、ソフトウェア描画では処理するようになっていたため、試しにここを修正しました。

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_x64_20220721-200659.zip

こちらのテスト版にて、今までと同様の使用により、低頻度フリーズが発生するかどうかの確認をお願いします。

sleepyF - 2111@VuWtR321 返信 2022/07/22
私の環境下では、フリーズと称しているのは①、②(メニューは出る)、③(なんのことか分かりません)、④「メインウィンドウが動かせて」が「表示内容の動き?」といういみなら動きません。ウィンドウの位置という意味?は試してないので不明。
⑤試してないか1回程度開いてみたかもしれない…(不明瞭)。でもメニューが出るので設定ウィンドウも開くのかも。

thilmera7test_build_x64_20220721-200659.zip も試してみますが、先に書いたとおり私の環境でのフリーズ頻度は低いので(フリーズすれば直ってないと言えますが、逆の判断は難しいです)。ひょいさんの環境で改善がみられれれば多分効果ありなのでしょう。

sleepyF - 2111@VuWtR321 返信 2022/07/22
thilmera7test_build_x64_20220721-200659.zip のテスト結果:
・サービス(thilmera7s64.exe)起動不能
「ローカル コンピューター の thilmera7 service サービスを開始できません。
エラー 1053: そのサービスは指定時間内に開始要求または制御要求に応答しませんでした。」
・単独(thilmera7_64.exe, thilmera7s64.exeとも)起動不能
・Win7 Home SP1 / Win10 Pro 21H2 の両環境で同じ状況

ひょい - 2103@pCEfWX5j 返信 2022/07/22
ご検証ありがとうございます。

現在分かっている①~③について
①ぼくの環境では何故か、最近は34時間前後でメインウインドウの更新が止まります。
②右クリックで、終了をクリックできますが、応答しません。
③参考までにイベントビューアの履歴を添付します。(画像のエラーは全てシルメラのものです。)なぜ、応答しなくなっているのに、ハングしていると記録されたり、されなかったりする理由は分かりません。

不明な点について(④、⑤)
①、②で言った感じで、メインウインドウの更新が止まっていても、
右クリックでメニューを呼び出せて、メニューを展開して、例えばcpuの項目の設定をクリックできますが、まったくメインウインドウの表示に影響しない感じです。
また、左クリックしてメインウインドウ(もしかした左クリックだけでも?)動かすと、その時だけ稼働時間だけ数値表示が更新されます。たとえば、稼働時間の表示が、「1day 13:40、13」の表示でフリーズしているメインウインドウを左クリックで位置を動かすと、
「1day 13:40、14」に表示が変化してまたフリーズしています。 

あと、ぼくも、20220721-200659.zipの中身は両方起動できませんでした。以上です。

Gakuto Matsumura - Developer 返信 2022/07/22
すみません、thilmera7test_build_x64_20220721-200659.zipはデジタル署名が失敗していました。
サインツールが古かったようで、セキュリティからか対応が切られていたようです。

以下でのテストをおねがいします。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_x64_20220722-150805.zip

ひょい - 2103@JAcxDRt3 返信 2022/07/23
お世話になっております。
20220722-150805.zipをテストさせて頂いたところ、同様の症状が確認されました。

・イベントビューアーに、アプリのエラーやハングなどの情報は記載されていません。
・昨日からのテストなので、最近の34時間くらいの間隔より短い時間で、フリーズに至りましたが、やはり気が付いたら、そうなっている感じで、ちょっと原因は特定できませんでした。

Gakuto Matsumura - Developer 返信 2022/07/23
報告ありがとうございます。

目をつけた部分の可能性を更に掘り下げてみました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_x64_20220723-211445.zip

もし目星のものが原因ならば、単に時間経過ではなく、PC上の操作が関係するので、ひょいさんの普段通りの使用にて確認していってもらえると助かります。

ひょいさんの環境と使い方だとほぼ確実に問題の個所が直っていない場合は確認できそうなので、しばらくお付き合い頂けるとありがたいです。

ひょい - 2103@JAqiI4Hy 返信 2022/07/25
お世話になっております。
20220723-211445.zip、ありがとうございます。早速テストさせていただいた所、やはりメインウインドウの更新が止まるという症状が確認されてしまいました。
ええと、「単に時間経過ではなく、PC上の操作が関係する」ということですが、こちらが普段通りの使用以外で、何かやったほうがいいこと等ありますでしょうか?
ちなみに、テストバージョンを使用して、フリーズしたら、
その度に lodctr /r や 再起動などした方がいいでしょうか?
フリーズした際に、スキャンするコマンドで何かエラーが無いか探していますが、
原因が見つからず、どうしたらいいのか分からずにいます。

Gakuto Matsumura - Developer 返信 2022/07/25
報告ありがとうございます。
一つ一つ可能性をつぶしていっているので、おそらく問題の一つだったAppHangB1は修正できてると思います。

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_x64_20220725-214110.zip
「単に時間経過ではなく、PC上の操作が関係する」の問題とは別の問題がもう一つあるようなので、こちらに切り替えての動作テストをおねがいします。

lodctr /r や 再起動は今のところしなくてもOKです。

止まった状態でもウィンドウを動かしたら起動時間だけ更新された。というヒントから、論理的にフレーム待機から抜けない状態になる可能性があるバグへの対処をしました。

ひょい - 2103@pCAVjmNq 返信 2022/08/01
お世話になっております。
20220725-214110.zip ありがとうございます。多分もう「タスクマネージャーからじゃないと終了できないフリーズ」の状態は起きないです。(たいへん嬉しいです)

テストをさしていただいて、気づいた点は、
1、
07/17 の書き込みでご報告した ① 時間経過とともに、負荷時のcpuクロックの値のブレが大きくなるという現象についてですが、これは以前のバージョンからこういう現象があったのですが、テスト版では一定時間を経過すると、こちらが設定したcpuクロック値からブレなくなりました。(ずっと1.00Gの表示)ただ、シルメラを再起動させると、また元の時間経過と共にブレた数値を表示するようになりました。個人的な感想ですが、数値がブレずに表示された方が何となく快適でした。
2、
気のせいかもしれませんが、ウインドウの「最前表示」にチェックを入れていても、いつのまにか、最前で表示されなくなっています。(特に問題はないです。)

以上です。

Gakuto Matsumura - Developer 返信 2022/08/01
テスト&報告ありがとうございます。

1ですが、そもそもCPUはIntelとAMDどっちですか?
時間経過しないとぶれるとのことですが、どの程度の時間経過でしょうか?
最初の数十秒ならば内部的な負荷なので難しいです。

2はものすごくやばいです。
以前のiniでは最前表示+常時でしたが、常時がオフになってるとかではなく最前表示になりませんか?

確認をおねがいします。

ひょい - 2103@pCEfz3t3 返信 2022/08/02
すいません訂正になりますが、
08/01に報告した 2 についてですが、常時がオフになっているのを見逃していました。うっかりしていました。最前表示には問題はないです。

あと、08/01の 1 についてですが、cpuはAMDです。
cpuを(再)起動してすぐシルメラを起動したときは、
cpuクロックは、1.00Gと0.99G、の二つの表示を負荷の際に交互に表示している感じですが、たぶん数時間~12時間ぐらいの間隔で、1.00Gを挟んで、
0.98⇔1.00⇔1.01・・・・・(数日後)0.85⇔1.00⇔1.15 のように変化します。
これは今回ご報告させていただいた、「タスクマネージャーからしか終了できない」件以前から、こういう感じでしたので、たぶん僕のPC環境のせいかなと思っています。

テスト版を使用させていただいて、この数値のブレが(これも数時間から12時間くらい?)ビタッと1.00Gなどに固定される現象が起こり、なんというか、この固定された表示の方が、見ていて快適だったので、もし良ければ、こういう表示を残してほしいという個人的な要望を報告しました。
追加で分かったことなのですが、この数値の固定現象、必ずしも1.00Gに固定されるわけではなく、先ほどは、0.92Gという表示で固定されていました。どうやら、時間の経過か、もしくはスリープから復帰した際などの負荷があった時に表示されているクロックの値で固定されるようでした。

以上です。

Gakuto Matsumura - Developer 返信 2022/08/02
1 よかったです。

2 多分、クロック取得スレッドが固まった説があるかもしれません。
というより、1.00でぴたっと止まるというのがものすごく不自然なので、

repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_x64_20220802-211018.zip

ちょっと上記のさらに改善したバージョンで、どう表れるか確認をおねがいします。
このバージョンは全ての更新スレッドが意図せず待機状態のままになってしまう不具合への対策をしたものになります。

ひょい - 2103@pCaEiQd2 返信 2022/08/13
お世話になっております。
20220802-211018.zip、ありがとうございました。
前回までのテスト版であった、cpuのクロックが固定されてしまう現象は、もう起きてないです。恐らく「全ての更新スレッドが意図せず待機状態」になることは、自分が表示している項目ではないと思います。テスト版の制作、本当にありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

報告 ディスクI/Oの%表示が変?
#876
ANACOSTIA - 2107@PPwZZ1Pw2g1wPPgtGfGJuZtGg0Jgmw2/ 返信 2022/07/18 23:58
 (自動アップデートにより、)いつからか、PC自体がアイドルに使い状態の時でも、[ドライブ]→[ディスクI/O]の%表示の数値(ディスク(ドライブ)のアクティビティ率。転送速度ではなくビジー状態の割合。 by 弦生ささと - admin 2021/07/29 (木) 18:36 (775,5442))が殆ど100%で固定されるようになってしまいました。

 この時、Windowsの[パフォーマンスモニター]で[LogicalDisk]→[対象ドライブ]→[% Disk Time]及び[% Idle Time]を確認すると、[% Disk Time]は0位で殆ど一定、[% Idle Time]は100位で殆ど一定になっています。
 [PhysicalDisk]の方も同様の結果です。

 これまでは、thilmeraの[ディスクI/O]の%表示が100%に張り付き続けるということはありませんでした(何か多量のファイルのやり取りその他の操作をしない限りは)。
 この状態が正常な動作・表示なのかどうか、確認をお願いしたいです。

Gakuto Matsumura - Developer 返信 2022/07/19
thilmeraのディスクI/Oが100%になる理由は大抵はOSのパフォーマンスカウンターが破損などにより0を返している場合が殆どです。
この場合はヘルプの「表示がおかしい」の一つ目にある、管理者権限のコマンドプロンプトdから「lodctr /r」を実行し、OS再起動で大抵直りますが、これはもう試されましたでしょうか?

ANACOSTIA - 2108@PPwZZ1Pw2g1wPPgtPXGwtZm/ffuXluJt 返信 2022/07/19
 早速のご返答ありがとうございます。
 未試行でしたので、先程実施してみました。
 しかし、残念ながら症状は変わらずです。

 現在2台のIntel-CPU-PCを使っていますが、2台とも同じ症状が出ています。
 朧げな記憶ですが、version 0b174(但しRev.不明)に自動アップデートされた辺りからこの症状が出たような気もします(2台のPCの運用の違いから、自動アップデートの時期がズレており、発生時期が明確ではありません)。

 尚、この症状が出た際に取り敢えず

・イベントビューアーから、関連しそうな異常がないかの確認
・SSDのSMARTに異常がないかの確認(thilmeraと他ソフトとの両方で)
・[コントロールパネル]→[メンテナンス]→[信頼性履歴の表示]で関連しそうな異常がないかの確認

を行い、取り敢えず差し迫った問題は無いと判断し、その内thilmeraのRev.アップでこの症状が無くなるのだろうと軽い考えでいました。
 しかし、100%に張り付き続けるのがずっと続くのにもどうかと思うようになったので、投稿した次第です。

Gakuto Matsumura - Developer 返信 2022/07/19
報告ありがとうございます。

確認してほしい事と、設定ファイルを添付していただけると助かります。

確認してほしいのは、
① DiskI/O全体だけでなく、各ドライブ「ディスクIO一覧」も全て100%になるかどうか。
② 100%固定の状態が常に続くのか、もしくはほぼ100%になるが、それ以下になることもある(変動が見られる)か。

2台ともということなので、なんらかの条件によりなる内部的な可能性が考えられますが、まずは設定ファイルによりこちらで再現できないか試してみたいです。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgtPXGwtZm/ffuXluJt 返信 2022/07/19
 thilmera7.iniを添付しました。

①について
 [ディスクIO一覧]を有効にすると、Cドライブ分が追加されますが、元々の[Disk:]と同時に100%になります。
 元々、PCにはSSDが1つしか装着されておらず、更にGPT特有のパーティションを除けば、OSから通常見えるドライブが1つ(Cドライブ)のみなので、こうなるのは当たり前なのでしょうけど。
 この件に関しては、2台のPCの内、片方のPCしか確認できていません。

②について
 時々100%未満となります。
 PC2台ともそうなります。

③[FullR]について
 これまで[ドライブ]→[ディスクIO]の[FullR]が有効でしたが、これを無効にすると表示が正常になるように見えます(これに関しても、PC2台ともそうなります。)。
 しかし、[FullR]は以前から(100%貼り付き問題が発生する前から)有効だったと思います。
 [ANACOSTIA - 2021@BSadaW6T 返信 01/13 (木) 20:36 (817,5627)]でもthilmera7.iniを添付しましたが、このファイルは[FullR]が有効になっているのではないでしょうか?(少なくともこの時は、100%貼り付き問題は起こっていなかった)
 残念ながらこの時のファイルが手元に無いので、申し訳ありませんが、こちらでの検証はできません。

④IOテキスト更新頻度
 フレーム速度をFPS:60(wait:0.016s)とし、[更新フレーム頻度-I/O]を15としています。
 なので、ディスクI/Oのバーは60Hz、テキスト(ReadとWriteそれぞれの速度(MB/s))は4Hzで更新されるようになります。
 しかし[ディスクI/O]の%表示は60Hzで更新されているようです(以前はどうだったのか記憶にありません……)。
 この[ディスクI/O]の%表示も、ReadとWriteそれぞれの速度と同じく、[更新フレーム頻度-I/O]の値が反映されて欲しいです。

[appended] ini

Gakuto Matsumura - Developer 返信 2022/07/19
なるほど。フレーム速度60FPSという時点でなんとなく原因はわかりました。

仕様として明記していないのが悪いのですが、FullR時のディスク稼働率は、最高値を採用します。
そしてディスク稼働率は、統計期間が短くなればなるほどピーキーに100%をだしやすい(0or100みたいなのが繰り返される)ので、根本的にFullR時の仕様を作り直す必要がありそうです。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgtXfwX0wJlmmJGJ/0l 返信 2022/07/20
 ディスクI/Oの[FullR]に関しては、CPUの[フルデータバー色反転]、GPUの[フルバー色反転]、トッププロセスの[フルバー色反転]と同じイメージで捉えていました。
 現に、以前は100%貼り付きが起こっていなかったと記憶しているからです。
 バージョンヒストリを見ると、100%貼り付きが起こるようになったのは、version 0b172 Rev.8でフレーム速度関係を変更してからなのかもしれませんが、小生の頼りない記憶からは、ここから発生するようになったという認識はありません。

 取り敢えずは[FullR]を無効にすることで解決できると考えております。
 データバーやテキストの更新頻度に応じたサンプリング範囲の最大値ではなく平均値を採ることで、最終的な解決が得られれば有り難いです。

Gakuto Matsumura - Developer 返信 2022/07/20
FullR時の最高値採用の理由は、100%近辺になった場合に激しく明滅してしまうため、非常に見づらいからでした。

パーセント表示の取得と更新間隔を、更新フレームIO準拠に変更してみました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220720-223139.zip

Gakuto Matsumura - Developer 返信 2022/07/20
FullR時も、サンプルからの最高値採用ではなく更新フレームIOの間隔での値をそのまま使用します。

ただ、当然ながら更新フレームIOの時間が短くなればなるほど値はピーキーになっていきます。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgtg211wg02flXtmfmG 返信 2022/07/22
 ありがとうございました。
 repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220720-223139.zip(0b174 Rev. 8.5) で問題は起こっていません。

 時間・精神・その他に余裕があれば、CPU & GPU 丸め(平均)、フレーム速度の基本ウェイト時間、フレームあたりのテキスト更新頻度を整理して、データバー、グラフ、テキストの更新頻度と丸め方(平均値の算出法)の見直しをすることも考慮すべきかもしれません。
 現在の自分の設定でいえば、
・データバー(及び100%で反転)は1/60秒間にサンプルした(全データ又は間引いた)データの平均値を60Hzで表示
・テキストは1/4秒間にサンプルした(全データ又は間引いた)データの平均値を4Hzで表示
という実装にするなどです。

Gakuto Matsumura - Developer 返信 2022/07/22
見直しということですが、具体的に今とどう変わるのでしょうか?

現在は、ベースとなる更新フレーム速度1に対し、グラフとバーは1更新。
IOなどのフレーム数指定により、20とすると、テキストは1/20更新となります。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgt2g2/01flwt2m10u/ 返信 2022/07/23
 他人に理解させることができない表現で申し訳ありません。


 まずは確認(認識の共通化)です。

> ベースとなる更新フレーム速度1に対し、グラフとバーは1更新。

 この更新に使うデータの取得法はどうなっているのでしょか?
 バーとグラフの更新頻度は1回/(60秒~1/60秒)(=1/60Hz~60Hz)ですが、例えばここで1回/秒(=1Hz)とします。
 この時、[CPU & GPU 丸め(平均)]の設定で、

・スルー    の時は、1秒間で 1サンプルし、そのデータを1秒間のバー&グラフ表示に使用
・前回との平均 の時は、1秒間で 2サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・10回平均   の時は、1秒間で 10サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・20回平均   の時は、1秒間で 20サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・50回平均   の時は、1秒間で 50サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・100回平均   の時は、1秒間で100サンプルし、その平均値を1秒間のバー&グラフ表示に使用

ということなのでしょうか?

 また、1回/(1/60)秒(=60Hz)の時は、

・スルー    の時は、1/60秒間で 1サンプルし、そのデータを1/60秒間のバー&グラフ表示に使用
・前回との平均 の時は、1/60秒間で 2サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・10回平均   の時は、1/60秒間で 10サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・20回平均   の時は、1/60秒間で 20サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・50回平均   の時は、1/60秒間で 50サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・100回平均   の時は、1/60秒間で100サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用

ということなのでしょうか?

 テキスト更新頻度も同様です。
 バーとグラフの更新頻度を1回/(1/60)秒(=60Hz)とし、テキスト更新頻度を15(イコール4Hz)の時は、

・スルー    の時は、1/15秒間で 1サンプルし、そのデータを1/4秒間のテキスト表示に使用
・前回との平均 の時は、1/15秒間で 2サンプルし、その平均値を1/4秒間のテキスト表示に使用
・10回平均   の時は、1/15秒間で 10サンプルし、その平均値を1/4秒間のテキスト表示に使用
・20回平均   の時は、1/15秒間で 20サンプルし、その平均値を1/4秒間のテキスト表示に使用
・50回平均   の時は、1/15秒間で 50サンプルし、その平均値を1/4秒間のテキスト表示に使用
・100回平均   の時は、1/15秒間で100サンプルし、その平均値を1/4秒間のテキスト表示に使用

ということなのでしょうか?


 そして、上記認識が正しいとした場合の当方の希望改善案ですが、

(1) [CPU & GPU 丸め(平均)]の設定にある、

・加減制限25%(前回の値と今回の値の差が25%以上の場合は差異25%とする)
・66%変動( (今回の値×2+前回の値)/3 )
・33%変動( (今回の値+前回の値×2)/3 )

を廃止。

(2) [CPU & GPU 丸め(平均)]の設定にある、[スルー、前回との平均、10回平均、20回平均、50回平均、100回平均]の対象を、CPUとGPUだけではなく、[メモリ]、[ドライブ]、[マザーボード, 電源, Hyper-V]、[ネットワークI/O]、[プロセス]にも反映。

 現状、これが無いので不便・不満を感じるということは少ないので、「そういえばこんな要求もあったなぁ」と記憶の片隅に留めて置いて貰えれば十分です。

Gakuto Matsumura - Developer 返信 2022/07/23
[CPU & GPU 丸め(平均)]というのは、元々は開発当初の2001年から残っている遺物です。
基本的に指定のフレーム速度が最速の1サンプル(1クロックと考えてもらえればよいです)となります。

1フレームが1秒である場合、
10回平均は1秒間で10サンプルではなく、10秒間の平均値をとります。

テキストは、この1クロックに「更新フレーム頻度」の数値をかけた回数で更新され、前回更新してからの平均値が出されます。
つまり、60hzのWaitで、更新フレーム頻度が20の場合、テキストの更新は3hzで、20回分の平均値となります。

ただ、ここで誤解がないように補足しておくと、ほとんどのサンプルデータは、期間が長くなればなるほど平均化されます。

例えば、60hzで取得した60サンプルの平均と、1hzで取得した1サンプルの数値はほぼ誤差の範囲になります。(温度系などは瞬間値なのでこの例には当てはまらない)

(1)
廃止に関しては、廃止すると利用している人がいた場合に元に戻してくれという話になるので(これは流石に使わないだろうという機能の撤廃で過去何度も発生した事案)、これに関しては残しておくことにさしてデメリットが思い当たらないので、ちょっと難しいです。

(2)
メモリ、マザーボードは完全に更新フレーム頻度に依存し、リアルタイムな値を出しているので、平均という概念がそもそもありません。

Hyper-VはCPU,GPUと同じ設定が適用されます。

ドライブとネットワークIOは、デフォルトの10回平均ではあまりにもガタガタしすぎるので、まとめるのは難しいです。
ちなみに現在は約2.5秒程度の平均化となっていますが、これを変えたいならば設定を作るのは構いませんが、少なくともデータの現れ方がCPUなどとは全く異なるため、一律な設定にしたら極めて見づらくなってしまいます。

トッププロセス関連は更新フレーム頻度に依存します。これも「60hzで取得した60サンプルの平均と、1hzで取得した1サンプルの数値はほぼ誤差の範囲になる」が適用されます。

ANACOSTIA - 2112@PPwZZ1Pw2g1wPPgt2g2/01flwt2m10u/ 返信 2022/07/24
 ご丁寧な回答ありがとうございました。

 ところで、フォーラム上にある今回のような内容の記述(ヘルプに記載があってもおかしくないような内容の記述)を、ヘルプに逐次追加していくようなことはできないのでしょうか?
 正直なところ、ヘルプにある記載と設定画面におけるポップアップの説明だけだと、設定内容の意味や設定値選択の判断に苦しむことがあり、フォーラムを検索したり、それでも欲しい情報が無ければフォーラムへ質問を投稿しているのが現状です。

 本フォーラム(BBS)の記述が古いものから削除されるのかは存じておりません(閲覧可能な一番古い投稿が2009/10/14のものですが、これより以前に本フォーラムへの書き込みは無かった??)が、もし古いものから削除されていくのであれば(例えそうでなくとも)、弦生ささとさまの独断と偏見で、「これはヘルプに追加した方が良いかな」と思われる記述の内容をヘルプに順次ぶち込んで戴ければありがたいと考えております。

 勿論それに伴う作業負荷を最小限にする為に、(タイトルだけは熟考する必要がありますが)フォーラムのやり取りをそのまま(直接関係ない部分の削除も最低限行った方が良いでしょうが)、[ヘルプ]→[トラブルシューティング]→[Q&A]のような形で追記していくものです。
 如何でしょうか?

Gakuto Matsumura - Developer 返信 2022/07/24
書いてみました。
thilmera.com/?page=help&lang=ja&i_ID=49
すみません、テキストの中身が前回からの平均というのは間違いでした。


ヘルプに記載がない質問を受けた仕様についてはもちろん今までと同様にヘルプに追加していきます。

ヘルプにも、疑問が記載されていない場合は質問してほしいと記載しているのは、開発者の立場からすると、何が分かって何が分からないか(何が気になって何が気にならないか)はユーザーでないとなかなかわからないので、疑問点は聞いて頂ければこたえられる範囲でまとめますし、今まで同様ヘルプにも追記していきます。

Gakuto Matsumura - Developer 返信 2022/07/25
書き忘れてました。
2009年10月時点のものが最古になります。
それ以前はややこしいのですが、多分シルメラの旧BBSが全く別形式で、それより前はフルJavaで書かれていたsPherTiaというサイトのBBSとごっちゃになってたのではないかな…

過去のバックアップを掘り起こしたらワンチャン見つかるかもしれませんが、観覧できるようにするのはちょっと手間かもしれません。
手間のわりに古すぎて内容に意味があるかも疑問です。

ANACOSTIA - 2113@PPwZZ1Pw2g1wPPgtuG00t2mlJ0/JlZ0X 返信 2022/07/26
 データの取得頻度、表示に際した代表値化方法、表示の頻度に関し少しだけ理解できました。

 ヘルプの記載と設定画面のポップアップの説明に無い情報を順次(勿論、精神的・時間的余裕のある時に限る)加えて欲しいと思ったのは、以前の小生の質問に対する回答(弦生ささと - admin 返信 01/15 (土) 17:03 [817,5632])も載っていないしなぁと感じていたからでした。

 旧BBSの件ですが、そこにしかない貴重な情報(ヘルプやポップアップに無い情報)が少なくない量で埋もれており、そして殆ど手間をかけずに可能というのであれば、是非公開ログデータ化して欲しいです。
 質問と回答の関係が明確になっていれば、単なるプレーンテキストで構わないというのが小生の考えです(この為だけに新たにスクリプトを組む必要も無い)。

Gakuto Matsumura - Developer 返信 2022/07/27
とりあえず2002-2005年くらいのデータはでてきましたが、やっぱり中身が殆ど私の作曲した曲の話とかですね。
しかも整形スクリプト書かないととてもではないがどこからどこまでが本文かわからん…

2005-2009の間は見つかりませんね…

この掲示板の最古データまでのはいくらでも見つかるんですが、多分2005-2009は落ちまくる自宅サーバー時代で、もしかしたら中身にあるかもしれないmysqlのバージョン不明のバイナリデータくらいしか見つかりませんでした。
test, test1 test2 というテーブルにない場合はこのバイナリデータを解析しても中には無いです。

貴重な情報とのことですが、どんなことが書かれてましたか…?

Gakuto Matsumura - Developer 返信 2022/07/27
認知される切っ掛けになったvectorの初登録が2009/07/20なので、2009/07/20から2009/10/14の3か月弱の間は多分vector上の掲示板が本体ですね。
vectorのコメント上でサポートしてたのを今更思い出しました。
comment.vector.co.jp/comment.php/477492/4
そりゃ手元にデータないわけだ。

この掲示板では
2009/10/14 (水) 21:18 の #2 CPU温度誤差報告スレッド【0b26以降】
が最も古いです。
#1はテスト書き込みして消しただけなので、実質消えたものは何もないです。
update
返信

*オープンクローズ
 + 
#
thilmera project - forum
フォーラム一覧
t7b - v12.30.0.0
Original - Board v3.4 Revision(http://revision.s22.xrea.com/)
© 2001-2024 Gakuto Matsumura:弦生ささと (thilmera7gmail.com) Privacy Policy