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);
Jiri Kastner [Thu, 22 Jun 2017 07:22:20 +0000 (09:22 +0200)]
rpm: makefile - extend cleaning
i realized, that after few builds rpm folder had 3GB,
because it keeped useless content in BUILD and SOURCES
also keeping generated tvheadend.spec results in not building
of current HEAD.
Mark Clarkstone [Wed, 14 Jun 2017 11:11:08 +0000 (12:11 +0100)]
mdhelp/markdown: add a space to all headers and fix a few little niggles properties: remove hash (#) from a few .name(s) and change a few others to (hopefully) make them clearer, as well as update a few .desc(s)
projects / thirdparty / tvheadend.git / log
