Closed stuarta closed 11 months 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.
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"
.
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:
...
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...
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.
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.
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.
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.
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.
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.
When I compiled I did hear the police sirens in the distance. :-)
I fixed the compiler warnings by adding a default: to the switch statement.
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?
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
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.
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>
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.
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?
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.
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.
[extra text deleted]
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.
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.
Can you tell if EIT scanning stops when you "Enable Updates" in web setup?
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
I have added the UpdateChannelGroups. See 307b3efdd5
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.
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
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
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.
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
I can test later today.
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
I opened issue https://github.com/janbar/pvr.mythtv/issues/209 for Kodi MythTV plugin
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
--noupnp
is used to disable upnp