Store channel type in database

[Stuart Auchterlonie]

Store channel type (TV/Radio/Data etc) into database when we find that information during channel scanning.

This information can then be leveraged in other areas, such as when setting up a recorder and the type of streams it expects to find.

[stuartm]

Milestone 0.25 deleted

[stuartm]

This seems like an interesting and very simple addition, one for 0.26 maybe?

[Stuart Auchterlonie]

Yes, its a good one for 0.26. Fixing the milestone

[Karl Egly]

I'd love to see us store the SD/HD/UHD/3D part of the service type, too. My plan is to use it in MFDB for a fixup similar to FixHD on EIT.

[Stuart Auchterlonie]

Milestone renamed

[Stuart Auchterlonie]

Moving remaining open tickets to 0.28.2 milestone

[Stuart Auchterlonie]

Moving remaining open tickets to 29.2 milestone

[Klaas de Waal]

This would be useful to setup the buffering parameters for Live TV/Radio. At the moment the Live TV is setup for 8Mbit/s for all channels. This is OK for TV but for radio/audio-only channels a much lower setting would be better.

[Stuart Auchterlonie]

Klaas you are welcome to do this.

Regards Stuart

[Klaas de Waal]

It looks like the best value to use for channel type is the service_type as described in the DVB Bluebook A038, Feb 2019, pages 82 and 83. The way to do this is to extend database table channel with a field service_type and copy the service_type into this field when found during the channel scan.

[Stuart Auchterlonie]

Klass, this just needs a DB schema update to add an appropriate column, and then the code as you mention to store the relevant info

[Klaas de Waal]

Column service_type is added to database table channel in commit 8ae1c0b7958f3693ca4361bc9d116e55958a47ad which bumps the database schema version to 1352.

The code to retrieve and store the data as described in comment:15 is added in commit c7ad89a7eb999982c702eda9347603a9a7a1f532.

[Klaas de Waal <kdewaal@…>]

In 8ae1c0b79/mythtv:

Update database schema to version 1352

Revert type change in update to version 1351, part of
commit 6f876b31e9e1a3dbc4f1ef3a27d58f25daacae07
In update to version 1352:

• change type of region_id and bouquet_id from int to unsigned int
• add service_type to table channel for ticket #8774
• change schema version number to 1352

Refs #8774

[Klaas de Waal <klaas@…>]

In bba208158/mythtv:

Support for channel service_type in services API

Add support for service_type in the C++ code of the services API.
Partial support added for perl, python and php bindings.

Refs #8774

[Klaas de Waal]

The possible values of the service_type are enumerated in file dvbdescriptors.h in class ServiceDescriptorMapping?.

An example on how to use this class:

#include "dvbdescriptors.h"
{
    uint32_t service_type = ServiceDescriptorMapping::kServiceTypeDigitalTelevision;
    ServiceDescriptorMapping st(service_type);
    LOG(VB_GENERAL, LOG_INFO, QString("service_type:%1 '%2' IsDTV:%3")
        .arg(st.ServiceType()).arg(st.toString()).arg(st.IsDTV()));
}

which gives the following output:

service_type:1 ' (TV)' IsDTV:1

[Klaas de Waal]

The mythtv-setup channel scanner feature "Import Existing Scan" fails in v31 and in master because the new field service_type is missing in database table channelscan_channel.

For now the "Import Existing Scan" feature will be temporarily fixed by importing the scan results without the service_type field.

The service_type was added to database channel but it was not added to table channelscan_channel.

Adding this field to table channelscan_channel and restoring the functionality to use it will be done before the v32 release so that the database schema version of master will be the same as v31 for a while.

[Klaas de Waal <kdewaal@…>]

In c970d5837/mythtv:

Fix "Import Existing Scan" option

Fix the Channel Scan option "Import Existing Scan".
This option has been broken since adding the field service_type
to database table channel in ticket #8774.
The functionality has been restored, but excluding the service_type value which
will be added before release of v32 as this requires a database schema change.

Other changes are:

• Present the saved scans in descending chronological order, so with the newest on top
• When saving a new scan, delete all scans older than 14 days from that video source Previously, only scans created with the same capture card were deleted.
• Delete al saved scans of a video source when the video source is deleted

Refs #8774
Refs #13472