DVR: Prefer autorec rule name if comment field is empty (#4500)
Currently the Upcoming recordings tab has a comment field that says
"Auto recording" or "Auto recording: <comment from autorec rule>".
This helps to identify why a recording is scheduled.
This patch ensures we continue to use the autorec comment field if
it is non-empty (keeping existing behaviour), but fallback to using
the recording rule name. If both are empty then we keep the
existing behaviour of fallback to an empty string.
This avoids the user having to duplicate the rule name in to
the comment string for manually created autorec rules.
So, in the above case it would be "Auto recording: <comment>",
"Auto recording: <rule name>", otherwise "Auto recording".
eit: Allow scraper configuration file to be configured at the GUI (#4287).
Previously the scraper was hard-coded based on the module name.
So "uk_freeview" module would check "uk_freeview" configuration file
and then the "uk" file.
However, this meant that the generic "eit" module (used by several
countries) had to be symlinked by the user to a specific configuration
for their country.
With this change, the user can simply enter "uk" in the GUI to read
that configuration.j
Also renamed "fixup" to be called "scrape" since we are scraping
data from the EIT rather than fixing it.
eit: Allow EIT scraping of season/episode to be disabled at GUI. (#4287).
We now have a tick box in the OTA configuration to enable/disable
the scraping of season/episode numbers from the eit grabbers.
This will allow us to add other scrapers and tidy-ups in the
future (such as removing "Also in HD" from the summary data
or "New:" from the title), and allow the user to disable ones
they do not want for very low-spec machines or due to their
duplicate rules relying on pre-tidy data.
To achieve this configuration, we now derive our eit grabbers
to be a "...scraper" type and hook in to the activate callback
to load/unload the regular expressions.
The loading of the config also had to be moved to the activate
rather than in the module create to allow us to access the
"scrape enabled" boolean.
eit: Extract season/episode numbers from OTA EIT. (#4287).
Broadcasters often include season and episode number in
the summary text in the OTA EIT.
For example, UK broadcasters often, but not always,
have a description of "Lorem ipsum (S5 Ep 8)" or
"Lorem ipsum (S3 Ep 4/9)" or "Lorem ipsum (Ep 4)".
From this we can use a regular expression match to
extract the season and episode data on a best effort
basis. This logic is based on the opentv extractor.
This is done via config files that are named after the
grabber module and exist in this directory:
data/conf/epggrab/eit/fixup/
Example names would be uk_freeview.
If the module-specific config file does not exist then we
fallback to trying the first component of the filename.
In the above example that would be "uk". This avoids having
duplicate files in the case where we have DVB-S and DVB-T
in the same country that share the same extraction regex.
The configuration file should contain season_num and
episode_num sections that can contain multiple regular
expressions to apply in sequence until one produces
a match.
For DVB-S, the configuration file normally needs to be copied to
a file named "eit" since data is broadcast via that mechanism.
This isn't done by default since the eit grabber is used by
multiple countries that may use different regular expressions.
eit: Move opentv pattern list functions to separate file. (#4287).
The pattern list functions are used for regular expression matching.
We move them to a separate file and rename them to have an
eit prefix instead of opentv prefix so they can be shared with
other eit modules.
E.Smith [Sat, 19 Aug 2017 09:26:44 +0000 (10:26 +0100)]
DVR: Record segmented programmes identified by EIT.
A broadcaster can split a programme in to multiple segments. These
are identified by the segments having a CRID containing an IMI
(a hash character followed by an ID). Segments have identical
values for this CRID and IMI and the segments start within three
hours of the end of the previous segment.
These rules are documented in this spec in section 7.1.7:
http://www.freeviewnz.tv/media/1055/freeview_dtt_transmission_rules_2_1.pdf
This document is based on the UK transmission specification.
For example, a movie may be broadcast as:
21:00--22:00 movie segment 1
22:00--22:05 five minute news
22:05--23:30 movie segment 2
The xmltv guides typically merges this segments in to one
programme such as:
21:00--23:30 movie (including news)
In theory, a programme can be split in to numerous segments.
In practice I have only seen a programme split in to two
segments as shown above.
To simplify recording these programmes, we identify segmented
programmes and extend the stop time. So, in the above case,
if the user records the 9pm showing then we will automatically
extend the stop time to be 23:30 instead of 22:00.
This patch explicitly disables "epg running state" for stopping
the recording. This is because the recording is tied to the first
showing and we don't want the recording to stop at 22:00 in the
above example.
We cache the calculated stop time to avoid any overheads, but
explicitly recalculate it at the start of the programme. This ensures
we detect any recent changes.
No modification is done of the actual EPG data to attempt to
merge the programme segments.
The consequence of this is that the EPG will only show a "recording"
marker against the first segment of the programme and not against
the second segment, which is unfortunate, however it is consistent
with recordings which have an extra stop time. The upcoming
recordings tab correctly shows the end time.
The duration of the finished recording is currently incorrectly
reported due to #3706. So the movie above would be reported as
60 minutes instead of 2h30.
Although the CRID processing is believed to be a global standard,
if other countries do not follow the UK/NZ specification then
the dvr_entry_get_segment_stop_extra could be updated to check a
(bitmask) config variable to enable/disable specific CRID processing.
I believe the overhead of the strcmp for the CRID check is minimal,
even on low-spec machines. If necessary we could cache to indicate
the CRID check has failed.
projects / thirdparty / tvheadend.git / log
