Linux DVB-S/DVB-S2 scan problem after Proxmox reinstall

[mvallevand]

If you can't lock 12188 you won't get RTL and 11464 is useless for you. You can try 12051

Code:

[ProSiebenSat 1 Media, CHANNEL]
    DELIVERY_SYSTEM = DVBS
    FREQUENCY = 12051000
    POLARIZATION = VERTICAL
    SYMBOL_RATE = 27500000
    INNER_FEC = 3/4
    INVERSION = AUTO

If you want another frequency that should lock but again it wasn't in your original channel.conf which might be suspect.

Perhaps just download https://git.linuxtv.org/dtv-scan-tables....c9d11ffcf1 and see if dvbv5-scan works with it.

Martin

[fireball]

Hi Martin,

thanks for the suggestions. I'll test both approaches (12051 and the official dtv-scan-tables) tomorrow.

I just moved the DVB card back to my Windows machine for now – I need to physically swap it back into the Linux server first. I'll post the results here as soon as I've completed the tests.

One important note: I checked my Windows setup, and N-TV does not exist on 12188 H there either. It seems this service is not (or no longer) available on this transponder. I'll test with RTL Television or VOX instead – they are confirmed to be present on this frequency.

Just to confirm what I'll test:

12051 transponder (DVB-S, with the parameters you provided)

Official dtv-scan-tables from LinuxTV, followed by a full dvbv5-scan

If either of these works, I should get a proper lock and can provide a valid TS capture from the correct transponder.

Let me know if you have any additional instructions before I start.

Cheers,
fireball

[mvallevand]

You can also create a full mux in Windows using sub's tscapture program from tscapture.com.

If 12188 locks on Windows it is probably the most interesting.

Martin

[fireball]

Hi Martin,

thanks for the suggestion – I hadn't thought of TSCapture on Windows. That's actually a great idea.

I can confirm that 12188 H locks perfectly on Windows – I'm getting a clean signal and VOX is detected with the correct SID (12060). So the transponder itself is definitely active and working.

I'll do the full mux capture on Windows using TSCapture tomorrow and upload the file. Since Windows already locks on this transponder, this should give you exactly the data you need for analysis – without any Linux driver issues getting in the way.

My plan for tomorrow:

Capture the full mux from 12188 H on Windows (TSCapture)

Upload the TS file externally

Post the link here

This way we can confirm the transponder is fine and isolate the issue to the Linux driver/hardware combination.

If you'd prefer me to continue testing on Linux with 12051 or the official dtv-scan-tables, let me know – but I think the Windows capture will give us the cleanest result.

Cheers,
fireball

[mvallevand]

Let's simplify things and wait for the 12188H file and I can setup up a Linux test here to see if I can scan it on proxmox

Martin

[fireball]

Hi Martin,

perfect – that simplifies things.

I'll capture the full mux from 12188 H on Windows using TSCapture and upload it. I'll post the download link here tomorrow as soon as the file is ready.

Just to confirm – I'm also running Proxmox on my Linux server, so if you find something that makes a difference there, I can try to replicate it on my end.

This should give you a clean reference capture to compare against your Proxmox test.

Cheers,
fireball

[mvallevand]

Don't count on my proxmox settings for much , I use USB and for DVB-S  this is delivered through a modulator so there is no true LNB control.

Your 11464 file worked as expected.

Martin

[fireball]

Hi Martin,

I've just captured the full mux from 12188 H on Windows using TSCapture.

Mode: Full Transport Stream

Duration: ~1 minute

File size: ~265 MB

https://www.dropbox.com/scl/fi/mp6omdthc...rm4x9&dl=0

Cheers,
fireball

[mvallevand]

Thanks no issues scanning or getting the guide (ntv was there under a different name than showed on lyngsat) on proxmox Debian 13 here.

Maybe check the firmware fw files and the cabling to the LNB.  Other than that maybe create the 12188.conf that I posted in /usr/share/dvb/dvb-snd scan from it, that is what I used.

Martin

[fireball]

Hi Martin,

thanks again for your help and the detailed suggestions.

I've now checked everything you mentioned:

Firmware: The SHA256 checksum of ngene_18.fw matches a known working version:

text
213d98ec2cd575eba15d82ee79fed7098e670de43792f8aa773a95cfb7c32060
So the firmware is correct and loads without errors.

Cabling/LNB: I can rule this out as the cause – the same antenna, same cable, and the same DVB card lock perfectly when the card is installed in a Windows PC. The only difference is the operating system and driver stack. So the issue is not related to the signal path.

12188.conf approach: I tried the dvbv5-scan approach as you suggested, but it fails with:

text
FEHLER Befehl BANDWIDTH_HZ (5) während der Abfrage nicht gefunden
This is a known bug in older dvbv5-scan versions – it expects a bandwidth parameter which is not needed for DVB‑S.

12188.conf approach: I tried the dvbv5-scan approach as you suggested:

bash
cat > 12188.conf << 'EOF'
[CHANNEL]
DELIVERY_SYSTEM = DVBS
FREQUENCY = 12188000
POLARIZATION = HORIZONTAL
SYMBOL_RATE = 27500000
INNER_FEC = 3/4
INVERSION = AUTO
EOF

dvbv5-scan 12188.conf -l UNIVERSAL -o dvb_channel_12188.conf
But dvbv5-scan fails with:

text
FEHLER Befehl BANDWIDTH_HZ (5) während der Abfrage nicht gefunden
This is a known bug in older dvbv5-scan versions – it expects a bandwidth parameter which is not needed for DVB‑S.

Since the scan didn't complete, I couldn't test dvbv5-zap with the result.

Kernel update: I even upgraded to the Backports kernel (6.12.95+), but the result is the same.

NextPVR version: I'm running 7.1.1.260616 – in case that helps for reference.

But here's an important discovery: I checked my VDR setup on the same system, and VDR works perfectly with the same channels. The working VDR entry for VOX uses:

text
VOX;RTL Deutschland:12187:hC34M2O0S0:S19.2E:27500:167=2:136=deu@3:71;74:0:12060:1:1089:0
So the key difference is the frequency – 12187 MHz (not 12188). This suggests that the driver and firmware are fine, and the issue is simply a parameter mismatch.

I'll test with the correct VDR parameters tomorrow and report back.

Thanks again for your patience!

Cheers,
fireball