Jaroslav Kysela [Fri, 29 Sep 2017 07:31:52 +0000 (09:31 +0200)]
prop: prop_sbuf / prop_ptr cleanups
The prop get string callbacks should use static buffers. This
patch is trying to fix the problematic parts (mostly in dvr_db.c)
and also introduces prop_ptr to not allocate static pointer
in each string get callback.
The problems in dvb_db.c were serious, so tvh could crash or
invalid data are written to the config files.
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".
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.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
The date calls are designed to work with both GNU date and BSD date
src/spawn.c:306:7: warning: implicit declaration of function 'kill' is invalid in C99 [-Wimplicit-function-declaration]
kill(-(s->pid), SIGKILL);
^
src/spawn.c:306:23: error: use of undeclared identifier 'SIGKILL'
kill(-(s->pid), SIGKILL);
^
src/spawn.c:655:3: warning: implicit declaration of function 'pthread_kill' is invalid in C99
[-Wimplicit-function-declaration]
pthread_kill(spawn_pipe_tid, SIGTERM);
^
src/spawn.c:655:32: error: use of undeclared identifier 'SIGTERM'
pthread_kill(spawn_pipe_tid, SIGTERM);
projects / thirdparty / tvheadend.git / log
