The configuration to enable finding a 'best' time slot for
recording is now configurable as an advanced option in
Configuration->Recording->DVR Profiles, with the default being
disabled.
When toggled, the autorec rules themselves need to be manually
toggled to cause them to reschedule.
dvr: Prefer earlier/better schedule events for autorecs.
We now try to avoid scheduling on a timeshift channel X+1 if we have
the same programme on channel X. If a programme is on at the same time
on multiple channels then we will try and schedule on a better
channel, such as one with more services (such as mixed DVB-T/DVB-S) to
allow service switching fallback on tuner conflict.
An example of the new log entry:
dvr: Autorecord "movie misc" Replacing existing dvr recording entry of
"The Departed" on ITV4+1 @ start 2018-09-20;00:35:00(+0100) with
recording on ITV4 @ start 2018-09-19;23:35:00(+0100)
Context for the change is below:
In some areas, a broadcast programme might be shown at the same time
on multiple channels, or at different times on various timeshift,
repeat, or regional channels.
An example of this is the Astra 28.2E satellite where BBC1 has
multiple (26) regional channels that (mostly) show the same
programmes, but sometimes a region might have a +30m or +1h timeshift
for a single programme.
Similarly the commercial channel "Channel 4" has "Channel 4+1", and a
repeat channel of "4Seven" and various associated HD channels. Homes
receive all these regional channels via one dish and are required for
BBC to manually switch between HD/SD versions for local interest
programmes such as regional news.
Previously, when setting an autorec, the item chosen to record was
based on the first broadcast that matched the criteria (such as film
title). However, this broadcast is not necessarily the earliest or the
best.
So this meant that with timeshift channels, a programme could be
scheduled on X+1 instead of X, so record at 21:00 instead of 20:00.
On other setups, the event might correctly record at 20:00, since
scheduling depended on internal structures and which broadcasts are
found first (such as via OTA updates).
Similarly, in countries where the same programme can be received but
on different channels in different qualities, it was possible to
schedule on a non-HD channel, even though the user wanted HD purely
because the non-HD broadcast was found first and the channels were not
merged.
So we now check our recording list to determine if the event is better
than the already scheduled event. If so, the existing recording event
is replaced.
For our criteria, "better" is defined in the function
dvr_is_better_recording_timeslot, and has a variety of criteria such
as "matches service filter", "earlier start", and "has more services"
(so more likely to be able to failover if there is a problem). If
other criteria are equal, then we use the channel with the lowest
channel number since Europe EPG has lower channel numbers for
'better' channels.
When determining if an autorec can be scheduled in a better timeslot,
we must only check against other autorecs and not a manually scheduled
entry since the user might schedule a recording at a later date
specifically to avoid conflicts.
This is achieved by replacing the old scheduled recording with a new
scheduled recording. A new log message indicates when this occurs.
Performance: Initial testing suggests that this rescheduling can occur
between zero and two times per programme (when there is an initial
schedule on +1, then a reschedule on non-timeshift SD, then final
schedule on HD). However, it should not add significant runtime
overhead for most people.
Jongsung Kim [Mon, 28 May 2018 18:42:04 +0000 (03:42 +0900)]
webui: fix http_serve_file() for FreeBSD
This patch fixes two major problems of FreeBSD port of tvheadend:
1. very high CPU usage while streaming a recored program
2. unable to stream the recorded program beyond 128MB.
Unlike Linux sendfile(), FreeBSD sendfile() requires an explicit
file offset, and return value must be checked to catch any error
occurred. (i.e., closed connection)
Patch tested with the latest FreeBSD port of tvheadend-4.2.6.
It looks because tcp_socket_dead() misunderstood the zero-return
from recv(). For the FreeBSD, recv() might return zero for alive
sockets which have nothing to read.
Patch tested with the latest FreeBSD port of tvheadend-4.2.6.
projects / thirdparty / tvheadend.git / log
