PSIで提供される情報にはさまざまなIDが付与されているが、このIDがどれくらいユニークなのかを把握しておくことがシステム設計に重要である。 TR-B15第四編5.3にユニーク性についての記述がある。
network_id
BSだったら4、CS1だったら6、CS2だったら7といったように決められており、日本国内でユニークである。
transport_stream_id
ネットワーク内でユニークとなっているが、実際はネットワークをまたいで同じTSIDが付くことがないように運用されている気がする。地デジは0x7E00〜0x7FFF、BSは0x4000〜0x4FFF、CS1は0x6000〜0x60FF、CS2は0x7000〜0x71FFとなっているようだ。もっとも、これは今たまたまそうなだけで、仕様上は network_id が別だったら transport_stream_id が同じでも区別できなければならない。
実運用上この ID を使うことはあまりないのではないだろうか。たとえば TOKYO MX の transport_stream_id は 0x7E87 だが、 TOKYO MX は MX1 と MX2 で異なる番組を放送することがあり、それぞれの service_id である 0x5C38 と 0x5C39 を使わないと保存すべきストリームを一意に決められない。
service_id
これもネットワーク内でユニークだ。わかりやすさのためだろうかすでに重複がある。たとえば難視聴用日テレ1のservice_idは294だが、 CS2のホームドラマチャンネルのservice_idも294である。
event_id
番組(イベント)ごとにつけられる ID だが、2バイトしかないので当然厳密にユニークなわけではない。運用規定では、放送終了後24時間経つと再利用可能なようになっている。番組情報や録画を長期的に残す場合、event_idを使って管理しようとするとどうやって長期的なユニーク性を確保するかが課題になる。日付を使おうとすると、 24時をまたいで時間変更があったときにダブってしまう。
もし運用上IDを使い切るまで再利用をしないのだとすると、仮に24時間全てが30分番組だとして1日に放送される番組の数は48で、1300日間は同じIDが使われない。5分番組しかないとしても220日は使われない。西暦と組み合わせれば運用上問題なくユニーク性を担保できるのではないだろうか。当然12月31日24時をまたいで時刻変更が行われるとダブってしまうのだが……
特定の番組を一意に表すために
ということで、特定の放送局の特定のストリームで特定の時間に放送される (もしくは放送された) 特定の番組を一意に表すために、
- network_id
- service_id
- year
- event_id
の4つを組み合わせると良い。