Jasmin Jessich [Wed, 1 Nov 2017 14:09:27 +0000 (15:09 +0100)]
Fixed crash on CAM remove
When TVH is terminated with <cntrl-c> and there is a CAM opened,
dvbcam_unregister_cam is executed prior to dvbcam_service_destroy.
dvbcam_unregister_cam will remove "as->ac" so linuxdvb_ca_enqueue_capmt,
executed in dvbcam_service_destroy will crash.
This should also fix a possible crash (not tested), when removing the
CAM with an active stream.
We add a few new format strings. This helps split
movies and tvshows in to separate folders to make
it easier for external programs to scrape.
$q and $Q determine if the programme is a movie or a
show from the guide data, with variants to force
detection as a movie or a show.
We then create "queryable" or scrapable names such as:
tvmovies/Gladiator (2000)
tvshows/Bonanza/Bonanza - S09E18 - The Burning Sky
This simplifies the recording format string for people
with good guide data since it easily splits the programmes
without need of post-processing scripts.
We don't split sports, news, etc. in to separate directories
purely because it is difficult to identify programmes that
are purely those categories. For example a popular nightly
politics series is classified as "News", whereas most people
think of news as being purely news headlines programmes.
We also add variants of $1q and $2q to force the programme
to be considered a movie or show ignoring the guide data.
The names are chosen to make it easier to add other variants
in the future if necessary ($3q, $4q, etc).
E.Smith [Fri, 13 Oct 2017 14:31:17 +0000 (15:31 +0100)]
dvr: Bump htsp_protocol_version. (#4652)
The new protocol supports DVR_AUTOREC_RECORD_UNIQUE and also
using categories in autorec (#4665).
We don't do any mappings of entries that have the enum since
clients I tested already map the unknown entry to "record all"
which I think is better than not sending the entry at all.
E.Smith [Thu, 5 Oct 2017 15:19:45 +0000 (16:19 +0100)]
dvr: Add new dup method of unique id. (#4652)
Programmes on many OTA channels and with many xmltv providers have unique ids.
This is the crid or the dd_progid.
So a particular movie will always have the same MV code, a particular episode
has the same EP code. Technically crid can be reused, but they don't appear to
be reused where I am.
If I have a rule for "Simpsons" it will record episodes but I have to decide
what dedup to use. If I use episode, then what happens when the Simpsons movie
is on? Is it recorded once, every repeat showing, never recorded?
So introduce a new method to differentiate programmes based on program id or
several other fields.
This is useful since many daytime programmes don't have unique descriptions or
any episode data in OTA, but can be distinguished by the crid.
The algorithm is:
- both have id and id is equal: dup;
- both have title+season+episode that are equal: dup;
- only one has title+season+episode: not dup;
- both have title+season or title+episode: undetermined so continue checks
- either has id or id is not equal: not dup;
- title+subtitle+description equal: dup;
- else not dup.
dvr: Start keeping programme unique IDs in the dvr log (#4652).
Many OTA and xmltv grabbers provide a unique id for programmes.
This is useful since many films have numerous remakes but keep
the same title, but have different unique id.
By starting to keep these IDs in the dvr log we may be able to
offer an easier de-dup method.
dvr: Allow selecting (xmltv) category in autorec. (#4665)
The xmltv import supports categories such as "movie",
"animated", "biography", so allow autorec to record via these
categories.
We do this by providing three drop-down selectors in the
advanced settings of the autorec. This allows the user
to easily discover the categories available whilst
providing enough capability for reasonably advanced
recordings when coupled with the existing fulltext search.
xmltv: Parse credits, category, keyword and more age ratings. (#4441)
The xmltv provides additional information about programmes such
as keywords ("Zookeeper", "Newscast", "Lion", "Mystery"), and
categories ("Crime drama", "Movie", "Series"). It can also provide
detailed information about actors, writers, editors, composers, etc.
We parse this information and allow it to be searched from the GUI.
We make this configurable since having 20+ actors per movie can
increase memory usage of the server and the clients to which we
send this information.
We also offer an option to append this information on to the
description. This allows people with old clients to see the
information.
We cache this information in to a csv string so users can search
across multiple actors such as "Douglas.*Stallone" to find movies
where both actors starred, rather than searching across each actor
individually.
The category is not currently searchable via regex since I think
that should probably be a search box similar to content type.
We currently only parse and store a few of the credits, viz., actor,
guest, presenter, writer, and director. If people really search for
films based on the composer or editor then we can add it in the future.
This information is stored on the epg_broadcast rather than the
epg_episode since theoretically a programme could have different
information for different showings of the same programme.
For example, my broadcaster shows the same film in the same week but
prefixes the description of some showings with a keyword (such as
"Frightfest") with other film of the same genre to create a pseudo-boxset.
Thus if we ever scrape keywords from EIT we'd probably tag the particular
films with this keyword as a tag on which people could search.
Similarly for credits, a daytime showing of a programme can contain edits
for violence, swearing that are not in the late night showing, thus potentially
changing the cast despite being the same "episode", or perhaps one showing
is dubbed.
We also parse a few more age ratings since a number of programmes
only have "word" ratings rather than age ratings (TV-14 instead of 14).
Also the existing age could underflow since one rating system
uses negative numbers which don't fit in our unsigned byte.
The _epg_object_set_lang_str has logic for setting lang_str_t.
We can re-use this logic for other objects in the future
(such as string_lists) so create a macro to abstract out
the destroy, compare, and copy functionality so the rest of
the logic can be re-used.
It's useful to be able to keep lists of sorted strings.
Although htsmsg allows us to keep lists, it is not
designed for easy sorted lists. So, build a simple
type on top of the existing RB trees.