Bug in Scanning DVB-T2 with QAM256 in UK

Server Version#: 1.32.0.6973 Linux
Player Version#: 1.67.2.3705-db506a00
Tuner Make/Model: hauppage wintv dualhd
Guide/Lineup name: Freeview
Using XMLTV?: Yes
Channel number/Name: 101-109

Continuing the problem signled in Plex DVR tuner scan failing to detect Freeview HD channels with WinTv QuadHR that TVHeadend does detect
which still there.

I accidentally found a workaround for the UK transponder ini files that makes plex decode again the HD mux and channels.

In my case I’m using the UK Crystal Palace frequencies 4103.ini

While trying to playing around with values I mistakenly entered a wrong value in frequency #19: 19=545833,8,QAM256

This syntax error (too many commas) made the frequency 545833 not being scanned anymore but now 546000 is not failing to tune anymore returning the missing LCNs for the HD channels.

Failed scan log with stock ini transponder: May 01, 2023 23:11:01.726 [0x7fc86912ab38] INFO - [I] web_service_t::process_get - Pastebin.com

Good scan log with modified ini transponder: May 01, 2023 23:24:03.033 [0x7fc869841b38] INFO - [I] web_service_t::process_g - Pastebin.com
The modified ini transponder (with bad syntax): [SATTYPE]1=41032=DVB-T/T2 UK (Crystal Palace)3=GB[DVB]0=271=481833 - Pastebin.com

I’ve rescanned multiple times and it seems that the workaround is consistently working, you can see that in the good scan logs the frequence 546000 is not anymore failing to scan and LCN 101,102, etc are scanned correctly

To note that 546000 is the only frequency that has DVB-T2 and QAM256 modulation in my area the other ones are DVB-T.

This information may be outdated, but the format of the .ini files used to be like this:

[SATTYPE]
1=5265
2=DVB-C Germany (Telecolumbus, Potsdam)
3=DE

[DVB]
0=24
1=122000,V,6900,,QAM256
2=130000,V,6900,,QAM256
3=138000,V,6900,,QAM256
4=146000,V,6900,,QAM256
5=162000,V,6900,,QAM256
6=306000,V,6900,,QAM64
7=314000,V,6900,,QAM256
8=354000,V,6900,,QAM64
9=362000,V,6900,,QAM64
10=370000,V,6900,,QAM64
11=378000,V,6900,,QAM64
12=386000,V,6900,,QAM64
13=394000,V,6900,,QAM64
14=402000,V,6900,,QAM256
15=410000,V,6900,,QAM64
16=418000,V,6900,,QAM256
17=426000,V,6900,,QAM64
18=466000,V,6900,,QAM256
19=642000,V,6900,,QAM256
20=650000,V,6900,,QAM256
...

line 0 indicates the number of valid transponder lines below.
then you have these data per transponder:

24 682000 V 6900 QAM256
# frequency in kHz V symbol rate omit modulation type

The V is for holding the polarization for satellite tuners. You can omit it or simply put V everywhere.
You should be able to get the symbol rates and modulation type from publicly available transponder lists for your area.

Thanks OttoKerner for the detailed answers one thing to note is that in my case I’m talking about terrestrial and not cable setup.

I found this old reference on transponder format How to make a custom transponder file - DVBLink wiki

and it seems to mention that modulation parameter is not used for terrestrial.

Anyway I’ll try to do some more tries later, the only thing I find it odd is that the 546 mhz frequency now works by just misconfiguring the previous one (545.833) which seems to hint at some bug in plex stack

I think it rather possible that the 546 mhz is just a rounded version of the correct 545,833 kHz

The differences between DVB-C and DVB-T are almost negligible. The main difference between them is the range of possible transponder frequencies.

About the frequency of the channels I found:

and

with more detail data which report the HD mux channels at 545.833 Mhz albeit scanning on the internet many people tuner just lock it in at 546.000 Mhz

I also did more tries but no ini permutation I mange to come out with actually works except the one I posted above which is very puzzling.

Some of the tries I made in the transponder.ini (all listed in the same pastebin):

Another thing visible from the logs is that no matter what parameter I pass the logs always shows:
May 01, 2023 23:24:03.122 [0x7fc8685f0b38] INFO - [I] CTVSStreamSource::TuneTransponder. Transponder tuning request: diseqc 0, freq 538000, modulation 0, polarization 0, symbol rate 0, LOF 8, LNB selection signal 0, FEC 0
May 01, 2023 23:24:03.122 [0x7fc8685f0b38] INFO - [I] Tuning request. 538000, 8, 0, 0, 0, 0, 0

so except frequency all other parameters are always 0 ( or at least the log says so)

You have renewed my faith that there may be a way to get HD channels working.
I shall see if I can do something similar to make the Sudbury transmitter work over the next few days and report back

1 Like

I had some success!! It took a bunch of tries and some experimentation, but eventually I managed to get the HD channels scanned. The automatic channel matching didn’t work, but it wasn’t a massive bother to go through and match them manually.

First of all I tried adding the exact same line as @tizia77 ( 19=545833,8,QAM256)before the frequency that wasn’t scanning (682000 KHz in my case), but that didn’t work (I did of course change the entry number to be in the correct sequence and updated line 0 to the correct new number of entries)

That made no difference. So next I tried modifying the frequency to the one I actually want (5=682000,,,8,,QAM256 in my case). That didn’t work either.

After that I tried to make a new test file with a bunch of combinations, with only the MUX for the HD Channels, and gradually added to it until I got a positive result. The test file is below:

[SATTYPE]
1=4899
2=DVB-T/T2 - UK (TEST)
3=GB

[DVB]
0=6
1=682000,,,8,,QAM256
2=682000,,,8
3=682000,,,8,,QAM256
4=682000,,,8
5=681833,,,8,,QAM256
6=682000,,,8

As you can see I got it to scan the same frequencies multiple times. However, I think it may have actually been the last 2 lines that made it work. There I used a similar config to @tizia77 - by having a frequency offset of a few hundred Hz first, followed by the correct frequency (681833 then 682000 in my case).

No idea if this is what made it work, or if it was just the sheer number of tries and retries of the same frequency that fixed it. But the end result was a successful scan of the HD channels :slight_smile:

At that point I didn’t feel like further troubleshooting, so I just combined the test file into my full transponder file, scanned the lot and called it a day. With all Muxes successfully scanned. My working file for the Sudbury transmitter is below if it helps anybody:

[SATTYPE]
1=4898
2=DVB-T/T2 - UK (Sudbury)
3=GB

[DVB]
0=11
1=682000,,,8,,QAM256
2=682000,,,8
3=682000,,,8,,QAM256
4=682000,,,8
5=681833,,,8,,QAM256
6=682000,,,8
7=658000,,,8
8=634000,,,8
9=538000,,,8
10=554000,,,8
11=602000,,,8

If I get time I’ll try setting up another plex server and see if I can narrow down the line that fixes it. It isn’t easy to test on my main server, as there is no simple way to delete channels in plex and start from scratch!

Hopefully this will be enough information for the devs to pick it up and figure out what the underlying issue is. As far as I can tell, it only effects Linux Debian builds (possibly just ARM builds). My Nvidia shield was working before with the normal full UK scan, and from my reading, Windows builds have always worked.

1 Like

About build affected I’m not on ARM, I’m on x86_64 plex docker: Docker

Ah, ok.
I’m also using docker, just in case that is relevant. I use the Linuxserver.io Plex image too, running on a Pine Rock64 host using the dietpi OS.

I had also tried the official docker images during previous testing, but they had the same issue.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.