PX-M1URのCATV対応について

[stu2005]

バグ報告ではなく質問です。お忙しい中での失礼をお許しください。
タイトルにある通りPX-M1URを使用しています。私の環境において地デジはCATVによる周波数変換パススルーで来ている為、recisdbではチャンネル番号C13~C64を指定する必要があります。
このドライバを使い、PX-M1URでパススルーを受信するのは想定された動作ですか?

px4_drv/driver/ptx_chrdev.c

Line 251 in 796bff8

chrdev->params.freq = 93143 + freq.freq_no * 6000 + freq.slot/* addfreq */;

この選局は、新たにサポートが追加されたPX-M1URでも行われるのでしょうか?

https://github.com/kazuki0824/recisdb-rs/blob/dea64f773e2dc079b112334882fcf4840f5f6eea/recisdb-rs/src/channels.rs#L59
を見る限り、DVB版ドライバではrecisdb側で選局していますが、Chardev版ドライバではドライバ側で選局しているように見えた為、こちらで質問させて頂きました。
tsukumijimaさんがCATV関連のテストをできる環境にないことは承知しています。

[tsukumijima]

PX-M1URでパススルーを受信するのは想定された動作ですか?

PX-M1UR のドライバは、数年前に失踪された nns779 氏が書かれた DTV02A-1T1S-U 向けのコードがベースです。そのため、 DTV02A-1T1S-U のドライバが CATV 周波数変換パススルーを考慮しているのであればおそらく対応している、という回答になります。

仰る通り私は周波数変換パススルー環境にないですし、日本全体で見ても周波数変換パススルーが運用されている地域はかなり限られている印象です。したがって動作報告もなく、「動くかわからないがとりあえず書いてある」程度のものでしかありません。動くような気もしますし、動かないかもしれません。
またデバイスによっては周波数変換パススルーに対応していない可能性も考えられますが、これも公式な情報は限られているため、よくわからないのが正直なところです。確か MyGica VT20 / PX-S1UD は一部の周波数変換パススルーの物理チャンネルに対応していなかったことだけは記憶しています。

[stu2005]

現状、
C13~C63の内一部のチャンネルにおいてBSの特定のチャンネルが録画されてしまいます。(例えばC14を録画すると、本来Eテレが録画される筈がBSイレブンになっている)
recisdbとrecpt1で動作は変わりません。
BSのチャンネル番号で録画する場合は問題ありません。
正規の手段(公式ドライバ+PLEXTV)で映ることを確認してます。

[tsukumijima]

ちなみにですが、DTV02A-1T1S-U とさんぱくん外出は外装こそ一見似ていますが、中身のチップ構成は別物（したがってドライバ実装も別物）であることに注意が必要です。
したがって、さんぱくん外出で動いたからといって、DTV02A-1T1S-U で動くとは限らないと思われます。

[hendecarows]

周波数変換パススルー環境ではないのですが、PX-M1URとrecpt1で確認したら同様にC14でBS11が録画されました。

px4_drv/driver/m1ur_device.c

Lines 197 to 203 in 796bff8

	static int m1ur_chrdev_init(struct ptx_chrdev *chrdev)
	{
	dev_dbg(chrdev->parent->dev, "m1ur_chrdev_init\n");
	chrdev->params.system = PTX_UNSPECIFIED_SYSTEM;
	return 0;
	}

DTV02-1T1S-UやPX-M1URは上の様にPTX_UNSPECIFIED_SYSTEMが設定されているため以下を通ってしまう様です。

px4_drv/driver/ptx_chrdev.c

Lines 266 to 290 in 796bff8

	case PTX_UNSPECIFIED_SYSTEM:
	if (chrdev->system_cap & PTX_ISDB_S_SYSTEM) {
	if (freq.freq_no < 0) {
	ret = -EINVAL;
	break;
	} else if (freq.freq_no < 12) {
	/* BS */
	if (0 && freq.slot >= 8) {
	ret = -EINVAL;
	break;
	}
	chrdev->params.freq = 1049480 + (38360 * freq.freq_no);
	chrdev->params.bandwidth = 0;
	chrdev->params.stream_id = freq.slot;
	chrdev->params.system = PTX_ISDB_S_SYSTEM;
	break;
	} else if (freq.freq_no < 24) {
	/* CS */
	chrdev->params.freq = 1613000 + (40000 * (freq.freq_no - 12));
	chrdev->params.bandwidth = 0;
	chrdev->params.stream_id = freq.slot;
	chrdev->params.system = PTX_ISDB_S_SYSTEM;
	break;
	}
	}

また、その下を見るとそもそもC13-C24には対応していないと思えます。

px4_drv/driver/ptx_chrdev.c

Lines 292 to 308 in 796bff8

	if (chrdev->system_cap & PTX_ISDB_T_SYSTEM) {
	if (freq.freq_no >= 24 && freq.freq_no <= 62) {
	/* CATV C25-C63ch */
	chrdev->params.freq = 93143 + freq.freq_no * 6000 + freq.slot/* addfreq */;
	chrdev->params.bandwidth = 6;
	chrdev->params.stream_id = 0;
	chrdev->params.system = PTX_ISDB_T_SYSTEM;
	break;
	} else if (freq.freq_no >= 63 && freq.freq_no <= 112) {
	/* UHF 13-62ch */
	chrdev->params.freq = 95143 + freq.freq_no * 6000 + freq.slot/* addfreq */;
	chrdev->params.bandwidth = 6;
	chrdev->params.stream_id = 0;
	chrdev->params.system = PTX_ISDB_T_SYSTEM;
	break;
	}
	}

解決方法は、recpt1なりの録画コマンドを以下を参考に修正すればよいのではないかと思います。
https://github.com/nns779/BonDriver_LinuxPTX/blob/develop/src/BonDriver_LinuxPTX.cpp#L289-L292

BonDriver_LinuxPTXを使うというのでも良いですが、DTV02-1T1S-UやPX-M1URでは、CloseTunerをせずにSetChannelでISDB-TからISDB-Sのように放送波を跨ぐようなチャンネル変更をするとTSが出力されなくなるバグがあります。

何かの参考になれば。

[tsukumijima]

@hendecarows
丁寧にご説明ありがとうございます。となると大元のドライバ側の実装不備の線が濃厚ですね…。
ただ私自身 C 言語をちゃんと書けるわけではなく、変更をマージしたり組み合わせるだけで精一杯で、自ら修正するのは正直ちょっと怖いです。よろしければプルリクなどいただけますと大変助かります。

[hendecarows]

ドライバ側の実装不備というよりはrecpt1等の録画ツールがそのまま使えることを優先したのではないかと思います。

PT1,PT3のchardevドライバではチャンネル変更時にドライバに渡される引数にTとSを直接区別する情報がありません。チャンネルは周波数ではなくTもSもゼロから始まる周波数番号で渡されるためです。TとSのチューナーが独立しているため、ドライバ側はTかSか自明ですしそれで問題はなかったのだと思います。

一方、px4_drvではPX-M1URなどTとSが独立していないチューナーがあるので、TとSを判別する情報は必要です。例えば、チャンネル変更時の引数にTとSを区別する情報を追加すれば良いのですが、それだとrecpt1等の録画ツールがそのままでは動作しなくなってしまいます。それを避けるために、TとSが独立していないチューナーに対しては、C13-C24等を使えなくする代わりにBS,CSを使えるようにしているのだと思います。これは、BS,CSの周波数番号が0-23しかないので、24以上ならT側だと比較的簡単に判断できること、地デジ13chは番号63なので重複もしていないからでしょう。

C13-C24を使えるようにするにはどうすれば良いのかですが、px4_drvにはPT1,PT3ドライバにはないTとSを切り替えるioctlがあります。それが、下のリンクにあるioctl(fd_, PTX_SET_SYSTEM_MODE, system)です。

https://github.com/nns779/BonDriver_LinuxPTX/blob/develop/src/BonDriver_LinuxPTX.cpp#L289-L292

px4_drvを修正するのではなく、recpt1を修正してチャンネル変更前にこのioctlを実行すれば、下のリンク側を通ってC13-C24が使えるようになるのでは？というのが私の考えです。

px4_drv/driver/ptx_chrdev.c

Lines 247 to 264 in 796bff8

	case PTX_ISDB_T_SYSTEM:
	if ((freq.freq_no >= 3 && freq.freq_no <= 12) ||
	(freq.freq_no >= 22 && freq.freq_no <= 62)) {
	/* CATV C13-C22ch, C23-C63ch */
	chrdev->params.freq = 93143 + freq.freq_no * 6000 + freq.slot/* addfreq */;
	if (freq.freq_no == 12)
	chrdev->params.freq += 2000;
	} else if (freq.freq_no >= 63 && freq.freq_no <= 112) {
	/* UHF 13-62ch */
	chrdev->params.freq = 95143 + freq.freq_no * 6000 + freq.slot/* addfreq */;
	} else {
	ret = -EINVAL;
	break;
	}
	chrdev->params.bandwidth = 6;
	chrdev->params.stream_id = 0;
	break;

とりあえず、この考えで修正したrecpt1を以下に置きました。最初に書いたように周波数変換パススルー環境ではないので動作確認はできていません。ひとまず、C14を録画したらBS11が録画されるのではなく失敗するようにはなりました。

https://github.com/hendecarows/recpt1

@stu2005 さん動作確認していただけないでしょうか。

[stu2005]

@tsukumijima @hendecarows
ありがとうございます。多忙につき長時間のテストができていませんが、hendecarows/recpt1で私の環境で放送されている全ての地デジのチャンネルが映るのを確認しました。