macrule [Wed, 29 Nov 2017 17:18:53 +0000 (18:18 +0100)]
wrappers: Implemented correctly for Darwin.
pthread_cond_timedwait() is not usable on Darwin, because it cannot be configured to use the monotonic clock. So instead the relative pthread_cond_timedwait_relative_np() is used with a relative time to wait for.
Only tvhthread_renice() is missing, but there seems to be currently no way on Darwin or FreeBSD to implement per-thread prioritization. The #warning is good, but it breaks with the default -Werror compile flag.
macrule [Wed, 29 Nov 2017 17:18:53 +0000 (18:18 +0100)]
tvhpoll: Fixed tvhpoll_add kqueue implementation.
The semantics of tvhpoll_add() in the epoll implementation is to set exactly the specified filters, and not add to any previously added ones. The kqueue implementation only added filters, and never removed those that were not set anymore.
This caused busy-polling in satip_frontend on FreeBSD and Darwin, because tvhpoll_wait() always returned immediately. This happened because the receiving socket was always ready to accept data for writing. The following recv() call was called repeatedly without any delay and caused high CPU utilization.
Daniel Becker [Thu, 21 Sep 2017 04:42:39 +0000 (21:42 -0700)]
fix storage space calculation
The f_bfree and f_bavail members in struct statvfs are expressed in
units of f_frsize, not f_bsize (see the statvfs(2) manpage, e.g. here:
<https://linux.die.net/man/2/statvfs>). The two can differ quite
substantially, e.g. on ZFS.
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.
projects / thirdparty / tvheadend.git / log
