[5ym]

ケーブル (CATV) のスキャンで、113 チャンネルを総当たりするのをやめ、ケーブル局の NIT から回す搬送波を決めます。

• 自主放送の TS に流れている NIT[actual] のケーブルの分配の記述子 (0x44) を読めたら、総当たりの残りをその一覧に置き換える。再送信の TS が NIT に載っていなければ、一覧に無いチャンネルは総当たりで探す。NIT を読めなければ今の総当たりのまま
• 一覧の搬送波がロックしなければ、10 秒・30 秒・60 秒あけて試し直す。それでもロックしなければ、前の控えのチャンネルを残す
• NIT の中身とバイト列 (1 KB まで) をスキャンの記録に出す。0x44 の並びは推定なので、次に誰かがスキャンすれば実機の値が分かる
• 一覧は設定の表の cableLineup:<エージェント> に書き、次のスキャンの入口と搬送波の増減に使う
• @danything/arib 2.5.0: 0x44 とネットワーク名を読む
• エージェント: QF<kHz> で周波数を直に指す。DVB の機材は QAM_AUTO か 64QAM・256QAM を試す (J:COM の QC26 が 256QAM だった)

実機で確かめていないこと: J:COM の NIT の中身 (0x44 の並び・再送信の TS が載るか)、試し直しでロックが取れるか、DVB-C の機材の 256QAM。ロックが不安定なこと自体は別の件で扱います。

🤖 Generated with Claude Code

https://claude.ai/code/session_01T8TqVbtN2Hp8wNmqBX8pzT

[5ym]

main の取り込みでレビューが飛ばされたため、開き直してレビューを回します

[claude]

Claude finished @5ym's task in 53s —— View job

---

レビュー結果

NIT から搬送波を決める設計は、既存の衛星の一覧 (satellite.ts) の扱いと揃っていて、境界値の処理も丁寧です。cable.ts の変換・並べ替えにはテストもあります。確認した点は次のとおりです。

指摘 (インラインコメントも付けました)

• agent/Denpa.Agent/ChannelTable.cs: Number の <summary> が、追加した定数の <summary> の上に残っています。Number の説明が定数側に付き、同じ要素に <summary> が 2 つ並びます。
• src/lib/server/scan.ts (要確認): NIT が流れていない TS では、受信できたチャンネルごとに最大 30 秒 (TUNE_TIMEOUT) 待ちます。NIT を読めなければ従来どおりの総当たり、という前提より時間がかかります。

要確認 (インラインにはしていません)

• Tuning.cs の LockCable: QAM_AUTO に対応しない DVB-C の機材では、ロックしないチャンネルが 64QAM と 256QAM の 2 回、QC24〜QC27 はずらした周波数で 4 回の WaitForLock を待ちます。NIT を読むまでの総当たりが長くなります。

問題なし

• DeviceProbe.CapsAt = 164 は dvb_frontend_info の並び (name 128 + type 4 + 周波数 16 + シンボルレート 12 + notifier_delay 4) と合っています。CanQamAuto = 0x10000 も FE_CAN_QAM_AUTO と一致します。
• adoptCable の列の差し替え (seen・planned の増減) と、work を回し直す do…while は、take が型で絞るため無限ループになりません。
• parseStored は形が違えば null を返し、設定の読み書き失敗は握りつぶして入口なしで回します。
• docs・コメント・画面の文言に、docs/writing.md の「使わない言葉」に当たるものは見つかりませんでした。

実機で確かめていない点 (J:COM の 0x44 の並び・試し直しでのロック・256QAM) は PR 本文のとおりで、記録に NIT のバイト列を出す作りなので、次のスキャンで確かめられます。

[claude]

Number の <summary> (236 行) が、追加した定数 DirectMinKhz・DirectMaxKhz の <summary> の上に残っています。Number のドキュメントコメントが定数側に付き、Number 自身は説明が無くなります。コンパイラの XML ドキュメント警告 (同じ要素に <summary> が 2 つ) も出ます。定数 2 つを Number の上ではなく、Tuning の解析の近くか Number の前の空行より上に移し、236 行目は Number の直前に戻してください。

Suggested change

	/// <summary><paramref name="digits"/> 桁までの数字だけの文字列を読む</summary>
	/// <summary>
	/// <c>QF&lt;kHz&gt;</c> で選局できる周波数の範囲 (kHz)。VHF 1ch の下端 (90 MHz) から UHF 62ch の上端 (770 MHz) まで。
	/// ケーブルの選局表の並び (<c>QV1</c>〜<c>QU62</c>) が収まる範囲と同じ
	/// </summary>
	private const int DirectMinKhz = 90_000;
	private const int DirectMaxKhz = 770_000;
	/// <summary>
	/// <c>QF&lt;kHz&gt;</c> で選局できる周波数の範囲 (kHz)。VHF 1ch の下端 (90 MHz) から UHF 62ch の上端 (770 MHz) まで。
	/// ケーブルの選局表の並び (<c>QV1</c>〜<c>QU62</c>) が収まる範囲と同じ
	/// </summary>
	private const int DirectMinKhz = 90_000;
	private const int DirectMaxKhz = 770_000;
	/// <summary><paramref name="digits"/> 桁までの数字だけの文字列を読む</summary>

[5ym]

3ca77b0 で直しました。定数 2 つを Number の

より上に移しました。

[claude]

要確認: nit.wait が true の間 (ケーブル局の NIT をまだ読めていない間) は、局が揃っても NIT[actual] が来るまで TUNE_TIMEOUT (30 秒) いっぱい読み続けます。NIT が流れていない TS (再送信で NIT を載せない局、QC の自主放送でない搬送波) では、受信できたチャンネルごとに最大 30 秒かかります。PR 本文の「NIT を読めなければ今の総当たりのまま」に対して、所要時間は総当たりのままではなくなります。J:COM で 113 本中 18〜25 本がロックする前提だと、最悪で数分の増加です。OBSERVE_WAIT のような待ちの上限 (例: 局が揃ってから 10〜15 秒) を NIT にも設けるか、NIT が 1 度も取れなかった搬送波の数で待つのをやめるかを検討してください。

[5ym]

3ca77b0 で、NIT を待つのを読み始めから 15 秒までにしました (NIT_WAIT。NIT は 10 秒に 1 回は流れるので、選局が落ち着くまでの数秒を足した値)。NIT が流れていない TS で 30 秒待つことは無くなります。

[claude]

Claude finished @5ym's task in 14s —— View job

---

レビュー結果 (最新コミット 3ca77b0 を確認)

前回の指摘 2 件は直っています。

• ChannelTable.cs: DirectMinKhz・DirectMaxKhz が Number の <summary> の下に移り、<summary> の重複は無くなりました。
• scan.ts: NIT[actual] を待つのを、読み始めから NIT_WAIT (15 秒) までにしました。NIT が流れていない TS でも、1 チャンネルあたり 30 秒は待たなくなりました。docs/data.md と引数のコメントも合わせて直してあります。

残っている要確認 (インラインにはしていません)

• Tuning.cs の LockCable: QAM_AUTO に対応しない DVB-C の機材では、ロックしないチャンネルごとに WaitForLock を 64QAM と 256QAM で 2 回待ちます。QC24〜QC27 はずらした周波数でも試すので 4 回です。NIT を読むまでの総当たりが長くなる可能性があります。実機の所要時間を次のスキャンで確かめてください。

問題なし

• 新しいコミットの変更に、不具合・セキュリティ上の問題・docs/writing.md に反する文言は見つかりませんでした。

実機で確かめていない点 (J:COM の 0x44 の並び・試し直しでのロック・256QAM) は PR 本文のとおりです。