MythTV / mythtv

The official MythTV repository
https://www.mythtv.org
GNU General Public License v2.0
704 stars 345 forks source link

Move backend config from mythtv-setup to mythbackend internal web server #239

Closed stuarta closed 11 months ago

stuarta commented 3 years ago

It's cumbersome to have to use mythtv-setup (an X application) on a headless backend server. We should be able to perform all required setup via the webserver in the backend

Original trac ticket https://code.mythtv.org/trac/ticket/8262

bennettpeter commented 1 year ago

I confirm that if you have changed the video source on the page, you have to save before scanning. I am making a change to warn you to save before scanning when it is necessary, and to disable the scan button if you have not saved.

rcrdnalor commented 1 year ago

Update to https://github.com/MythTV/mythtv/issues/239#issuecomment-1584929121 With MythTV Version : v34.0~master.202306140148.5cad31054d~ubuntu23.04.1 I was able to import channels from FREEBOX (iptv), but I had no luck with a full scan for DVB-T2 channels triggered from the web interface. I guess I found the reason: Within channelscanner_web.cpp the call to https://github.com/MythTV/mythtv/blob/ba1d6831e50a14a72cf245dff86fc436b680d806/mythtv/libs/libmythtv/channelscan/channelscanner_web.cpp#L89 returns values different than the code is expecting: DVB_T2 vs. DVBT2 Log excerpt with logging options general:debug,http:info,chanscan:info,channel:info:

I HTTP4 mythhttpsocket.cpp:276 (Read) 127.0.0.1:41490: Processing: path '/Channel/' file 'StartScan'
I HTTP4 cardutil.cpp:1233 (SetDeliverySystem) CardUtil[7]: Set delivery system: DVB-T2
D HTTP4 cardutil.cpp:1036 (ProbeSubTypeName) CardUtil[7]: subtype:DVB_T2 

Note: The subtype in the log is what above function call returns and further used as inputType in channelscanner_web.cpp.

That is the reason, why a channel scan immediately returns 'false'. I guess, this is also true for other DVB types and worked only by chance for inputType == "ATSC".

kmdewaal commented 1 year ago

Yes, that must be it. Well spotted! Maybe do this similar to how it is done in scanwizardconfig.cpp:230 where the inputType is converted to an enum value and then the tests are done on enum symbolic values. This prevents typo's in literal string constants. Note also the part that is conditional on USING_SATIP, that is needed here as well.

    QString subtype = CardUtil::ProbeSubTypeName(m_hwCardId);
    int nCardType   = CardUtil::toInputType(subtype);

#ifdef USING_SATIP
    if (nCardType == CardUtil::SATIP)
    {
        nCardType = SatIP::toDVBInputType(CardUtil::GetVideoDevice(cardid));
    }
#endif // USING_SATIP

    const QString fullScanHelpTextDVBT2 = QObject::tr(
        "For DVB-T/T2 and scan type 'Full Scan' select a country to get the correct set of frequencies.");

    clearSelections();

    switch (nCardType)
    {
        case CardUtil::V4L:
        case CardUtil::MPEG:
            addSelection(tr("Full Scan"),
                         QString::number(FullScan_Analog), true);
            addSelection(tr("Import existing scan"),
                         QString::number(ExistingScanImport));
            return;
        case CardUtil::DVBT:
...
kmdewaal commented 1 year ago

I've done a quick test with the above changes applied. I do a "Full Scan (Tuned)" on a HDHomeRun DVB-C, but that does not yet work. It still fails with parsing of the modulation parameter. For the scan I do select the Modulation value QAM-64 as presented in the list. When it arrives in the parsing routines the modulation is set to "unknown". This value is assigned is in line 212 of channelscanner_web.cpp.

207             break;
208         case ScanTypeSetting::FullScan_Analog:
209             modulation = "analog";
210             break;
211         default:
212             modulation = "unknown";
213     }
216 
(gdb) p nScanType
$2 = 11

The scantype 11 is NITAddScan_DVBC but the switch tests on FullScan_DVBC.

This is as far as I got today...

bennettpeter commented 1 year ago

Response to https://github.com/MythTV/mythtv/issues/239#issuecomment-1593631129 Thank you Ernst. Actually the only ones affected are DDV_T2 and DVB_S2. There is an enum for this and I am changing it to use that, as suggested by Klaas. Once that it is an enum I can use a switch instead of the if statements.

bennettpeter commented 1 year ago

Response to https://github.com/MythTV/mythtv/issues/239#issuecomment-1594510264 Thank you Klaas. I believe that I need to remove that default line. The modulation comes in the input parameters. So it is wrong to reset it to unknown here. I will make a change.

bennettpeter commented 1 year ago

I have pushed both fixes, for DVB_T2 and DVB_S2 as well as the modulation fix. I cannot test these as the only DVB type I can test is ATSC cable.

kmdewaal commented 1 year ago

HDHomeRun DVB-C "Full Scan (Tuned)" is OK. HDHomeRun DVB-T2 "Full Scan" and "Scan all existing transports" is OK. SatIP "Full Scan (Tuned)" fails with message "This scan type is not supported". I will have a look at where this comes from. To be continued.

jfabernathy commented 1 year ago

I just rebuilt and tested your latest. tl:dr it worked on ATSC 1.0 OTA but odd behavior on Program guide

after rebuild and reboot I used the web app to enter setup and deleted all channels in the Channel Editor and deleted all tuners. Then I added back 4 HDHR ATSC tuners without the EIT scan enabled, i.e. the default.

I then edited the first tuner in Input Connections by selected the name as MPEG2TS and picking the Video source as SD. I Saved per the requirement and tip. Then I did a full scan but set it to stop at channel 20 and not go to the max of 36.

Full scan works and found all my channels. I Inserted all and then set the starting channel and saved.

I did the same on the other 3 tuners without doing another Full Scan.

On Channel Editor I changed 3 channels to no visible and saved.

At this point I restarted the backend and checked the Dashboard and other tabs.

Channels looked good, Upcoming was blank as expected because the EPG should be blank but when I checked the Guide I had some channel data but not for the nn.1 main channels. It also had no channel Logos.

In the past that page showed as completely blank except for the listing of channel numbers. So I did as I always have done and ran mythfilldatabase. This completed quickly as the database was update this morning early.

At this time the Guide looked complete on all channels with logos.

kmdewaal commented 1 year ago

I just pushed a fix for the SatIP channel scanning. Scan is still running but it starts OK and the rest is common code. About changing the if-then-else to a switch. This gives now loads of warnings about enumeration values that are not handled. The software police is closing in on us... and in this case I think the if-then-else is maybe better to avoid the warnings.

jfabernathy commented 1 year ago

When I compiled I did hear the police sirens in the distance. :-)

bennettpeter commented 1 year ago

I fixed the compiler warnings by adding a default: to the switch statement.

kmdewaal commented 1 year ago

I now try to scan on another system with a /dev/dvb PCIbus card for DVB-C. Scanning with mythtv-setup works OK. With the webapp, on selecting the "Scan Type" there is the message: "Failed to open the card" instead of the choices "Full Scan" etc. I think this message comes from the webapp itself and not from the C++ code. Any hint on how to debug this?

billmeek commented 1 year ago

I'm light years behind, but it comes from here:

html/assets/i18n/en_US.json:

"erroropen": "Failed to open the card",

And it's used in the default case here:

html/backend/src/app/config/settings/input-connections/channelscan/channelscan.component.ts:

this.scanTypes.push({ label: 'settings.channelscan.type.erroropen', value: 'ERROR' });

DVBC exists in a case above, but not DVB-C. That's as far as I got.

-- Bill

bennettpeter commented 1 year ago

The error "Failed top open the card" occurs when it gets ERROR_OPEN or a value that it does not recognize for InputType from the API Call:

http://backend:6744/Capture/GetCardSubType?CardId=81

If you run this on a browser you should see something like this

<CardSubType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" serializerVersion="1.1" version="1.0">
<CardId>81</CardId>
<SubType>ATSC</SubType>
<InputType>ATSC</InputType>
<HDHRdoesDVBC>false</HDHRdoesDVBC>
<HDHRdoesDVB>false</HDHRdoesDVB>
</CardSubType>

The web app looks at the InputType value and the HDHRdoes values to determine the list of scan types for channel scan.

For example, if I unplug my DVB device, that call gives me this, and I get the failed to open error.

<CardSubType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" serializerVersion="1.1" version="1.0">
<CardId>81</CardId>
<SubType>ERROR_OPEN</SubType>
<InputType>ERROR_OPEN</InputType>
<HDHRdoesDVBC>false</HDHRdoesDVBC>
<HDHRdoesDVB>false</HDHRdoesDVB>
</CardSubType>

Please try that on a browser with your card id and let me know what you see.

kmdewaal commented 1 year ago

This is the result from my DVB-C card:

<CardSubType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" serializerVersion="1.1" version="1.0">
<CardId>127</CardId>
<SubType>QAM</SubType>
<InputType>DVBC</InputType>
<HDHRdoesDVBC>false</HDHRdoesDVBC>
<HDHRdoesDVB>false</HDHRdoesDVB>
</CardSubType>
bennettpeter commented 1 year ago

https://github.com/MythTV/mythtv/issues/239#issuecomment-1595814795 That should be OK. The code handles InputType 'DVBC' and should give 5 scan type options. Please can you try with Chrome: Press Control-shift-i Click the Network Tab Refresh the browser Open the inout connections for the card and the "scan for channels" panel There should be a list of API calls in the network tab Click the one labeled GetCardSubType?cardid=nn Check it has the correct cardid Click the Response tab You should see this

{
    "CardSubType": {
        "CardId": 81,
        "SubType": "QAM",
        "InputType": "DVBC",
        "HDHRdoesDVBC": false,
        "HDHRdoesDVB": false
    }
}

Scan Type should have 5 entries in the drop down list.

kmdewaal commented 1 year ago

The Response tab has this:

{
    "CardSubType": {
        "CardId": 127,
        "SubType": "ERROR_OPEN",
        "InputType": "ERROR_OPEN",
        "HDHRdoesDVBC": false,
        "HDHRdoesDVB": false
    }
}

Considering this might be related to EIT I did disable active EIT scanning for this capture card but that did not make a difference. Just the URL http://modu:6744/Capture/GetCardSubType?CardId=127 still gives the correct response.

<CardSubType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" serializerVersion="1.1" version="1.0">
<CardId>127</CardId>
<SubType>QAM</SubType>
<InputType>DVBC</InputType>
<HDHRdoesDVBC>false</HDHRdoesDVBC>
<HDHRdoesDVB>false</HDHRdoesDVB>
</CardSubType>

This is the error message:

2023-06-17 23:57:04.565318 E [6008/6141] HTTP3 cardutil.cpp:1278:OpenVideoDevice  CardUtil: Can't open DVB frontend (/dev/dvb/adapter11/frontend0) for /dev/dvb/adapter11/frontend0.
            eno: Device or resource busy (16

This is the backtrace from the webapp:

(gdb) bt
#0  CardUtil::OpenVideoDevice(QString const&) (device=...) at cardutil.cpp:1273
#1  0x00007f5728a4c860 in CardUtil::ProbeDeliverySystems(QString const&) (device=...) at cardutil.cpp:640
#2  0x0000000000637c45 in V2Capture::GetCaptureDeviceList(QString const&) (CardType=...) at servicesv2/v2capture.cpp:664
#3  0x000000000069f7d7 in V2Capture::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)
    (_o=0x7f562803b950, _c=QMetaObject::InvokeMetaMethod, _id=16, _a=0x7f56ffffda10) at moc/moc_v2capture.cpp:335
#4  0x00000000006a00c0 in V2Capture::qt_metacall(QMetaObject::Call, int, void**) (this=0x7f562803b950, _c=QMetaObject::InvokeMetaMethod, _id=16, _a=0x7f56ffffda10)
    at moc/moc_v2capture.cpp:396
#5  0x00007f5728448e90 in MythHTTPService::HTTPRequest(std::shared_ptr<MythHTTPRequest> const&)
    (this=0x7f562803b950, Request=std::shared_ptr<MythHTTPRequest> (use count 2, weak count 0) = {...}) at http/mythhttpservice.cpp:129
#6  0x00007f572840f5b3 in MythHTTPSocket::Read() (this=0x7f562800e540) at http/mythhttpsocket.cpp:299
#7  0x00007f5728419924 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (MythHTTPSocket::*)()>::call(void (MythHTTPSocket::*)(), MythHTTPSocket*, void**) (f=(void (MythHTTPSocket::*)(MythHTTPSocket * const)) 0x7f572840ec80 <MythHTTPSocket::Read()>, o=0x7f562800e540, arg=0x7f56ffffe3a0)
    at /usr/include/qt5/QtCore/qobjectdefs_impl.h:152
#8  0x00007f5728418aa3 in QtPrivate::FunctionPointer<void (MythHTTPSocket::*)()>::call<QtPrivate::List<>, void>(void (MythHTTPSocket::*)(), MythHTTPSocket*, void**)
    (f=(void (MythHTTPSocket::*)(MythHTTPSocket * const)) 0x7f572840ec80 <MythHTTPSocket::Read()>, o=0x7f562800e540, arg=0x7f56ffffe3a0)
    at /usr/include/qt5/QtCore/qobjectdefs_impl.h:185
#9  0x00007f5728417149 in QtPrivate::QSlotObject<void (MythHTTPSocket::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*)
    (which=1, this_=0x7f5628049750, r=0x7f562800e540, a=0x7f56ffffe3a0, ret=0x0) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:418
#10 0x00007f5726ee8461 in void doActivate<false>(QObject*, int, void**) () at /lib64/libQt5Core.so.5
#11 0x00007f572774a07f in QAbstractSocketPrivate::canReadNotification() () at /lib64/libQt5Network.so.5
#12 0x00007f5727760889 in QReadNotifier::event(QEvent*) () at /lib64/libQt5Network.so.5
#13 0x00007f5726eb416b in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#14 0x00007f5726f071af in socketNotifierSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5Core.so.5
#15 0x00007f572271339c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#16 0x00007f5722771438 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#17 0x00007f5722710a23 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#18 0x00007f5726f06729 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#19 0x00007f5726eb2b4b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#20 0x00007f5726cf45b0 in QThread::exec() () at /lib64/libQt5Core.so.5
#21 0x00007f572825ee3d in MThreadInternal::exec() (this=0x7f5640024a00) at mthread.cpp:84
#22 0x00007f572825e3f4 in MThread::exec() (this=0x7f5640002f10) at mthread.cpp:327
#23 0x00007f5728409d98 in MythHTTPThread::run() (this=0x7f5640002f10) at http/mythhttpthread.cpp:30
#24 0x00007f572825eda3 in MThreadInternal::run() (this=0x7f5640024a00) at mthread.cpp:78
#25 0x00007f5726cf59bd in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5
#26 0x00007f57266ae907 in start_thread (arg=<optimized out>) at pthread_create.c:444
#27 0x00007f5726734870 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) 

BUT.... after making this backtrace, cut&paste etc, I then continued the backend (needed to do that a few times) and then the drop down list did appear! Could it be a timing issue?

bennettpeter commented 1 year ago

OK I think I know what the problem is. There is a GetCaptureDeviceList call issued, and then a GetCardSubType call for the scan. I had the problem of it being in use for the second call, so I added a 1 second delay. That solved it for me. Probably that is not enough, or maybe I need to do it differently.

jfabernathy commented 1 year ago

I see the device busy as well, but not sure if it caused me any issues. I just upgraded my Main backend to v34(master) and it's working fine. I just finished deleting all the channels and tuners and re-adding them just like I did on my HDHR test system. I used only the web app and everything appeared as expected during the process. But when you check the log I see some errors related to device busy. This is a Hauppauge WinTV quadHD ATSC 1.0 PCIe card.

log.txt

[extra text deleted]

bennettpeter commented 1 year ago

I have pushed a fix for the device busy error. The code will wait until GetCaptureDeviceList has returned before calling GetCardSubType. Previously it would call GetCardSubType after 1 second. If you have a lot of DVB devices or the device is slow, it could still be in use.

Note that I have made changes to stop EIT scanning (as well as stopping the scheduler) when you "Enable Updates". I am unable to test that since I do not have an EIT scan ability. If you notice EIT scanning is still happening when you have enabled updates, we will have to fix it.

jfabernathy commented 1 year ago

Just rebuilt on my system with the HDHR tuners and set it up with EIT OTA Video Source only. The first 2 tuners had the active scan turned on and the last 2 did not. The setup was normal and the only log items tagged with a "E" was related to program overlap.

Jun 18 10:34:18 debian-mythtv mythbackend[683]: mythbackend[683]: E EIT programdata.cpp:621 (GetMatch) Unexpected result: shows don't overlap Anne Boleyn: Arrest, Trial, Executi: 2023-06-18T16:30:55Z - 2023-06-18T17:16:08Z UNC-EX Programming: 2023-06-18T17:16:08Z - 2023-06-18T17:16:08Z Jun 18 10:34:30 debian-mythtv mythbackend[683]: mythbackend[683]: E EIT programdata.cpp:621 (GetMatch) Unexpected result: shows don't overlap Midsomer Murders: 2023-06-18T22:00:05Z - 2023-06-18T22:41:41Z PBS NC Programming: 2023-06-18T22:41:41Z - 2023-06-18T22:41:41Z Jun 18 10:34:32 debian-mythtv mythbackend[683]: mythbackend[683]: E EIT programdata.cpp:621 (GetMatch) Unexpected result: shows don't overlap My Home, NC Shorts: 2023-06-18T23:49:41Z - 2023-06-18T23:59:59Z PBS NC Programming: 2023-06-18T23:49:41Z - 2023-06-18T23:49:41Z

I can't change my system with PCIe tuner card at this time. But I can rescan with SD as the video source.

bennettpeter commented 1 year ago

Can you tell if EIT scanning stops when you "Enable Updates" in web setup?

jfabernathy commented 1 year ago

maybe this complete mythtv-backend.service log since the reboot after I rebuilt the latest will give you the details you want. If not let me know. This is from the HDHR ATSC OTA EIT system. I did the setup with webapp immediately after reboot.

log.txt

jfabernathy commented 1 year ago

I did get an error on the latest EIT only system when I went to the program guide to select a program to record this after noon. When I tried to save it I got:

Jun 18 11:44:53 debian-mythtv mythbackend[683]: mythbackend[683]: E HTTP7 mythhttpservice.cpp:138 (HTTPRequest) Service Exception: Invalid duration.

EDIT: This was for a Golf match that runs from 1PM to 10PM today.
I could setup to record the 12:30 to 4pm F1 race today without error.

Using mythfrontend I could setup to record the Golf so it's a webapp issue

I went to the webapp on my main backend and it was already set to record the golf so I deleted that recording schedule and saved, then using webapp I requested to record it. This time it worked but this is a Schedules Direct XMLTV system.

kmdewaal commented 1 year ago

The dropdown list for Scan Type now appears, this is OK. Tested the "Full Scan (Tuned)" but this does not work. The tuning parameters appear to be passed along OK and the tuning succeeds but there is no lock or there is but it is not detected. For comparison I did start the same scan on mythtv-setup and on webapp/mythbackend.

The relevant part of the log of mythtv-setup:

2023-06-18 19:47:15.182868 I [7065/7410] Scanner channelscan_sm.cpp:2001:run  ChannelScanSM[127]: run -- begin
2023-06-18 19:47:15.182880 I [7065/7410] Scanner channelscan_sm.cpp:2245:ScanTransport  ChannelScanSM[127]: ScanTransport Tuning to Frequency 474000000 mplexid(0)
2023-06-18 19:47:15.182898 I [7065/7410] Scanner dvbchannel.cpp:812:Tune  DVBChan[127](/dev/dvb/adapter11/frontend0): Tuning parameters:
2023-06-18 19:47:15.182914 I [7065/7410] Scanner dvbchannel.cpp:813:Tune      Old: 0 auto a 0 auto auto a a auto a v fec:auto msys:UNDEFINED ro:0.35
2023-06-18 19:47:15.182919 I [7065/7410] Scanner dvbchannel.cpp:814:Tune      New: 474000000 qam_64 a 6875000 auto auto a a auto a v fec:auto msys:DVB-C/A ro:0.35
2023-06-18 19:47:15.182921 I [7065/7410] Scanner dvbchannel.cpp:824:Tune  DVBChan[127](/dev/dvb/adapter11/frontend0): Tune(): Tuning to 474000000Hz
2023-06-18 19:47:15.182932 I [7065/7410] Scanner dvbchannel.cpp:1821:dtvmultiplex_to_dtvproperties  DVBChan[127]: Delivery system: DVB-C/A
2023-06-18 19:47:15.182947 I [7065/7410] Scanner dvbchannel.cpp:975:Tune  DVBChan[127](/dev/dvb/adapter11/frontend0): Tune(): Frequency tuning successful
2023-06-18 19:47:15.182980 I [7065/7410] Scanner dtvsignalmonitor.cpp:198:SetChannel  DTVSigMon[127]: SetChannel(-1, -1) 
2023-06-18 19:47:15.182984 I [7065/7410] Scanner dtvsignalmonitor.cpp:231:SetDVBService  DTVSigMon[127]: SetDVBService(transport_id: 0, network_id: 0, service_id: -1) 
2023-06-18 19:47:15.258259 I [7065/7411] SignalMonitor dvbsignalmonitor.cpp:379:UpdateValues  DVBSigMon[127](/dev/dvb/adapter11/frontend0): UpdateValues -- Signal Locked
2023-06-18 19:47:15.258322 I [7065/7411] SignalMonitor streamhandler.cpp:42:AddListener  SH[127]: AddListener(0x1e22dc8) -- begin
2023-06-18 19:47:15.258330 I [7065/7411] SignalMonitor streamhandler.cpp:54:AddListener  SH[127]: AddListener(0x1e22dc8) -- locked
2023-06-18 19:47:15.358700 I [7065/7411] SignalMonitor streamhandler.cpp:76:AddListener  SH[127]: AddListener(0x1e22dc8) -- end 
2023-06-18 19:47:15.441068 I [7065/7420] DVBRead channelscan_sm.cpp:402:HandleCAT  ChannelScanSM[127]: Got a Conditional Access Table for Frequency 474000000
2023-06-18 19:47:15.441327 I [7065/7420] DVBRead channelscan_sm.cpp:583:HandleSDTo  ChannelScanSM[127]: Got a Service Description Table (other) for Transport ID 2059 section 0/0 
:

The relevant part in the mythbackend log:

2023-06-18 19:05:44.805235 I [11618/11952] Scanner channelscan_sm.cpp:2001:run  ChannelScanSM[127]: run -- begin
2023-06-18 19:05:44.805245 I [11618/11952] Scanner channelscan_sm.cpp:2245:ScanTransport  ChannelScanSM[127]: ScanTransport Tuning to Frequency 474000000 mplexid(0)
2023-06-18 19:05:44.805253 I [11618/11952] Scanner dvbchannel.cpp:812:Tune  DVBChan[127](/dev/dvb/adapter11/frontend0): Tuning parameters:
2023-06-18 19:05:44.805260 I [11618/11952] Scanner dvbchannel.cpp:813:Tune      Old: 0 auto a 0 auto auto a a auto a v fec:auto msys:UNDEFINED ro:0.35
2023-06-18 19:05:44.805260 I [11618/11948] ScanMonitor channelscanner_web.cpp:519:HandleEvent  ChScanWeb:   0% S/N 0 L : Scanning... Frequency 474000000 (Scanning... Frequency 474000000)
2023-06-18 19:05:44.805264 I [11618/11952] Scanner dvbchannel.cpp:814:Tune      New: 474000000 qam_64 a 6875000 auto auto a a auto a v fec:auto msys:DVB-C/A ro:0.35
2023-06-18 19:05:44.805267 I [11618/11952] Scanner dvbchannel.cpp:824:Tune  DVBChan[127](/dev/dvb/adapter11/frontend0): Tune(): Tuning to 474000000Hz
2023-06-18 19:05:44.805272 I [11618/11952] Scanner dvbchannel.cpp:1821:dtvmultiplex_to_dtvproperties  DVBChan[127]: Delivery system: DVB-C/A
2023-06-18 19:05:44.849611 I [11618/11952] Scanner dvbchannel.cpp:975:Tune  DVBChan[127](/dev/dvb/adapter11/frontend0): Tune(): Frequency tuning successful
2023-06-18 19:05:44.849665 I [11618/11952] Scanner dtvsignalmonitor.cpp:198:SetChannel  DTVSigMon[127]: SetChannel(-1, -1)
2023-06-18 19:05:44.849675 I [11618/11952] Scanner dtvsignalmonitor.cpp:231:SetDVBService  DTVSigMon[127]: SetDVBService(transport_id: 0, network_id: 0, service_id: -1)
2023-06-18 19:05:44.861964 I [11618/11948] ScanMonitor channelscanner_web.cpp:519:HandleEvent  ChScanWeb:   0% S/N 0 L : Scanning... Frequency 474000000 ()
2023-06-18 19:05:44.862004 I [11618/11948] ScanMonitor channelscanner_web.cpp:519:HandleEvent  ChScanWeb:   0% S/N 81 L : Scanning... Frequency 474000000 ()
2023-06-18 19:05:44.899523 I [11618/11953] SignalMonitor dvbsignalmonitor.cpp:379:UpdateValues  DVBSigMon[127](/dev/dvb/adapter11/frontend0): UpdateValues -- Signal Locked
2023-06-18 19:05:44.899574 I [11618/11953] SignalMonitor streamhandler.cpp:42:AddListener  SH[127]: AddListener(0x7f5dc001ce88) -- begin
2023-06-18 19:05:44.899582 I [11618/11953] SignalMonitor streamhandler.cpp:54:AddListener  SH[127]: AddListener(0x7f5dc001ce88) -- locked
2023-06-18 19:05:44.899714 I [11618/11948] ScanMonitor channelscanner_web.cpp:519:HandleEvent  ChScanWeb:   0% S/N 81 l : Scanning... Frequency 474000000 ()
2023-06-18 19:05:44.899740 I [11618/11948] ScanMonitor channelscanner_web.cpp:519:HandleEvent  ChScanWeb:   0% S/N 96 l : Scanning... Frequency 474000000 ()
2023-06-18 19:05:44.999895 I [11618/11953] SignalMonitor streamhandler.cpp:76:AddListener  SH[127]: AddListener(0x7f5dc001ce88) -- end
2023-06-18 19:05:51.852526 I [11618/11952] Scanner channelscan_sm.cpp:993:UpdateChannelInfo  ChannelScanSM[127]: transport_tune_complete: wait_until_complete 0
2023-06-18 19:05:51.852599 I [11618/11952] Scanner channelscan_sm.cpp:1135:UpdateChannelInfo  ChannelScanSM[127]: Frequency 474000000 -- Timed Out, no channels

Maybe the new ScanMonitor which is present in mythbackend but not in mythtv-setup does interfere with the still existing SignalMonitor?

bennettpeter commented 1 year ago

https://github.com/MythTV/mythtv/issues/239#issuecomment-1596187967 Invalid Duration: MythTV does not accept any recording of more than 8 hours. As far as I know, schedules direct will split it into two programs if it is more than that. I will look into whether I can get it to report the error back instead of just Backend Network Failure.

jfabernathy commented 1 year ago

This makes sense. The error occurred when using a OTA EIT schedule for 1pm to 10pm (9hrs). When I looked at the equivalent setup on a SD program schedule it had 1 to 9PM and same name program 9-10pm. I didn't have that one hour set to record, but I could set it so I get the whole thing.

Since I use SD on my production backend, then I'd just need to remember to record the second part of any program longer than 8 hours. Having a better error explanation would be better for the EIT 8 hour programs. I don't think this will be a common problem except for Olympics or other major sporting events.

bennettpeter commented 1 year ago

https://github.com/MythTV/mythtv/issues/239#issuecomment-1596231208 Full scan (tuned) requires that you enter a frequency and other details. Is this useful, and do MythTV users need it? I don't understand why full scan would work but the tuned option would not, if the same parameters are used.

kmdewaal commented 1 year ago

Good questions.

You need "Full Scan (Tuned)" for European cable (DVB-C) and satellite (DVB-S/S2). For ATSC and European terrestrial (DVB-T/T2) the "Full Scan" is used. I think the "Full Scan" will thus cover the majority of the MythTV users.

About what works and what does not work. The HDHomeRun does work with "Full Scan" on DVB-T2 and with "Full Scan (Tuned)" on DVB-C. The SatIP does work with "Full Scan (Tuned)" on satellite and I expect that SatIP will also work with DVB-T/T2 and DVB-S/S2 given the nature of the protocol. What does NOT work is the "Full Scan (Tuned)"on DVB-C on a /dev/dvb/... type of tuner. The problem seems to be that the signal monitor does not notice that the tuner has locked. I expect that the "Full Scan" also does not work.

If you are happy for now with supporting the network tuners and leave the /dev/dvb tuners for later then that is not yet a problem, for the time being I expect to keep mythtv-setup working.

jfabernathy commented 1 year ago

I was just testing the latest pull that contains the webapp update for allowing UserJobs to be scheduled on the Recording tab. It works on triggering a Commflag run and for triggering my own user job.

One small display issue on the Dashboard. Under Job Queue it's not picking up the user job name on actual user jobs that the user created. 2023-06-21T14:32:06Z - S.W.A.T. - Commflag - Status: Finished

2023-06-21T14:53:03Z - S.W.A.T. - Unknown - Status: Queued

2023-06-21T14:53:15Z - S.W.A.T. - Unknown - Status: Running

On the setup Job Queue (Job Commands) page the entered User Job 1 Description is:

send TV to NAS

kmdewaal commented 1 year ago

With a rebooted system and rebuilt software I did just try the DVB-C "Full Scan (Tuned)" on a /dev/dvb/ capture card again and now it works OK.

kmdewaal commented 1 year ago

Feature Request: default values for "Full Scan (Tuned)" parameters.

In the Video source you can define a Scan Frequency parameter (see https://www.mythtv.org/wiki/Channel_Scanning#Scan_Frequency). In mythtv-setup, this frequency is used as default for the "Full Scan (Tuned)". And, if there is already a transport present for that video source with this frequency then all tuning parameters of that multiplex are used as default in the GUI. This is extremely convenient, as this means that for a given video source you do need to enter the parameters only once. The source code used in mythtv-setup is in channelscan/scanwizardconfig:139 function SetPaneDefaults.

bennettpeter commented 1 year ago

Feature Request: default values for "Full Scan (Tuned)" parameters.

https://github.com/MythTV/mythtv/issues/239#issuecomment-1610208299 I have made the requested change. Note that the default frequency is set when you select the scan type. If, after selecting the scan type, you go up on the page and change the video source, the frequency will not change to the default for the new video source. Also, there is a validation on the frequency of 0 to 999,999,999. Let me know if that is not high enough.

jfabernathy commented 1 year ago

I've started noticing that metadata lookup jobs are now failing after a recording. I now how 3 recordings on my test system with that error. I tired to re-queue all three and they failed again. I've attached what little log info I could find: metadata-lookup.log

jfabernathy commented 1 year ago

On a clean build of a VM with EndeavourOS (Archlinux) I built the backend and frontend using a modified PKGBUILD of the AUR mythtv-git package. It was modified to build master. It is running but I could not do HDHomeRun Channel Import. I had to do Full Scan. What was different this build was on Capture cards I checked on both of the HDHR tuners it found. In the past I only checked on 1 of the 2. I went back I unchecked one of the tuners and Channel Import worked. However I got double channels. one for 4.1 and the duplicate was 4_1. I think this is fixable by deleting all channels and just either importing them or full scan and no mix and match.

kmdewaal commented 1 year ago

About channel scanning and channel editing. After this is done, and just before the backend is restarted, please call

ChannelGroup::UpdateChannelGroups();

This is about the "automatic channel groups" feature; if there is more than one video source then there is automatically a channel group created for each video source. The channel groups must be updated after a scan is done or after channel editing so that the channel groups do have the correct channels. This is done in mythtv-setup.cpp line 599, just before it exits from main.

bennettpeter commented 1 year ago

Is it correct that UpdateChannelGroups should be called after a channel or channels are added only? Should it be called after channels are deleted? After channels are updated?

It is not easy to make it call UpdateChannelGroups after the scan, because the user could get part way through the scan then close browser or restart before getting to the final prompt of scan complete. So I will have to call it after each stage of t he scan where channels were updated, added or deleted.

For the channel editor it will have to call UpdateChannelGroups after every add, delete or update because there is no way to know they exited the page.

kmdewaal commented 1 year ago

I think it is best to call UpdateChannelGroups just before restarting the backend. Calling it after every add, delete or update is not needed.

When this feature was implemented it was also considered to do it on every start of the backend but after discussions it was decided it was best to do it at the exit of mythtv-setup. In the webapp you have to stop the backend, then do all the changes you want including channel scans and then restart the backend. Calling UpdateChannelGroups once just before restarting the backend is thus the perfect moment and is roughly equivalent to what happens in mythtv-setup.

bennettpeter commented 1 year ago

I can do that, but there is a risk that they restart the backend manually or with systemctl restart, in which case it would not be called. Also there is the ability to add or modify channels with channel editor in the dashboard section of the web app, where the scheduler does not have to be disabled, so there would be no restart.

kmdewaal commented 1 year ago

I can do that, but there is a risk that they restart the backend manually or with systemctl restart, in which case it would not be called.

You do have a point here. We can do the UpdateChannelGroups also in the mythbackend startup, that would cover this. It would increase the startup time by 2 seconds or so and that is completely OK with me (but maybe not with @gigem ).

Also there is the ability to add or modify channels with channel editor in the dashboard section of the web app, where the scheduler does not have to be disabled, so there would be no restart.

This is true, but that would then be fixed whenever the backend is restarted. Which is good enough for me.

bennettpeter commented 1 year ago

I have added the UpdateChannelGroups. See 307b3efdd5

jfabernathy commented 1 year ago

For some reason after the recent changes with port numbers and maybe something else, Kodi's pvr-mythtv has stopped connecting to my backend. It worked early on the testing of v34 with the new web app but now I can't get it to connect. It mentions PIN code not configured and some other things. My kodi setup for pvr-mythtv is still the same as it was when installed.

billmeek commented 1 year ago

My issue too. The backend log says it's listening on 6544, but netstat/nmap tools don't show it. There is a failure on port 6554 in the log below.

Ubuntu 22.04, Qt5, with and without the --disable-qtwebkits and --disable-qtscript switches.

More tests/data/logs: https://pastebin.com/raw/R3hZekYg

bennettpeter commented 1 year ago

It seems that 6550 was not a good choice for the backend upnp service, because that also opens 6554 for SSL, but 6554 is already used for other purposes. I will fix it

bennettpeter commented 1 year ago

I fixed the two bugs in commit dc6fb82500.

Kodi now connects but fails to add channels or program guide. Recordings work with Kodi.

At the moment, temporarily, the old server is still available on port 6550, so Kodi works fully with channels and guides if you specify port 6550 as the status port.

I shall open an issue with the Kodi mythtv plugin developer for the channel problem.

bennettpeter commented 1 year ago

Before I log a bug with the Kodi Mythtv plugin, please can you try Kodi with the latest master and status port 6544 and let me know if you also have the problem with channels and guide not showing in Kodi

jfabernathy commented 1 year ago

I can test later today.

jfabernathy commented 1 year ago

So the only way I can get Kodi to connect is with these settings: Mythtv Backend Port 6543 API servcices Port 6544

FYI (34.0 master.202307251604.dc6fb82500~ubuntu22.04.1)

Both Guide and Channels are empty

bennettpeter commented 1 year ago

I opened issue https://github.com/janbar/pvr.mythtv/issues/209 for Kodi MythTV plugin