ラベル Windows の投稿を表示しています。 すべての投稿を表示
ラベル Windows の投稿を表示しています。 すべての投稿を表示

2025年7月28日月曜日

31.1.2

公開されてましたが、まだリリースのLastestになっていない様子。


UI関連の視点ではYami.obtのスクロールバーのサイズが設定されるようになったことや、今までspacing: var(--spacing_small);と全体的に設定されていたものが、スライドバーやチェックボックス、ラジオボタン、メニューバー、グループボックスに限定されるなど微調整が入っている様子。

スピンエディットには変更がないようなので現行のままだと左右の余白が多すぎな状態でした。

個人的なカスタマイズ部分は変わりなくマージできたのでこの辺のテコ入れはなさそうと判断し、pullリクエストでも…とドキュメントを見たらちょっと面倒そうなのでこのままかなぁw


一応ソースは手前のリポジトリには上げてたりするので変更点はそれなりに行けるとは思うけど、 GitHubの特定のtagからのブランチとか上手くできないので常にその時点のmasterからしかできていないのが難点。GitHubの使い方もう少し調べないと…

あと、メインウィンドウのドック状態のサイズ変更のフォーカス時の区切り線が残ったりするようになった感じ…前からかもしれませんが。 

2025年7月16日水曜日

地味に設定画面が画面からはみ出てるので…

obs-studioをビルドして確認するために実行する。

すると、メインで使っている画面で設定画面を開くと、設定のウィンドウが微妙に画面からはみ出しているという…

タスクバーを隠れるようにすればいいんだろうけど。というわけで、設定値を確認してみると、\obs-studio\frontend\forms\OBSBasicSettings.ui

<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
 <class>OBSBasicSettings</class>
 <widget class="QDialog" name="OBSBasicSettings">
  <property name="geometry">
   <rect>
    <x>0</x>
    <y>0</y>
    <width>981</width>
    <height>730</height>
   </rect>
  </property>
:

現在使用中のモニターを見ると1920x1080で大丈夫そうですが、拡大/縮小で150%(推奨)というのが問題になってそうです…

まぁ何と言うか、とりあえずやっつけでデフォルト値を弄っておけばいいかな?

ザックリ考えると、古典的な考えで800x600とかでいいかとか。

まぁとりあず画面内に収まってるからこれで良しとしようw

一般的にはメインウィンドウが存在するデスクトップウィンドウのサイズを取得して、作業領域に収まるように表示させるのですが、あまり凝りすぎると付加処理が悪さをすることも。まぁその辺は気が向いたらコードを弄るのがよさげかな?
 

QSpinBox padding

グレー枠の原因はあきらめて、31.1からやたら大きくなってしまったSpinBoxの原因を探ってみました。

色々と見て行くとどうやらYami.obtというstylesheetフォーマットのファイル中にたどりつきました。

ただ実際にどのように反映されているのか良くわかっていなく、このファイルを反映するにはリビルドすることが必須となってしまっていてトライアンドエラー方式で確認するのは結構痛いかった。そのうちpowershellでfindstrを使ってソース検索したときに

obs-studio\build_x64\rundir\Release\data\obs-studio\themes\Yami.obt

obs-studio\frontend\data\themes\Yami.obt

と表示され、単純にコピーされているだけという事実に…。記憶でどこかにobs-studioを使い始めたときにスタイルシートがどこかに入っていた記憶があったのだが、ユーザーフォルダ内のAppData\Roamingの中を探してなかったのであきらめていたが、よく考えればインストールフォルダにあるのが当然なのですが。

コンパイルの必要が無くなり、ようやく細かな点を確認できるようになりました。 

31.1からスペーシングやパディングを変更したために悪影響が出ているのと、全体的に修正作業がやっつけっぽいので細かいところでいろいろとおかしくなっています。

ザックリと31.0.4のYami.obtの比較しても全体的に修正が加わっているためにパッと見ではよくわかりませんが、細かく見て行くとQSpinBoxはベースとなるQPlainTextEditとQSpinBoxに付随するup-button,down-buttonが組み合わさって構成されていました。(Qtのドキュメントを見た方が早いとは思う…が、) 

最初にQSpinBoxのpaddingの記述が違っているのでそこから様子を見ることに。

結論から言えば、QSpinBoxは内部のQPlainTextEditのpadding分と自身のpadding分が反映されるため、巨大化しているようです。極端な話、QSpinBoxのpaddingを 0px 0pxで指定すれば全体的にスッキリします。ただ、スピンのボタンが小さくなりすぎるので、UIデザイン的には反則気味にw

31.1の変更状態を考慮すると、marginは触らずにpaddingだけで行っている感じがするのと、QSpinBoxはやはり大きめにしたいのではないかと考え、

QSpinBox,
QDoubleSpinBox {
    background-color: var(--input_bg);
    border: 1px solid var(--input_bg);
    border-radius: var(--border_radius);
    padding: var(--input_padding) var(--input_text_padding);
    padding: var(--input_padding) 0px;
    height: var(--input_height);
    max-height: var(--input_height);
}

としてみました。左右の無駄なパディングを消した形です。31.0.4と比べ、height指定が増えていますが、これ、正直意味をなしていないようで…。

あとは気になるポイントとしてはスピンボタンの上下にある間の隙間。それとこれでも右側の隙間が無駄に存在している点も気にはなります。min-widthとか設定できたりするのかな?

試行錯誤中の状態がこちら 



何となく行けそうな雰囲気?

2025年7月15日火曜日

obs-studio githubからのビルド

このブログだとあまり明記していなかったので具体的なビルド手順を載せておこうかと。

必要な環境は、git, cmake, visual studio 2022ぐらいかな?現時点では全て誰でもダウンロード可能です。

ビルドに必要な空き容量NTFSで 6.26GB となっていました。

PowerShell 7.5.2
PS C:\Users\xxxxx> mkdir S:\obs\31.1.1\

Directory: S:\obs

Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 25/07/15 09:12 31.1.1

PS C:\Users\xxxxx> s:
PS S:\> cd \obs\31.1.1
PS S:\obs\31.1.1> git clone --recursive https://github.com/obsproject/obs-studio.git -b 31.1.1 --depth 1
Cloning into 'obs-studio'...
remote: Enumerating objects: 5326, done.
remote: Counting objects: 100% (5326/5326), done.
remote: Compressing objects: 100% (4434/4434), done.
remote: Total 5326 (delta 879), reused 3056 (delta 657), pack-reused 0 (from 0)
Receiving objects: 100% (5326/5326), 14.86 MiB | 14.24 MiB/s, done.
Resolving deltas: 100% (879/879), done.
warning: refs/tags/31.1.1 4b56b9b214967c6f0143e36f722c64c6d755d55f is not a commit!
Note: switching to 'a32b3f9f6d5e1cf6fa0f8105a2ed46ec0b4d991c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

git switch -c <new-branch-name>

Or undo this operation with:

git switch -

Turn off this advice by setting config variable advice.detachedHead to false

Updating files: 100% (5043/5043), done.
Submodule 'plugins/win-dshow/libdshowcapture' (https://github.com/obsproject/libdshowcapture.git) registered for path 'deps/libdshowcapture/src'
Submodule 'plugins/obs-browser' (https://github.com/obsproject/obs-browser.git) registered for path 'plugins/obs-browser'
Submodule 'plugins/obs-websocket' (https://github.com/obsproject/obs-websocket.git) registered for path 'plugins/obs-websocket'
Cloning into 'S:/obs/31.1.1/obs-studio/deps/libdshowcapture/src'...
remote: Enumerating objects: 1037, done.
remote: Counting objects: 100% (604/604), done.
remote: Compressing objects: 100% (96/96), done.
remote: Total 1037 (delta 537), reused 511 (delta 508), pack-reused 433 (from 2)
Receiving objects: 100% (1037/1037), 332.23 KiB | 10.07 MiB/s, done.
Resolving deltas: 100% (722/722), done.
Cloning into 'S:/obs/31.1.1/obs-studio/plugins/obs-browser'...
remote: Enumerating objects: 3799, done.
remote: Counting objects: 100% (1676/1676), done.
remote: Compressing objects: 100% (444/444), done.
remote: Total 3799 (delta 1376), reused 1258 (delta 1232), pack-reused 2123 (from 2)
Receiving objects: 100% (3799/3799), 1.09 MiB | 10.11 MiB/s, done.
Resolving deltas: 100% (2594/2594), done.
Cloning into 'S:/obs/31.1.1/obs-studio/plugins/obs-websocket'...
remote: Enumerating objects: 6189, done.
remote: Counting objects: 100% (823/823), done.
remote: Compressing objects: 100% (203/203), done.
remote: Total 6189 (delta 656), reused 631 (delta 618), pack-reused 5366 (from 4)
Receiving objects: 100% (6189/6189), 1.75 MiB | 10.62 MiB/s, done.
Resolving deltas: 100% (4258/4258), done.
Submodule path 'deps/libdshowcapture/src': checked out '8878638324393815512f802640b0d5ce940161f1'
Submodule 'external/capture-device-support' (https://github.com/elgatosf/capture-device-support) registered for path 'deps/libdshowcapture/src/external/capture-device-support'
Cloning into 'S:/obs/31.1.1/obs-studio/deps/libdshowcapture/src/external/capture-device-support'...
remote: Enumerating objects: 60, done.
remote: Counting objects: 100% (60/60), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 60 (delta 30), reused 41 (delta 19), pack-reused 0 (from 0)
Receiving objects: 100% (60/60), 34.39 KiB | 5.73 MiB/s, done.
Resolving deltas: 100% (30/30), done.
Submodule path 'deps/libdshowcapture/src/external/capture-device-support': checked out 'fe9630974d47f51bf54826e72fb8b654e620aa93'
Submodule path 'plugins/obs-browser': checked out 'bdabf8300ecefeb566b81f4a7ff75f8a8e21f62b'
Submodule path 'plugins/obs-websocket': checked out '40d26dbf4d29137bf88cd393a3031adb04d68bba'
PS S:\obs\31.1.1> cmake-gui
PS S:\obs\31.1.1>

cmake-guiが起動した後は、上の方から設定します。

Configureを押し、ビルドするフォルダの作成の確認をした後、終了するまでしばらく待ちます。完了したらGenerateを押し、またしばらく待ちます。終わったらOpen Projectを押すとVisual Studio2022が起動します。


実際にビルドするには必要かどうかわかりませんが、ソリューションの構成をReleaseにしてデバッグなしで開始(Ctrl+F5)を押すと実行ファイルの作成が始まります。この状態で放置して、しばらくすると(手元のネットブックだと35分ほど)obs-studioが実行された状態になります。

一回ビルドを通しておけば、ソースの修正などを行う時に型チェックなどがまともになるので時間があるのであれば一度ビルドしておくことをお勧めします。

失敗するパターンとしてはファイルシステムがWindowsではNTFSでないとcmakeでエラーが出て進まなくなりました。 

2025年7月12日土曜日

31.1.0が4日前にリリースされてたっぽいですね

31.0と31.1はソースの配置位置が変わっていたりファイル名が変わっていたりと、内部的には大きく手が入っている印象がありました。

ドキュメントを見ると結構ダイアログの修正や内部的なバグの修正など行われているみたいです。

UIの見た目で嬉しいのは、コントロールの大きさがデザイン系から独立して変更できる点でしょうか?全体的にコンパクト収まるので、クラッシックを使用していましたが、今後はもう少し選べる選択肢が増える感じ。

手を加えた状態はこんな感じに

時分秒のエディットボックスが大きくなってる気がします…世間的には出力タイマーのウィンドウは大きくしたいのだろうか?

そして相変わらずプレビューのグレー枠の原因が分からない…orz 

2025年7月7日月曜日

やはり余計なプラグインが入っていたのが原因だった

先日の出力タイマーの時間が保持されないと言った原因はリネームしたプラグインが原因でした。

しかも2つ…プラグインフォルダのファイルを取り除いて起動するとスッキリしました。

 

やはりこちらはプレビューの枠が無い状態。ウィンドウの大きさを変えても出てこないのでどこかの設定が違うだけなのか? 

2025年7月5日土曜日

プラグインフォルダ

プレビューのグレー枠が気にはなっていますが、それ以外にも少し気になる点が。

こちらは手を加えた出力タイマーですが、時間設定の変更をしてobs-studioを再起動するとどうも時間が変更する前の状態に戻っているという謎現象。

ソースを追うと時間設定値を開始時にはファイルからリストアされて、終了時にはファイルに保存されている部分がありました。具体的には

C:\Users\[ユーザー名]\AppData\Roaming\obs-studio\basic\scenes\[シーン名].json

内のoutput-timerに保存されています。更新状況を見ると毎回終了時に書き出されているのが確認できました。

コンパイル環境では出力タイマーの時間設定値は更新されていて、実際に使用している環境だと時間設定値が変わらないという状況で、原因がよくわからないので一旦obs-studioのファイルの整合性チェックを行って更新して見ましたが、変化がなかったので、再インストールすることに。31.0.4のインストーラが公開されていたのでこれで試してみます。

設定ファイルは消さない状態で再インストールしましたが、出力タイマーの時間設定値が更新されることを確認。

そしてカスタマイズした実行ファイルを被せてみます。

まずは本体。obs64.exeとobs64.pdbをリネームし、入れ替え再実行。→時間設定値が更新される。

次にプラグインとなるfrontend-tools.dllとfrontend-tools.pdbをリネームし、入れ替えて再実行。→時間設定値が更新されない。

さらに実行ログにはNumber of memory leaks: 1という明らかに良くなさそうなものがきろくされていました。 

プラグインかぁ…とobs-studioのメニューのツール内を見てみると、なにやら英語と日本語表記がダブって表示されていることに気づき…frontend-tools.dllとfrontend-tools.pdbをリネームしてプラグインフォルダに残っていることが原因ではなかろうかと…。

不要なリネームしたファイルを一旦関係のない別のフォルダに移動してobs-studioを起動して試してみると、メニューはスッキリ日本語のみとなり、時間設定値も保存されるようになりました。実行ログもNumber of memory leaks: 0となったのでめでたしめでたし。

プラグインフォルダには余計なファイルを入れていおいてはダメみたいですねw  

 

2025年7月4日金曜日

プレビューの枠?

31.0.4で消えたと思っていたプレビュー画面のグレーの枠

別PCのOBSを31.0.4にアップデートしたところ…

消えてねくね?

消えたと思ってたけど消えてなかったのか??

後日ウィンドウのサイズを変えて確認しよう。 

2025年7月1日火曜日

あれ?

31.0.3をインストーラーからインストールして、更新して、カスタマイズした31.0.4のexeとカスタマイズしたプラグインの実行ファイルを放り込んだはずの環境のobsのウィンドウには31.0.3と出ている……。

インストールされているフォルダ内を確認してみると、差し替える元となるファイルのバージョンは31.0.3になっている。ということは、31.0.3の環境に31.0.4のカスタマイズされた実行ファイルと、プラグインを入れ替えたという状態になっているのだろうなぁ…単純にobs-studio内からアップデートかけてないということか…orz

そんなわけで、試しにobs-studio内から更新を行ってみると「最新の状態」となってしまい、何も変わらず。なのでファイルの整合性チェックを行い、更新してみると、ようやく31.0.4の状態になったっぽいです。  

まぁカスタマイズで差し替えたものは綺麗さっぱり正規の状態に書き戻されたわけですが、ここで改めてカスタマイズし昨日作成した実行ファイルを差し替えて…。ようやく期待している状態になりましたw 

 

そもそも31.0.xはそんなに違いは無いはずなのと、各モジュールとのインタフェースは変わってない感じなので当然と言えば当然ですが、もしかしてそれぞれの環境を個別にgit cloneする必要はなかったという事実w

ちょうどいいタイミングでSDカードが飛んでしまったのでNTFSフォーマットにして作業場所ができたのでいいんですけど。 

2025年6月27日金曜日

出力タイマーのレイアウトの調整など

QGridLayoutの詳細が分からなかったのであまり弄らないつもりでしたが、.uiファイルを見ているとやりたいことは一通りできそうなので少し調べてみました。

そもそも論として.uiファイルはxmlで記述されていて、そこの仕様が惜しいところで把握できなく…

Qt Widgets Designer's UI File Format(https://doc.qt.io/qt-6/designer-ui-file-format.html)

さらに見ていくとデザイナーなるアプリが存在していることも知ることができました。
最初は自動生成された.hを直接修正するとかイミフなことをやってたぐらいですw

デザイナーを使うためにQtのインストールをしようかと調べてみると、ユーザー登録とかなんか面倒そうなので途方に暮れてたところ、gitでダウンロードした中に .deps\obs-deps-qt6-2024-09-12-x64 / bin がありその中に一式ありそうでした。

試しに起動してみると見事にデザイナーが開き、.uiファイルを開いても正しく読み込めました。

一番知りたかったのがストレッチとスペーサーの違い。xml記述だとスペーサーに統合されているようで、ストレッチが記述できそうにないところまでは分かったのですが、実際にどんなパラメータを並べればストレッチのようになるのか知りたかったので、デザイナー上でスペーサーを追加し、保存したファイルの中を見てみることに。

その結果、 

      <spacer>
       <property name="orientation">
        <enum>Qt::Vertical</enum>
       </property>
      </spacer>
とすれば、今回必要だった縦方向に伸び縮みするエリアができてくれました。ストレッチのヒントとかデザイナーではデフォルトで追記するようになっていましたが、今回は省いても問題なしと判断。

そんな感じで出力タイマーの.uiファイルを弄っていて、気になったのが出力タイマー画面のデザイン。使い始めたときから気になっていた画面ではありますが、明らかにグリッドに配置されているセルの扱いがヤッツケ感が高いというかw

なのでcolspanを設定して変な余白が出ないようにするとこんな感じに。 

ウィンドウ自体もここまで縮まるようになりました。 

キャンセルボタンの有効化/無効化はボタンの表示の切り替わるタイミングで行うようにして画面レイアウトもひとまず終了。

2025年6月25日水曜日

個人的に欲しかった機能 録画タイマーのキャンセル

例えばタイマー設定をして記録し始めたときに、やっぱり延長したいなぁと思っても、OBSの録画タイマーのキャンセルって停止してから再開する他無いんだよなぁなんて思ったことはないですか?

私だけですか…?

そんな優柔不断な決断力と実行力のない人向けのボタン!

使える状態にするだけならさほど手間取らないとは思っていましたが、無効化などさせなければほんとに単純に実装できました。

関係ないときや機能しない状態のときの無効化を意識しなければこのままでもいいかもしれない…

OBSの出力タイマーは個人的には独特の使用方法と感じましたが、慣れると結構便利で、例えば30分間の動画をメインに作成しているときなど、何も考えずに開始すればグダグダになった動画でも強制停止されるために仮に途中で寝落ちしても巨大な動画ファイルが作成されずに済むとか…普通は無いですかw

結構重宝してるのですが、問題となるのは録画中に停止タイマーを切りたいときに一旦停止させる必要があるというのが、結構ヒッカカッテ使ってました。

ソースを追い始めて手間暇かかってる感じがして結構大変そうかな?とか挫折しそうになりましたが、結局のところこのタイマーは、開始時に終了までのインターバル時間を設定して開始させてるだけで、終了時間が経過するとイベント処理が行われる。という非常にシンプルな物でした。

録画の一時停止との連動はややトリッキー的に終了までの残り時間を保存してタイマーを停止。再開時には保存した残り時間をタイマーのインターバルに設定して開始しているだけ。

非常にシンプル。

メインとなるobsの動作はボタンが押されたときに録画を開始させたり、すでに録画状態であればタイマーだけ開始させたり、録画中でタイマーが動作している場合は録画停止を行ったりと1つのボタンで機能分けされている感じになっていました。

正直なところ、出力タイマーウィンドウを閉じたらキャンセルしてくれないかなぁとか最初は思ったりしたんですけど、UI的にそれはどうかとは思うw 

 

タイマーだけ単独の一時停止とかもあってもよさそうな気もしますが、どうなんでしょうね?  

2025年6月10日火曜日

とりあえず動く形に

何も考えずひたすらビルドすることだけに進んでみたが、結局は素直にgit cloneするのが良いようです。

 

何も考えず、デベロッパー用のドキュメントの手順で進めると、github上のリポジトリからクローンした場合は、バージョンチェックで引っかかるので、

set(OBS_VERSION_OVERRIDE "31.1.0-beta2 master")

どこかでOBS_VERSION_OVERRIDEを設定してあげるか、cmake-guiだと変数のところでaddしてあげれば切り抜けられるとは思う。

色々と試行錯誤した結果として、github上だとデフォルトのブランチからしかフォークさせられないようで…ほしいものは、「実際に動かしている状態で実行ファイルだけ挿げ替えたい」なので、これではだめだということに。

ソースファイルのダウンロードの方法は、 obsproject/obs-studio でブランチなりタグなりを一覧表示させればそのものがダウンロードはできた。

 

そして、いざcmake!

一番最初にやったことですが、zipなりでソース展開するとどうもgit cloneで取得できるもののようで、内包される別リポジトリのソースは含まれていないようで…当たり前っちゃ当たり前だけど、結構不便。というか、知らないで後日何かしようとしても手遅れになりそう。

実際にcmakeを実行させると最後の方で、

-- Configuring done (0.4s)
CMake Error at plugins/win-dshow/virtualcam-module/CMakeLists.txt:93 (target_link_libraries):
  Cannot find source file:

    C:/obs/obs-studio-31.0.2/deps/libdshowcapture/src/dshowcapture.hpp


-- Generating done (0.7s)
CMake Generate step failed.  Build files cannot be regenerated correctly.
CMake Error at cmake/windows/architecture.cmake:17 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 1"

Call Stack (most recent call first):
  CMakeLists.txt:8 (include)


-- Configuring incomplete, errors occurred! 

などと怒られるので、個別にソースを何とかしてあげたりするとcmakeは通ってくれるようにはなるものの、当たり前ですが、バージョンが一致してなければコンパイルすら通らなくなるという…

 

試行錯誤の末、結局git cloneで直接ローカルに持ってくるしかない。という結論に。

> git clone --recursive https://github.com/obsproject/obs-studio.git -b 31.0.2 --depth 1

欲しいのはこのタグ付けされたバージョンが欲しいので、これなら一気に持ってきてくれるハズ。

とはいえ、コミットされていないものがあるので、ワーニングが出たりしましたが、一通りダウンロードされたので、cmake!

なんだかんだと勘違いなどもあるので、cmake-guiを使った方がvisualstudioの起動まで行ってもらえるので便利かな?

ソースの場所や、プリセットを設定し、Configure Generate OpenProjectボタンを順番に押しました。 

visualstudio上でソリューションのオープンもできたようなので、試しに▷ボタンで実行してみるとコンパイルが始まりました。しばらくすると、2つのビルドで(キャスト関連の)警告文が発生し警告がエラーとして扱われるためにビルドエラーが発生してしまいました。内容的には問題なさげなので、個別のプロジェクトのコンパイルオプションを変更して警告は無視させました。

そして待望の31.0.2のOBSの画面がでました。  

で、ソースを手直しして…と思ったら、31.0と31.1はソースの配置換えを行っているようで、ファイル名まで違っていた様子。

目的の \obs-studio\UI\window-basic-stats.cpp ファイルも見つかったので、中身はほぼ一緒なので修正もすぐ終わり、構成をリリースに切替て実行させてみました。

いい感じになったので、実際に動かしている環境に実行ファイルを入れて動作確認。

昨日試しにインチキビルドした実行ファイルを挿げ替えて実行させたところライブラリなどのエントリポイントの不一致でエラーが発生させてしまったのですが、その時からコントロール内のボタンが一つ表示されなくなりました。正直消したかったのでいいのですが、ビルドした実行ファイルが原因で、レジストリのエントリーが消されたのかな?とは思います。

一通り動作はした感じですが、気になるのが実行ファイルのファイルサイズが結構違うところ。

もともとインストールされていたobs64.exeが4.89MBだったのに比べ、出来上がったものは4.69MBと、0.2MBほどの誤差が…付随する.pdbファイルも微妙にサイズが違ったりしているので、バンドルされているプラグインがdisable状態に変更になっているだけかもしれません。

足掛け3,4日でなんとかやりたいところまでようやくたどり着きました…。

 

蛇足

いまさらながら、統計ウィンドウはドック状態のウィンドウでもウィンドウのタイトルバーに「×」ボタンがついているという事実…ソース内では closable で単独ウィンドウなのかドック可能状態か区別しているのですが、どっちもクローズできるじゃん…とかw 

統計のレイアウト

かなりやっつけで変更したものの、いざリリースされているバージョンでコンパイルしようとしたら見事にハマり、なおかつ、github上で変更して置いたら微妙に漏れてたりとかしたので、ほとぼりが冷めてから手直しした形がこちら。

ダイアログ形式のときの閉じるボタンはそのままに、リセットボタンだけ移動という考え方に。

github上の操作で特定のブランチからフォークさせるやり方が分からないので思っているようなことがうまくできなくて歯がゆい…w 

2025年6月8日日曜日

OBS 統計ウィンドウの整形

非力なPCでOBSを使っていてもそれなりに動いてくれるのですが、画面的制約から無駄な領域が何とかならないかと思っていました。

最初はリソースっぽい何かがありそうかな?と期待していたのですが、GitHubを見る限りそんなものはなさそうで…クロスコンパイル前提のソースでディレクトリ階層がまったく把握できず。途方に暮れてましたが、どうせならコンパイル環境を作るところから始めてみました。が、最初は全くうまくいきませんでした。

必要なツールは個別にインストールし、説明されている通りにgit cloneからcmakeを実行したところでどうにもダメ。原因が不明なところどうやらFAT32ではなくNTFS上でソースを扱う必要があるという点と、PowerShellのバージョンが古いとエラーではまるらしいということで再度挑戦してみるとようやくVisualStudioで実際にビルドすることもできました。 

実際にx64環境でVisualStudioで開いてみると、ソースをブラウズするのもかなり便利に。

そして肝心のリソースのようなものは存在していないというのが確定したこと。ダイアログとドックはほぼ共通化されていて、ウィンドウクラスは同じものという作りだということがわかりました。

OBSはQtが使用されていて、ソースを眺めていればそれなりに解りやすかった?

ターゲットとなるソースファイルは.\obs-studio\frontend\widgets\OBSBasicStats.cpp 

メモを起こして、どんな感じの入れ子になっているのか確認しつつ実際に直接変更してみました。 

その結果、

結構コンパクトに。

いまいち位置の固定方法がわかってないのでドック可能なパターンだとリセットボタンが割り当てられている領域の中心位置になってはいます。多分ストレッチを追加すると上か下に張り付かせられそうだけど、まぁ見た目的には満足なので…

ただ、これ、最新のmasterからのクローンなので、実際に使っているバージョンではなくてbeta版…GitHub上でフォークすればよかったかなw

これで統計を下にドックさせた状態でも少しだけだけどプレビュー画面が広がる…

とりあえず、GitHubにソースを反映させてみた。まだcloneしてコンパイル通していないけど… https://github.com/siriuth/obs-studio/tree/master

2024年3月30日土曜日

\AppData\Local\Temp dd_BackgroundDownload_*.log

ユーザーフォルダが肥大化していたのでとりあえずTEMPフォルダ内のクリーンアップを始めたところ大量に存在する特定の名前で始まるファイル名が目にとまりました。

dd_BackgroundDownload_XXXXXXXXXXXXXX.log
dd_BackgroundDownload_XXXXXXXXXXXXXX_00_setup_errors.log
dd_BackgroundDownload_XXXXXXXXXXXXXX_00_setup.log
dd_BackgroundDownload_XXXXXXXXXXXXXX_result_Success.log

ファイルサイズは1,000KB~1,500KB程度でほぼ半分は空のファイルとなっていました。

ログなので中を見ると

Command line: "C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe" https://download.visualstudio.microsoft.com/download/

と言った文字列が目につきました。

Visual Studio関連らしいのでVersionを確認してみます。

Microsoft Visual Studio Community 2022 (64 ビット) - Current
Version 17.9.4
 

手始めに「dd_BackgroundDownload」で検索をかけてそれらしいページを開いてみました。

https://developercommunity.visualstudio.com/t/automatic-updates-is-disabled-but-the-background-d/815856

Version 16.3.3から発生しているらしく、日付も2020/08となっているのでそれなりに古いのですが、怪しい無駄アップデートは今も発生している模様。

ログの中身を見るとダウンロードもガンガン行い、勝手にエラーで失敗し続けている感じが強く、無駄な通信も行われ続け、ストレージもそれなりに浪費させ続けるというこの上なく迷惑な気配が濃厚です。

さらに、このディスカッションを見る限り、この自動アップデートは一日に6回程度行われるよう。

停止の仕方はVisualStudioInstallerの自動更新を停止し、さらに直接タスクスケジューラーを停止する以外に方法はなさそうで…

 

とりあえず管理者権限でVisual Studioを起動し、メニューから

 「ツール」→「オプション」

「環境」→「拡張機能」

「更新を自動的に確認する」と「拡張機能を自動的に更新する」を無効

ほとんどの自動処理を停止


念のためにタスクスケジューラを起動しタスクを確認してみると…

見事にそのまま有効のままだったので無効化

そしてトリガー条件を見て唖然とする。「アイドル時」ってことは何度も実行されるという事では?

 

これで様子を見てみることにしましょうか… 


以下ディスカッションをGoogle翻訳したもの

自動更新は無効になっていますが、バックグラウンド ダウンローダーは引き続き 1 日 2 回実行されます
閉店 - 情報が不十分112
0票
の上
オリバー・ニーバー
- 2019年11月12日午前10時報告

このバグは本当に厄介です。 私は無効になっています

[ツール] -> [オプション] -> [環境] -> [製品アップデート] -> [アップデートを自動的にダウンロード]

ずっと続いていますが、自動ダウンロードはまだ行われています。 私のTMPディレクトリには「dd_BackgroundDownload.*」がたくさんあります。

自動更新を無効にしているので、何もダウンロードされないはずです。 また、Windows スケジューラには何もありません。

はい、これらの自動ダウンロードはまったく必要ありません。 なぜこれを強制するのですか? それとも、これはあなたがよく考えていない別のことでしょうか?

現在バージョン 16.3.8 を使用していますが、まだ壊れています。 最後にこのナンセンスを修正してください! ありがとう!
Visual Studiowindows 10.0visual Studio 2019 バージョン 16.3

フィードバック ボットの優先順位付け

さらなる評価のために、お客様のフィードバックを適切なエンジニアリング チームに送信しました。 チームはフィードバックを確認し、次のステップについて通知します。
0
2019年11月12日午後5時17分

Xiu Li [MSFT] 詳細情報が必要です

ご意見ありがとうございます! インスタンスがバックグラウンドで更新を自動的にダウンロードしないように、マシン全体のポリシー (レジストリ キー) を設定してみてください。 こうするほうがよいかもしれません。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\Setup]
「BackgroundDownloadDisabled」=dword:00000001
このレジストリ キーと値を設定すると、インストーラーは、インストールされている Visual Studio 製品の更新プログラムを自動的にダウンロードしなくなります。
これがうまくいくかどうかお知らせください。
-1
2019年11月12日 午後6時13分

オリバー・ニーバー

返信いただきありがとうございます。 エントリーを追加しました。 この号は今後、約 36 時間以内に更新します。

このエントリを追加して PC を再起動した後、最初に目にしたのは、ファイルがまだあるということです。
「dd_updateconfiguration_20191112173609.log」には次の 1 行のみが含まれます。
「[29b4:0001][2019-11-12T17:36:10] 前回の実行以降更新がありません。 現在の操作をスキップします。」

また、新しく作成された「tw-*.tmp」ディレクトリがまだたくさんあります。 はい、PC を再起動する直前に TMP ディレクトリを手動で空にしました。

もっと後で。
0
2019年11月13日 1:47 AM

シウ・リー [MSFT]

%temp% フォルダーに「dd_BackgroundDownload.* ログ」がまだ表示されるかどうか教えてください。 タスクマネージャーにBackgroundDownload.exeプロセスが表示されましたか?

「dd_updateconfiguration_20191112173609.log」、このログは拡張機能の自動更新に関するものである必要があります。

「ツール」→「オプション」→「環境」→「拡張機能」に移動し、「更新を自動的に確認する」と「拡張機能を自動的に更新する」を無効にすることができます。

「tw-*.tmp」は Windows の一時ログ用です。
0
2019年11月13日 18時44分

フィードバックボット

さらに調査するのに十分な情報がないため、このレポートは 7 日以内に終了します。 問題を解決しないために、要求された詳細を提供してください。
0
2019年11月20日午後12時04分

オリバー・ニーバー

数日後、TMP ディレクトリを手動で大量に削除し、一部を再起動すると、結果は次のようになります。
1.) レジストリ エントリはバックグラウンド ダウンローダーを部分的にのみ停止します。
A.) 0 KB サイズの dd_BackgroundDownload_*.log ファイルがまだ 12 個あります。つまり、それらは完全に空です。
これは、30 ~ 60 分ごとに 1 日中毎日発生します。

自動アップデータ拡張機能:
2.) ユーザーおよびシステム全体の更新チェックを無効にした後: dd_updateconfiguration_*.log がまだ作成されており、次の行が含まれています。
「[250c:0001][2019-11-21T12:43:35] 前回の実行以降更新はありません。 現在の操作をスキップします。」

これは 1 日に 1 回発生します。

どこかでスケジュールされた実行を逃したのでしょうか? ありがとう!
0
2019年11月22日午前5時50分

シウ・リー [MSFT]

返事が遅れて申し訳ありません。 これらのログは、バックグラウンド ダウンロードの事前チェックのために生成され、事前チェック検証を実行して、バックグラウンド ダウンロード機能が有効か無効かを確認します。機能がポリシーによって無効になっている場合、バックグラウンド ダウンローダーはキャンセルされます。
0
2019年11月28日 15:46

Microsoft の解決策 - フィードバック ボット
終了しました - 情報が不十分です

追加情報が要求されない限り、この問題をさらに調査することはできません。
2019年12月12日 11:28 AM

ディーン・ジャクソン

@Xiu Li [MSFT] @Oliver Niebuhr

私も同じバグに気づきました。 16.3.3 をインストールしましたが、16.3.3 をインストールした後、Visual Studio オプション内のすべての更新をすぐに無効にしました。 数か月後、毎日数回定数一時フォルダーが作成され、それらのフォルダー内に VS セットアップ ブートストラップ プログラムが存在することがわかりました。 この問題は、タスク スケジューラの VisualStudio フォルダー内の「backgrounddownload」と呼ばれるスケジュールされたタスクが原因で発生します。 このタスクを無効にしました。明日一時フォルダーをチェックして、タスクが停止したかどうかを確認します。

/users/58388/e82cb80e-da10-4a7d-9ce2-1727d16d53f0.html
0
2020年1月10日 6:20 AM

マリオ・ボラレビッチ

私は16.6.2を持っていますが、製品のアップデートがチェックされていないにもかかわらず、TEMPフォルダーに大量のゴミがまだありました。 それは 9 GB を超えていましたが、まだファイルを検出していて増加しており、すべてが Visual Studio のインストールに関連していたため、プロパティを閉じました。

また、削除にどれくらいの時間がかかったかを想像することもできます。

他の人が言ったように、タスクスケジューラタスクを無効にすることで解決しましたが、ディスクスペースがどんどん小さくなる一方で、隠された設定を探す必要があるのは本当に良くありません。
0
2020年8月29日 午前1時30分

2011年11月23日水曜日

HDDアクセスが気になる

今までも何とかならないかと気になってるのですが、


HDDプロパティの「このディスクにインデックスを付け、ファイル検索を早くする(I)」を外す。

起動時のHDDアクセスが長くなる現象対策としては

Windows Updateのサービスを止めてから、c:\windows\SoftwareDistribution\DataStoreの中身を削除し、Windows Updateサービスを再開する。 
http://zenryokuhp.com/blog/archives/2010/11/windows_xpwindo.php
http://support.microsoft.com/kb/875560/ja

100Mを越えていました。そもそもAutomatic Updateはいらない気がするので手動に変更。

プロセスモニタでディスクアクセスしているプログラムなどが判断できるのでこれで個別に確認。
http://technet.microsoft.com/ja-jp/sysinternals/bb896645

sonyの付属のものが頻繁にディスクアクセスを行っているので、全く利用していないのでサービスを停止VAIO Entertainment Databese Service, File Import Service,

realplayer 自動アップデートを外してもなにやら動いているようです。→アンインストール

FlashPlayer コントロールパネルで自動アップデート停止

2011年11月16日水曜日

jqs.exe

最近ではとても重く感じるノート。
気になったのでちょっとタスクマネージャーを起動してみているとJqs.exeというプロセスが突如あらわれています。
早速けんさくしてみると見ると、
jqs.exe が起動していると XP がプチフリする件
というのが見つかりました。

JavaのJava Quick Starterみたいですね。
停止はコントロールパネルから設定できるようです。
詳細タグページのJava Quick Starterのチェックを外す必要があるようです。