Opened 3 years ago

Last modified 6 months ago

#13014 assigned Bug Report - General

switching to required delivery system

Reported by: willem@… Owned by: Klaas de Waal
Priority: minor Milestone: 31.0
Component: MythTV - DVB Version: 0.28.0
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The Hauppaugge Win soloHD and dualHD USB sticks (Silicon Labs Si2168), there are multiple delivery systems available: DVB-T, DVB-T2 and DVB-C/ANNEX_A.

The default at boot seems to be DVB-T. Using the tool dvb-fe-tool it is easy to switch to the required delivery system (dvb-fe-tool -a 0 -d DVBC/ANNEX_A for example). But when running mythtv-setup, the delivery system is recognized from the card. And I have not found a way to switch it.

My work-around is to run a quick systemd unit to use dvb-fe-tool to switch the card, but I feel I shoud be able to select the delivery system from the mythtv-setup utility.

Attachments (10)

preferDVBC.patch (799 bytes) - added by microcheese 9 months ago.
Prefer DVB-C Input instead of the DVB-T2 on multi Tuner Frontend
20190314-delsys-v0.patch (21.9 KB) - added by Klaas de Waal 7 months ago.
First implementation of support for multiple delivery systems.
delivery-system-patch-mythbackend.log (84.9 KB) - added by Mike Bibbings 7 months ago.
20190319-delsys-v1.patch (30.9 KB) - added by Klaas de Waal 7 months ago.
Second implementation of support for multiple delivery systems.
20190320-delsys-v1.patch (30.9 KB) - added by Klaas de Waal 7 months ago.
Regenerated the patch for today's master. No functional changes.
set-delsys-dvbt-dvbt2-dvbs-dvbs2-mythtv-setup.20190323080511.23318.log (120.6 KB) - added by Mike Bibbings 7 months ago.
20190325-modsys-all-v2.patch (11.1 KB) - added by Klaas de Waal 7 months ago.
Save delivery system in dtv_multiplex/del_sys for all delivery/modulation systems.
mysql-tables.txt (23.5 KB) - added by Mike Bibbings 6 months ago.
mythtv-setup.20190412152034.2544.log.tar.bz2 (96.1 KB) - added by Mike Bibbings 6 months ago.
mythtv-setup2-with-console-output.log.tar.bz2 (90.0 KB) - added by Mike Bibbings 6 months ago.

Download all attachments as: .zip

Change History (60)

comment:1 Changed 3 years ago by Stuart Auchterlonie

Milestone: unknown29.0
Owner: set to Stuart Auchterlonie
Status: newassigned

comment:2 Changed 2 years ago by Stuart Auchterlonie

Milestone: 29.030.0

comment:3 Changed 2 years ago by andreaz@…

I run in to a very similar issue. But even with dvb-fe-tool in front of mythbackend start isn't helping. Mythtv always switch it back to dvb-t. My Card is a digital devices Cine with a duoflex c2t2. The tuners on the cine card are working perfectly. The problematic ones are the both on the duoflex c2t2.

comment:4 Changed 2 years ago by andreaz@…

Is there a way to forbid mythbackend to switch the delivery system anyhow (disabling codeblocks or something), so i am able to set the default delsys prior the mythbackend start?

comment:5 Changed 21 months ago by bugs@…

Setting delivery system to DVBC using a mythbackend systemd override config including ExecStartPre? seems to help, for me.

comment:6 Changed 21 months ago by hugovangalen@…

I was unable to get any effective workaround in place. No matter what is set with dvb-fe-tool, the backend resets it.

In my case, where I have a DVB-C/T and a DVB-C/T/T2 frontend, the first is always re-initialised by the backend with a "DVB/C ANNEX_A", and the latter with a "DVB/T2" delivery system. This somehow causes an issue when trying to play video of the second frontend which eventually times out because "No lock" can be gotten.

I was able to get things working by altering dvbchannel.cpp (and cardutil.cpp which was probably not necessary) to force all frontends to DVBC.

It would be useful to be able to override the delivery system type for certain cards, or to tell the backend what general setting to apply, or to tell it to leave that setting alone.

comment:7 Changed 20 months ago by dcarretas@…

Yesterday I was able to put my TBS 6522 working on DVB-C and it keeps working after reboot. I used dvb-fe-tool -a 0 -d DVBC/ANNEX_A as it is referenced here and I put it into mythtv-setup -> General settings -> startup command. I also set on adapter config to allow concurrency with the adapter.

comment:8 Changed 10 months ago by Stuart Auchterlonie

Milestone: 30.031.0

comment:9 Changed 9 months ago by microcheese

Starting with the 30.0 Release there appeared a new issue with DVB Cards and multiple Protocols on one Frontend. Till 0.29 it worked fine with the dvb-fe-tool command before starting mythbackend - now this is not longer working. I did a small workaround patch to Prefer the DVB-C protocol (Instead DVB-T2) in Mythtv (see quick and dirty patch attached). The issue is that it selects currently only the DVB-T2 input, if both protocols available. Tested with a TBS 6290SE and TBS 6205 Quad Tuner. BTW - the dvb-fe-tool is still required in addition to the patch.

Changed 9 months ago by microcheese

Attachment: preferDVBC.patch added

Prefer DVB-C Input instead of the DVB-T2 on multi Tuner Frontend

comment:10 Changed 9 months ago by grizzlybear1980

I have the exact same problem when upgrading to 30.0 and the patch solves the problem for me as well.

comment:11 Changed 8 months ago by stefanb2

One of the changes for #12638 (Switch to using DVB APIv5) commit 55e1cac4bd249ec2e9463684a50121661af60417 (Partial support dvb v5 API) introduced a regression for multi delivery system HW, like the Hauppauge WinTV dual-HD DVB-T/T2/C USB stick.

If the frontend responds to the ioctl FE_GET_PROPERTY/DTV_ENUM_DELSYS query with a list that contains SYS_DVBS2 or SYS_DVBT2 then that will override anything else. If you had set up the device with 0.29 on a DVB-C multiplex, then 0.30 will try to tune a DVB-T2 device with those parameters (e.g. QAM), which of course fails:

2019-03-06 21:26:05.196847 W [3348/3348] CoreContext dtvmultiplex.cpp:286 (ParseDVB_T2) - DTVMux: Invalid T2 modulation system parameter '', aborting.
2019-03-06 21:26:05.196854 E [3348/3348] CoreContext recorders/dtvchannel.cpp:292 (SetChannelByString) - DTVChan[16](/dev/dvb/adapter2/frontend0): SetChannelByString(51): Failed to initialize multiplex options

There is no easy fix for this, because the root cause is that mythtv doesn't have support for specifying the DVB card subtype. It will always try to auto-detect when opening the frontend, which explains why solutions based on dvb-fe-tooldon't work.

For proper multi delivery system HW support IMHO the following changes would be required to mythtv:

  • libmythtv/cardutils returns the full list of develiver systems supported by a frontend
  • change mythtv-setup/Capture Cards that card subtype would be a selection list (currently the subtype is a read-only text field)
  • the table capturecard needs a new column cardsubtype which records the users choice
  • libmythtv/recoders/dvbchannel.c should use the setting from the database

FYI: as a workaround for the Hauppauge WinTV dual-HD issue I've submitted a patch proposal for the si2168 kernel module: it adds a parameter to disable DVB-T/T2 support. I.e. the frontend will only report DVB-C support and thus mythtv 0.30 is able to tune the device again. Such a change should be easy for other frontend kernel modules too.

comment:12 Changed 7 months ago by Klaas de Waal

Owner: changed from Stuart Auchterlonie to Klaas de Waal

comment:13 Changed 7 months ago by Klaas de Waal

This is the first version of support for multiple delivery systems.
It has been tested with two new devices:

  • MyGica? T230 DVB-T/T2/C with Silicon Labs Si2168 demodulator
  • Digital Devices DVB-T/T2/C with Sony CXD2837ER demodulator

The implementation is largely in line with the suggestions in comment:11. Thanks.

Note that this is NOT the full solution; this first implementation uses column displayname in table capturecard to store the selected delivery system. This enables testing without the need to modify the database schema.
The full solution will include a new column deliverysystem to store the selected delivery system.

The attached patch 20190314-delsys-v0.patch can be applied to today's master.

Changed 7 months ago by Klaas de Waal

Attachment: 20190314-delsys-v0.patch added

First implementation of support for multiple delivery systems.

comment:14 Changed 7 months ago by Mike Bibbings

I appreciate the patch is a minimal implementation.

Tried the patch on two test systems, one with PCI-e Device TurboSight? TBS 6522 DVB-S/S2/DVB-T/T2/C supports DVBT,DVBT2,DVBC/ANNEX_A,ISDBT,DVBC/ANNEX_B , the other with Astrometa USB Device Realtek RTL2832 DVB-T only.

On both systems with empty database (for Capture Cards and Videosources) creating Capture Card, Videosource and running a full channel scan worked.

I note that the patch does not support DVBS/S2. I tried it (TBS 6981 PCI-e card dual DVB-S/S2 is installed) and was offered Delivery Systems of DVBT,DVBT2 etc, which is not correct for the adapter/frontend combination.

For devices supporting DVBT and DVBT2 suggest DVB-T is not offered as the Delivery System, users often just accept the defaults, which currently has DVBT as first in the list. I would expect DVBS/S2 to also not offer DVBS if both DVBS and DVBS2 are supported. Is it intended in the final implementation to default Delivery system to something or make the user select from the drop down list. I would prefer it defaulted to DVBT2 if supported or DVBT if DVBT2 is not supported.

Applying the patch to an existing current master configured system, setting the Delivery system, and running a full scan results in duplication of existing channels but with channum set to serviceid, so there is an upgrade issue in that existing channels were not treated as old DVB channels and therefore should have been updated.

LiveTV does not work, neither does EIT scanning. Attached is a mythbackend log showing tuning failure for LiveTV. A failure is at:

Mar 14 20:13:23 mike-AB350-Gaming-3 mythbackend: mythbackend[15959]: E TVRecEvent recorders/dtvchannel.cpp:281 (SetChannelByString?) DTVChan[1](/dev/dvb/adapter0/frontend0): SetChannelByString?(1): Failed to initialize multiplex options

All testing was done on Xubuntu 18.04.2 using kernel 4.18.0-16-generic #17~18.04.1-Ubuntu SMP Tue Feb 12 13:35:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

with mythtv master 686ab4092b

The test systems are available for further testing if it helps.

Mike

Changed 7 months ago by Mike Bibbings

comment:15 Changed 7 months ago by stefanb2

If I understand the patch correctly it just sets the frontend type on the HW using FE_SET_PROPERTY / DTV_DELIVERY_SYSTEM. That leaves m_tunerType unchanged. But that instance variable determines how dtvchannel.cpp and recorders/dvbchannel.cpp talk to the frontend, e.g. when setting the multiplex parameters.

comment:16 Changed 7 months ago by Klaas de Waal

Thanks to the reviewers of the first version.

This is the second version of the support for multiple delivery systems. Changes with respect to the first version are:

  • Set m_tunerType to the correct value instead of to the value from FE_GET_INFO/info.type
  • Support for DVB-S/S2. This is largely untested, however, an ancient Hauppauge WinTV Nova S PCIbus card is recognized correct and, not surprisingly, has only one delivery system.
  • Presentation names for delivery/modulation systems have been mostly reverted to the old values, e.g. DVB-T instead of DVBT and DVB-C/A instead of DVBC/ANNEX_A. The shorter size makes them fit in column mod_sys of table dtv_multiplex where this information is also stored.
  • The delivery system is now stored in capturecard/inputname instead of in capturecard/displayname. The field inputname dates from the days of analog television; if this does not cause a conflict then maybe this field can be used permanently instead of creating a new field. At the moment it is possible to modify the inputname with the GUI in the "Input connections" dialog but this should not be done in this test.
  • EIT scanning, both active and passive, does work on DVB-T2 and DVB-C.
  • Live TV does work on DVB-T2 and DVB-C.

Not investigated yet:

  • Failure to recognize existing channels with a scan update, resulting in duplicates

About user-friendly defaults in the mythtv-setup GUI. This is something that deserves a separate ticket. For instance, a delivery system is really information that belongs to a video source, so it could be better to move the delivery system choice to the video source and then automatically configure the tuner when the tuner is connected to that video source.

In case of any issue a log file of both mythtv-setup and mythbackend would be very helpful.

The attached patch 20190319-delsys-v1.patch can be applied to today's master.

Changed 7 months ago by Klaas de Waal

Attachment: 20190319-delsys-v1.patch added

Second implementation of support for multiple delivery systems.

comment:17 Changed 7 months ago by Klaas de Waal

About "Failure to recognize existing channels with a scan update, resulting in duplicates".
This is a problem that cannot be reproduced here.

The following sequence, using the same physical tuner:
With today's master:

  • select videosource "ziggo" with DVB-C signal
  • delete all channels
  • ChannelScan? with "Full Scan (Tuned)"

Then with today's master, with the patch applied:

  • select videosource "ziggo" with DVB-C signal
  • ChannelScan? with "Full Scan (Tuned)"

Result is that all "old" channels are found and they can be updated. There have been no duplicates generated.
If the problem is still present with the latest patch then it would help to have the information from database table channel of the original and the duplicate channels. Possibly table dtv_multiplex is interesting also.

Changed 7 months ago by Klaas de Waal

Attachment: 20190320-delsys-v1.patch added

Regenerated the patch for today's master. No functional changes.

comment:18 in reply to:  17 Changed 7 months ago by Mike Bibbings

Replying to Klaas de Waal:

About "Failure to recognize existing channels with a scan update, resulting in duplicates".
This is a problem that cannot be reproduced here.

The following sequence, using the same physical tuner:
With today's master:

  • select videosource "ziggo" with DVB-C signal
  • delete all channels
  • ChannelScan? with "Full Scan (Tuned)"

Then with today's master, with the patch applied:

  • select videosource "ziggo" with DVB-C signal
  • ChannelScan? with "Full Scan (Tuned)"

Result is that all "old" channels are found and they can be updated. There have been no duplicates generated.
If the problem is still present with the latest patch then it would help to have the information from database table channel of the original and the duplicate channels. Possibly table dtv_multiplex is interesting also.

Retested without patch, the problem exists in current mythtv master. I have raised a trac ticket https://code.mythtv.org/trac/ticket/13432

comment:19 Changed 7 months ago by Mike Bibbings

Re: Regenerated the patch for today's master. No functional changes.

I have tested the v1 patch against current master and it works.

The only thing I did notice (due to underlying master, not the patch) was that when del sys is set to DVB-S, mod_sys in dtv_multiplex table is UNDEFINED, rather than DVB-S. When set to DVB-S2 the expected DVB-S or DVB-S2 are set for mod_sys. Maybe a similar change to that done to set DVB-T is required?

For the record I ran mythtv-setup configuring as follows:

Astrometa USB tuner, scanned with del sys DVB-T

TBS 6522 PCI-e tuner, scanned with del sys DVB-T and DVB-T2

TBS 6981 PCI-e tuner, scanned with del sys DVB-S and DVB-S2 Attached is mythtv-setup log (just default logging)

Build version:

mike@mike-AB350-Gaming-3:/tmp$ mythbackend --version Please attach all output as a file in bug reports. MythTV Version : v31-Pre-227-gd0208428b1-dirty MythTV Branch : master Network Protocol : 91 Library API : 31.20190109-1 QT Version : 5.9.5 Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_x11 using_xnvctrl using_xnvctrl_external using_libbluray_external using_xrandr using_xv using_profiletype using_systemd_notify using_systemd_journal using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_vaapi using_vaapi2 using_nvdec using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2

Changed 7 months ago by Mike Bibbings

comment:20 Changed 7 months ago by jpilk

I have current master running: d81335eec11

I was confused because only one of the supported delivery systems could be selected in card config, but it appears that selecting DVB-T2 does allow the MyGica? card to fallback to DVB-T

comment:21 Changed 7 months ago by Klaas de Waal

The current master now includes the v1 patch, with minor modifications.

This makes it possible to select a delivery system that is not the first in the list, so a tuner that supports DVB-T/T2/C can now be used as a DVB-C tuner.

The already existing DVB-T/T2 scanning code tries both DVB-T and DVB-T2 for each multiplex if the tuner does support that. This has made it possible to scan and receive DVB-T2 multiplexes already quite some time. This functionality is NOT changed by the v1 patch.

Now that it is possible to select a delivery system in the card configuration, the code can be simplified so that if you select DVB-T you get DVB-T multiplexes and if you select DVB-T2 you get DVB-T2 multiplexes. This would definitely be less confusing and as simpler code is a Good Thing I am happy to do this but I do not know if this breaks anything. At least it would then require two scans to get both the DVB-T and DVB-T2 multiplexes.

comment:22 Changed 7 months ago by Mike Bibbings

Here in the UK we have Freeview which is a mixture of DVB-T and DVB-T2 multiplexes at a particular transmitter, so the Capture card needs to be set to DVB-T2, but mythtv-setup needs to scan for both DVB-T and DVB-T2 to setup the dtv_multiplex table to either DVB-T or DVB-T2. Some tuner drivers do not care and auto switch between DVB-T and DVB-T2, other drivers must be told which to use as there is no standard for this auto switching.

comment:23 Changed 7 months ago by Klaas de Waal <kdewaal@…>

In 860231879/mythtv:

Support for multiple delivery systems

In mythtv-setup, add selection of a delivery system for
tuner frontends that support multiple delivery systems.
In mythbackend, setup the frontend to use that
delivery system before recording.

Refs #13014

comment:24 Changed 7 months ago by Klaas de Waal <kdewaal@…>

In d81335eec/mythtv:

Show delivery system in "Input connections" configuration screen

Previously the mythtv-setup "Input connections" configuration screen showed
on the first line the "Input name" with user selectable value in drop down box.
For DVB cards the label is now "Delivery system" and the presented value is not editable.
Note that the delivery system can be selected in the card configuration screen.
For non-DVB cards nothing has changed.

Refs #13014

comment:25 Changed 7 months ago by Klaas de Waal

The new patch, 20190325-modsys-all-v2.patch implements:

  • The delivery system is now stored in dtv_multiplex/mod_sys for all delivery systems.

This should solve the issue that the delivery system is not stored for DVB-S. This fix replaces the part of the previous fix in which the delivery system for DVB-T was stored explicitly.

This patch can be applied to the current master. Note that the previous "v1" patch has been committed already; this patch only contains the new functionality, some code cleanup and minor cosmetic changes.

Changed 7 months ago by Klaas de Waal

Save delivery system in dtv_multiplex/del_sys for all delivery/modulation systems.

comment:26 Changed 7 months ago by jpilk

After I installed current master (comment 20) it seemed appropriate to re-run mythtv-setup. I suspect it might be essential to do so. Should this be flagged?

comment:27 Changed 7 months ago by Klaas de Waal

After the fix in ticket #13434 it should be possible to run the latest mythbackend without having run mythtv-setup. If there are still problems with this then please report.

With mythtv-setup the following sequence gives a clean start:

  • Delete all capture cards
  • Delete all video sources; this also deletes all transports
  • Create the capture cards and select the modulation system
  • Create the video sources
  • Connect the video sources
  • Do a "Full Scan" (for DVB-T/T2) or "Full Scan (Tuned)" (for DVB-C)

comment:28 Changed 7 months ago by jpilk

I have done limited testing with 9593dc9. It appears to work for me. One device does DVB-T only, and sees 6 transports. The other is DVB-T/T2 capable, sees the 6 DVB-T and 3 DVB-T2 transports. I can make simultaneous recordings from 2xT, or 1xT and 1xT2, and get conflicts, as expected, if I try 2xT2 transports. But I *have* run mythtv-setup, several times.

I get all my muxes from one mast, and the 'search for linked transports' works well for me - but does not find additional DVB-T2 transports. So I do 2 'all known and linked transports' scans, one for DVB-T, and one for DVB-T/T2. Minimum starting info seems to be freq/BW for the main BBC DVB-T mux, and freq/BW for all three DVB-T2 muxes. Unfortunately the ukfree.tv site has still has incorrect data, but my TV can reveal it, in a 'manual tuning' menu.

I suppose this is the official source; but everyone there has probably been working on Brexit too.

https://www.ofcom.org.uk/spectrum/information/transmitter-frequency

http://www.ofcom.org.uk/static/broadcasting/Complete-DTT-frequency-plan.xls

comment:29 Changed 7 months ago by Klaas de Waal <kdewaal@…>

In 9593dc90b/mythtv:

The delivery system is now stored in dtv_multiplex/mod_sys for all delivery systems.

There is also some code cleanup, additional debug messages and minor cosmetic changes.
This commits the changes in attachment 20190325-modsys-all-v2.patch of ticket #13014.

Refs #13014

comment:30 Changed 7 months ago by Klaas de Waal <kdewaal@…>

In 161d7857c/mythtv:

Use cardid and inputname (delivery system) on OSD when displayname is empty.

In mythtv-setup, an input connection can be given a "Display name (optional)".
This name is typically used to give a user-friendly name to a tuner card.

This name is shown on the screen the first time Live TV is started.

If there is no displayname defined there is a name generated consisting
of the input number, the card type and the inputname.
The inputname is now used to store the delivery system; this leads
to names as "1: DVB/DVB-T2" which contain one DVB too many.
This fix changes the name to the input number and the inputname,
for instance: "1: DVB-T2".
N.B. This is the same format what would be generated by function
TV::UpdateOSDInput in tvplay.cpp, if CardUtil::GetDisplayName? would
return an empty string.

Refs #13014

comment:31 Changed 7 months ago by hugovangalen

Great! I installed the latest master and can confirm that, for me, the problems have gone away. (I did need to go into mythtv-setup and switch all the frontend delivery subsystems from "DVBInput" to "DVBC/A".)

comment:32 Changed 7 months ago by jpilk

Yes. I updated another system, with 3 DVB-T-only cards, from 31.Pre.227.gd0208 to 31.Pre.306.g161d7 (4 days). I had the Video source set as 'eit' and could not access the Transport editor until I had reset the card delivery systems to DVB-T; then rescanned with a one-transport seed as in Comment 28. All seems ok now, but it was disconcerting to see that 'You haven't selected any programmes to record' - until EIT began to repopulate the guide.

comment:33 Changed 7 months ago by jpilk

Perhaps this is a result of not going through the full mythtv-setup, but my recordings now have chanids 9000 greater than before - so the channels of old recordings are not identified...

eg 1002 -> 10002 ??

comment:34 in reply to:  33 Changed 7 months ago by Gary Buhrmaster

Replying to jpilk:

Perhaps this is a result of not going through the full mythtv-setup, but my recordings now have chanids 9000 greater than before - so the channels of old recordings are not identified...

eg 1002 -> 10002 ??

As of v30 commit 503218e (~October 2018) newly created chanids are typically assigned as (10000 * videosource_id + channum), while previously it was (1000 * videosource_id + channum). Existing chanids remain the same as long as you do not directly or indirectly delete the old ones (and then later add them back). Chanids should mostly be considered opaque numbers (the actual chanid assigned will be munged in some cases), although they are clearly visible in file system names.

comment:35 Changed 7 months ago by Klaas de Waal

In commit 503218e716f3c7d81e328497499b31a7ee624ad9 on Sep 6, 2018 the channel ID generation has been changed from "sourceid * 1000 + chan_num" to "sourceid * 10000 + chan_num".

comment:36 Changed 7 months ago by jpilk

OK, thank you both. I have just done the full 'delete all cards' setup and, not surprisingly, see the same thing. I can live with it, but as of now I guess I have around 2400 recordings for which the frontend does not show a channel name - only the old #chanid...

comment:37 Changed 7 months ago by Klaas de Waal

Replying to jpilk comment:36

If you are adventurous you could do something like this:

MariaDB [mythconverg]> update recorded set chanid=(chanid DIV 1000 * 10000) + (chanid MOD 1000) where chanid<10000 limit 1; Query OK, 1 row affected (0.001 sec) Rows matched: 1 Changed: 1 Warnings: 0

comment:38 Changed 7 months ago by Klaas de Waal

Again with proper formatting:

MariaDB [mythconverg]> update recorded set chanid=(chanid DIV 1000 * 10000) + (chanid MOD 1000) where chanid<10000 limit 1;

N.B. The "limit 1" does reduce the damage in case it does not work.

comment:39 Changed 7 months ago by jpilk

Yes, that looks plausible. But perhaps, like St Augustine and chastity, 'not yet'. I'll see how things go. Cheers.

comment:40 Changed 7 months ago by Klaas de Waal

About comment:38. Although the SQL statement does actually work, I've just learned that chanid+starttime is the primary key for lots of tables, e.g. the recordedseek which is useful to jump around in a recording. It is better to lose only the name of the channel that it is to lose everything else.

Thx to gigem for pointing this out.

comment:41 Changed 7 months ago by jpilk

Yes, I was afraid there might be other consequences of modifying the DB.

I notice that the format which I use in mythlink has lost the old channel numbers too; I may investigate further, but life goes on.

comment:42 in reply to:  36 Changed 7 months ago by Gary Buhrmaster

Replying to jpilk:

OK, thank you both. I have just done the full 'delete all cards' setup and, not surprisingly, see the same thing. I can live with it, but as of now I guess I have around 2400 recordings for which the frontend does not show a channel name - only the old #chanid...

The current state is that if one wants the old associated channel names/logos/etc. one has to be careful when deleting/running various things that result in deleting the old channels that are referenced by recordings.

FWIW, there has been a statement of an intention/proposal by a dev on the -dev list to change some things in that area that would copy the required channel data to the appropriate recorded tables, which would eliminate this particular anomaly of losing names/logos on past recordings.

comment:43 Changed 6 months ago by Mike Bibbings

In current master [v31-Pre-439-g7a59e6f36c] channel scan for Satellite DVB-S/S2 is broken. mod_sys in dtv_multiplex table has everything set to DVB-S2. Some should be set to DVB-S.

The log files are for a full tuned scan of Astra 28E2 (notionally UK Freesat,but does include some other FTA channels)

The mythtv-setup2-with-console-output.log.tar.bz2 captures the additional console output which may be of use (at the end it has all the found channel data, which does not get into the normal log)

attachments: mysql-tables.txt mythtv-setup.20190412152034.2544.log.tar.bz2 mythtv-setup2-with-console-output.log.tar.bz2

Mike

Changed 6 months ago by Mike Bibbings

Attachment: mysql-tables.txt added

Changed 6 months ago by Mike Bibbings

Changed 6 months ago by Mike Bibbings

comment:44 Changed 6 months ago by Klaas de Waal

Interesting!

It looks like the scan itself uses the correct modulation system as it does change from DVB-S to DVB-S2 and vice versa, as shown by the following bits of debug output from mythtv-setup2-with-console-output.log (with line numbers):

    430 Old Params: 10714000 qpsk a auto auto a a auto a h fec: auto msys: DVB-S rolloff: 0.35
    431 New Params: 11758500 qpsk a auto auto a a auto a h fec: auto msys: DVB-S2 rolloff: 0.35
    432 2019-04-12 16:24:59.923974 I  DVBChan[1](/dev/dvb/adapter0/frontend0): Tune(): Tuning to 11758500kHz
    433 2019-04-12 16:24:59.981260 D  DVBChan: modsys DVB-S2
    434 2019-04-12 16:24:59.981296 D  DVBChan[1](/dev/dvb/adapter0/frontend0): prop 0: cmd = 17, data 6
    ....
    543 Old Params: 11758500 qpsk a auto auto a a auto a h fec: auto msys: DVB-S2 rolloff: 0.35
    544 New Params: 11778000 qpsk a auto auto a a auto a v fec: 2/3 msys: DVB-S rolloff: 0.35
    545 2019-04-12 16:25:12.309666 I  DVBChan[1](/dev/dvb/adapter0/frontend0): Tune(): Tuning to 11778000kHz
    546 2019-04-12 16:25:12.309786 I  DiSEqCDevTree: Changing LNB voltage to 13V
    547 2019-04-12 16:25:12.505274 D  DVBChan: modsys DVB-S
    548 2019-04-12 16:25:12.505319 D  DVBChan[1](/dev/dvb/adapter0/frontend0): prop 0: cmd = 17, data 5

However, the dtv_multiplex is definitely wrong and should have DVB-S or DVB-S2 where appropriate instead of having DVB-S2 everywhere.

It is interesting to know if:

  • you started with a correct dtv_multiplex, i.e. with DVB-S and DVB-S2 correct filled in, and the scan did "destroy" the dtv_multiplex (rescan existing transports)
  • or if you started with an empty dtv_multiplex and everything comes from the NIT (full scan tuned)

Can you please do an identical scan with, in addition to "general, channel, record" also "chanscan", again with --loglevel=debug ?

Thanks! Klaas.

comment:45 Changed 6 months ago by Mike Bibbings

Hi Klaas,

It was a clean start, empty capturecard and dtv_multiplex tables. Will run again with the extra logging

Mike

comment:46 Changed 6 months ago by Mike Bibbings

Hi Klaas,

New log files have been created with chanscan for the DVB-S2 problem.

Files are too big to attach (2M limit per file), even when zipped, so I have put them in my Dropbox

https://www.dropbox.com/sh/3u7rtnghamaujsc/AAASJ5Lh59slVTVlGXyDFvV_a?dl=0

Mike

comment:47 Changed 6 months ago by Klaas de Waal <kdewaal@…>

In 47c1d3061/mythtv:

Do not overwrite modulation system in multiplex with value from tuner.

A DVB-S multiplex can be received by a tuner configured for a DVB-S2 delivery system.
The removed line of code did overwrite the modulation system in
the multiplex with the delivery system currently configured in the tuner.
This caused the modulation system in all DVB-S/S2 multiplexes to be set to DVB-S2.

Refs #13014

comment:48 Changed 6 months ago by Klaas de Waal <kdewaal@…>

In d3f58fd9fa/mythtv:

Add modulation system in dtv_multiplex for DVB-C and DVB-S tuners.

Refs #13014

comment:49 Changed 6 months ago by Klaas de Waal

When doing a channelscan there is now a suitable default delivery system selected if the user has not done that. This should make the move from v30 to the current master, and later to v31, run smooth also for casual users. See ticket #13449.

comment:50 Changed 6 months ago by Klaas de Waal <kdewaal@…>

In 806eb647d/mythtv:

Select best default delivery system when creating new capture card.

Previously, when creating a new capture card in mythtv-setup
the default delivery system was the first one of the available
delivery systems for that card. Unfortunately, if a device is
capable of e.g. both DVB-T and DVB-T2 then DVB-T is first on the
list and thus the default even if DVB-T2 is usually the better choice.
Idem for DVB-S and DVB-S2.
With this fix the better choice is now the default.
Note that when editing an existing capture card the value
for the delivery system in the database is always the default,
even if it is DVB-T or DVB-S.

Refs #13014

Note: See TracTickets for help on using tickets.