-
-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Q] How does EIT Actual Schedule work? #1447
Comments
What do you want to do exactly? If you want to generate EIT's for an EPG, this is not the right way. EIT's are special beasts which change all the time. The correct way to inject EIT's is the plugin Otherwise, I have no idea about your table 0xA0. It should not be there from your input file. But I don't want to enter an irrelevant discussion if your goal is simply to inject EIT's. If you have a specific issue about the |
Hi @lelegard Thanks for your response. I will have a play around with the plugin Regarding the current method of using the plugin The tsduck command:
The input eit.xml file:
The commands to extract the EIT:
The xml output of
|
You can remap the PID using Alternatively, I can (and will) add an option to specify another PID. Concerning the weird section with table id 0xA0, the problem is in your XML file: From the TSDuck user's guide:
For EIT schedule, the type attribute shall be a value between 0 and 15. It is added to the base table id for EIT schedule actual/other. The base table id for EIT schedule actual is 80. Plus 80 equals 160, or 0x80. It is a bug in TSDuck to accept a value above 15. Your XML file should have been rejected. I will fix this. That being said, you can see that it is extremely difficult to generate a consistent EPG using individual EIT's from XML files. In practice, it is even impossible. I repeat: impossible. The reason is simple. XML files can only contain full tables. The generation of a binary table over multiple sections is automatically done by TSDuck, based on available space in sections. EIT schedule, on the other hand, are not full tables. They are sparsed sections. This is why generating a consistent EPG is not possible from individual EIT structures in a XML file. This is why the plugin This is why I asked the question: what do you want to do exactly? If you want to do some specific isolated test, |
Option |
Automatically closed after 153 days without update and "close pending" label set. |
I'm currently trying to get my head around EIT tables and am attempting to inject an EIT into a new ts using the following;
The test input EIT is in the following format:
I then use the following to extract the tables from the captured ts:
I then get the following as output, which doesn't look quite correct:
The pf table looks OK except for the version number having changed for 5 to 0 (What's the reason for this? Does tsduck always renumber the EIT version with --eit-normalization?).
However instead of the schedule actual EIT table being table_id 0x50, it now appears as a generic_long_table with table_id 0xA0.
Is the "type" in the EIT XML input supposed to be type="80" or type="0x50" or something else for actual schedule?
Or is there something else I'm not doing correctly?
I should add I'm using an older build of tsduck for compatibility (version 3.35-3215).
The text was updated successfully, but these errors were encountered: