-
Notifications
You must be signed in to change notification settings - Fork 31
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
ETT improvements #26
ETT improvements #26
Conversation
Both parse::dont_collect_ett and #ifdef ETT require source code changes to access, but if you do #define ETT, you still need to manually disable dont_collect_ett, which seems kind of silly. In lieu of a more formal control mechanism, assume for now that if you #define ETT, you probably want dont_collect_ett=false. Signed-off-by: Richard Tollerton <richard.tollerton@gmail.com>
If a decoded ETT is available for an event, print it to stderr along with the rest of the EIT information. Signed-off-by: Richard Tollerton <richard.tollerton@gmail.com>
We would like to display ETTs as part of the EPG output. But ETTs tend to be transmitted asynchronously with respect to EITs. Reliably presenting ETTs requires keeping track of which EITs have a declared etm_location but for which the associated ETT has not arrived yet. As a crude first implementation, we simply search for every event in every EIT with a declared etm_location, and try to look up its ETT. It is enabled automatically if ETT is defined and -E is supplied on the command line. Signed-off-by: Richard Tollerton <richard.tollerton@gmail.com>
Thanks for your work ! We should probably add a #define for ETM_MAX_LENGTH in Also, now that I think about it, we should use dynamic allocation for those 4K buffers rather than stack allocation. You can either do that work or I'll deal with it myself after merge - its not urgent. I seem to recall having a run-time method for turning on the ETT collection, but maybe it required an API call that I don't currently support in the cmd-line app. I have to check on that... EDIT: the API is
Thank you for your contributions :-) |
if (!d.got_all_eit(eit_collection_limit)) return false; | ||
#if ETT | ||
#if 1 | ||
if (!d.got_all_ett()) return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to need to be conditionalized. I can imagine cases where the user may want to know a quick list of all shows currently airing without the need for collecting all the events long descriptions.
EIT's are conditionalized by the eit_collection_limit
, which might be zero. For ETT I think we just need a boolean, and your function seems to have the right idea comparing received ETTs against expected ETTs.
@rtollert , By now I have merged the majority of your changes in this pull request, leaving only three changes visible as outstanding. The internal tracking of the ETT tables needed a complete overhaul. It is possible for multiple messages from the same source to also have the same ETM_ID, but the etm_id is unique within a given slot. They must be separated into 128 slots based on the ETT position, which correlates to the EIT position. In the end, your check for decode: fix tracking of ETT Extended Text Tables: 6ffb3c3 It does indeed take quite a lot of time to fetch a complete dataset when waiting for all ETT. It can take even more than the five minutes you have observed. Can you give the latest Anyway, to enable the extended text table collection, pass For instance, to scan for a full EPG in JSON output dump format on channel 33 using an hdhomerun:
|
So my eventual goal is to use ETTs for duplicate recording detection. Out of all the EPG tools I could find, it seems as if dvbtee is the closest to this goal. I was able to get a proof-of-concept working (in these patches) inside the ETT ifdef, by pulling ETTs into -E output via dump_epg_event, and (crudely) blocking completion of -E until all ETTs are accounted for.
This causes execution time under -E to balloon to 2-5 minutes on KLRU-HD because the ETTs for higher EITs are transmitted infrequently.