Tuners no longer able to get a channel lock #1071

briggella · 2025-04-17T20:11:45Z

Platform: Ubuntu 24.04.2 LTS
MythTV version: v34.0
Package version:v34.0+fixes.202504131949.a473f5e2d7~ubuntu24.04.1
Component: mythbuntu-ubuntu-34-noble.sources

What steps will reproduce the bug?

About 3 days ago my installations 3 tuners all failed to record any programs. When trying to watch live TV they all failed to achieve Tuner lock. They have done that ever since. I have checked the cables and hardware but my satellite box for freeview is working fine coming off the same connections. The signal is split four ways via a digital 4 way splitter here including the freeview satellite box to my TV which is still working.

https://digitalimports.co.nz/product/digital-distrubution-module-4-way/

I note from the web setup interface that the database is reported to be 1379 and seems to be highlighted as a problem, though I can connect to it.

I found out that the Optus satellite was changed at the same time as this problem occurred with a new satellite called Korea sat 6 but the new satellite was moved into the same location. I have tried to retune my channels file and I detect lots more channels but they are not saved.

How often does it reproduce? Is there a required condition?

This is a now permanent condition

What is the expected behaviour?

mythbackend.log

backend.log attached

What do you see instead?

Additional information

briggella · 2025-04-17T21:09:15Z

Last successful recording was 14th April 8:45pm

kmdewaal · 2025-04-17T21:12:07Z

Currently my best guess is that this is caused by the change of the satellite. I think the database version is OK, the highlighting is part of the webgui and in this case I think it does not indicate a problem.

Can you try the following:

create a new video source
connect all satellite capture cards to that video source
do a channel scan
and then see if it now works?

linuxdude42 · 2025-04-17T22:11:26Z

I noticed a similar error my HDHomeRun last night, after having upgrading my backend last week. Some cable channels would tune, others timed out after 10 seconds. What I would see in the OSD is that the letters "TLAM_" would show up, but it would never put the 'C' at the end. I know those are the tuning states, but I don't know what they stand for off the top of my head. I ended up having to revert my production backend to its previous version (almost a year old).

I was able to recreate the problem in my testbed last night, and the problem was definitely in MythTV because vlc could play the problem channel when MythTV couldn't. It was also rock solid which channels MythTV would tune and which wouldn't. This morning I tried to bisect the code to find the problem, but its gone away. I can now play the problem channels while running the latest code. Arrrgh. When it was happening it was very consistent which channels would tune and which wouldn't. I'm going to try and recreate the problem again whenever I can find the time.

briggella · 2025-04-18T02:11:03Z

I have run a channelscan with a new video source and it found 32 channels. Once finished I saved it but my vidoe source was empty as it appeared not to ahve saved anything. It does this everytime. I am also unable to update the old video source. I attach the latest Mythbackend log and the mythconverg files list relating to channels so you can see which ones are updating and which ones are not.

mythbackend2.log

mythconverg.channels.txt

kmdewaal · 2025-04-18T06:37:07Z

There are some interesting messages in the backend log....

Can you try the following:

stop mythbackend
do a scan with classic/deprecated mythtv-setup
post the log file

briggella · 2025-04-18T10:46:12Z

Scan with mythtv-setup

performed at 22:38 on 18/4/25
using video source freesat2 instead of freesat.

mythbackend3.log

kmdewaal · 2025-04-18T18:52:45Z

From the backend log it looks like the database is in a strange state.
It does look like the capture cards are not connected to a video source. But, if that is true then you should not find any channel at all during the channel scan.
To figure this out, it is necessary to know what is in the tables capturecard and videosource.

First step is logging into mysql with the following command:

klaas@kasus:~$ mysql -u mythtv -p mythconverg
Enter password: 
Reading table information for completion of table and column names
....
MariaDB [mythconverg]>

Then the important columns of capturecard:
MariaDB [mythconverg]> select cardid,parentid,videodevice,cardtype,sourceid,hostname,startchan from capturecard;

Then everything from videosource:
MariaDB [mythconverg]> select * from videosource;

About scanning for channels with the classic (also known as deprecated) mythtv-setup. The output of mythtv-setup is not written to the backend log file (as far as I know) but can be captured separately.
Please do start mythtv-setup from the command line with the debug options and capture the output in a log file.
Like this:
klaas@kasus:~$ mythtv-setup -v general,eit,channel,chanscan,siparser 2>&1 | tee ms-20250418.log

Please note that mythbackend must be stopped (this means not running at all) before you can start mythtv-setup.

briggella · 2025-04-18T21:12:22Z

Ok files attached for mythconverg query.
when running the channe;l scan, I noticed that at the end the logfiles were empty. I ran it twice with the same result. I have found a mythtv-setup.log which I attach. On one run the system ground to a halt and had to be forcibly terminated.

mythconverg_rpt.txt

mythtv-setup.log

briggella · 2025-04-20T05:17:32Z

Run today in debug mode, entries dated 20/4/25.

Don't know why it won't write to a log via command line.

mythtv-setup2.log

kmdewaal · 2025-04-20T21:59:17Z

Thanks for the logs, very useful.

I think that your first problem, tuners no longer able to get a channel lock, has been caused by the change to a new satellite. In MythTV this requires a new channel scan. The new channel scan fails and that is now the problem. Your problem could be a duplicate of #1070 but there is a separate investigation done on that issue and we are following different paths.

The log does show two errors:

It scans only a few frequencies, repeating a scan of the same frequencies over and over again. After the first frequency it should continue with the second etc and that does not work.
The channels that it does find in the scan do not have logical channel numbers. This is why they are discarded and this is why you do not get any channels at all at the end of the scan.

The next thing to do now is to do the scan again but then with the option "Logical Channel Numbers required' unchecked.
You then should get at least a few channels (at least Al Jazeera) that you can actually use, although they will have unusual channel numbers.

Please do the scan again with classic mythtv-setup and do log the output again.

N.B. In Ubuntu the mythtv-setup is actually a shell script which starts a binary called mythtv-setup.real
This is why there is only output in the standard log file and not as output of the command line.
I think you can, when mythbackend is stopped, start mythtv-setup.real directly on the commandline, like this:
klaas@kasus:~$ mythtv-setup.real -v general,eit,channel,chanscan,siparser 2>&1 | tee ms-20250420.log
This is for me the preferred log file format.

briggella · 2025-04-21T01:54:03Z

Done with new command. Log is now populated. Scan initially failed as all the transport data had been wiped. Worked after I entered one transport..

ms-20250420.log

kmdewaal · 2025-04-21T07:10:52Z

Thanks for the log. The problem looks to be the same as that of #1070. The good news is that it looks like the bug has been found in #1070. When the fix has been committed and propagated into the packages then please update and try again.

Revert a change done in commit 80ebec6 where the character representing channel polarity ('H' or 'h' or 'V' or 'v') was changed into the numerical value of the character. Refs #1070 Refs #1071

kmdewaal · 2025-04-21T09:24:07Z

Please note that the fix has for now only been committed to master. After some time it will be backported to v35 and v34.

briggella · 2025-04-21T10:10:50Z

Is there anything I can do in the meantime in case it is a long time before it is backported?

kmdewaal · 2025-04-21T10:27:47Z

I intend to do the backport late today or tomorrow after our American friends have had a chance to have a look at it.

If you are really in a hurry then you can do the following:

upgrade to master and wait until the repository is updated
build master from source
build v34 from source and apply the fix before building

briggella · 2025-04-21T10:36:57Z

A couple of days is brilliant. Sounded like it would be much longer. Thank you for your help. I will await the backport.

linuxdude42 · 2025-04-21T19:38:41Z

This fix passes my suite of ~50 builds. (I figured it would pass, but I specifically wanted to test the Qt6.9 build and it was easier to just started the whole suite.)

My apologies for introducing the problem when I was fixing Qt6.9 build failures.

kmdewaal · 2025-04-21T19:43:49Z

OK, thanks for looking at it right away. And yes, things do happen... Will backport now to v35 and v34.

Revert a change done in commit 80ebec6 where the character representing channel polarity ('H' or 'h' or 'V' or 'v') was changed into the numerical value of the character. Refs #1070 Refs #1071 (cherry picked from commit cf33bfb)

kmdewaal · 2025-04-21T20:19:12Z

OK issue fixed. Closing ticket now. If there is still a problem then please re-open this ticket or create a new one.

kmdewaal closed this as completed Apr 21, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tuners no longer able to get a channel lock #1071

Tuners no longer able to get a channel lock #1071

Tuners no longer able to get a channel lock #1071

Tuners no longer able to get a channel lock #1071

Comments

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behaviour?

What do you see instead?

Additional information