WinTV-Nova-S2 Raspberry Pi 4 Buster latest

[calston]

When you connect a nova-s2 USB device nothing happens. Adding the firmware has no effect, the device is entirely ignored.

So after hours of hackery I seem to have tricked it into working by forcing the em28xx driver to actually look at it.

modprobe em28xx card=92
echo 2013 8258 | tee /sys/bus/usb/drivers/em28xx/new_id

And hooray, it seems to work in tvheadend and scans.

Not sure if this needs to be a udev rule or the driver doesn't like the product ID my device shows up as. Just wanted to log this on here for prosperity

[charrus]

@calston Thank you so much for this. This is the solution for the newer WinTV-Nova-S2 cards (mine has a revision BAH9 printed on the back).

I have been in touch with Haupauge support and will refer them to this 2 year old issue to resolve my support case.

[rbollampally]

I went through the rabbit hole to figure out what is going on. I believe the problem is probing wrong demod here: em28xx-dvb.c

dvb->i2c_client_demod = dvb_module_probe("m88ds3103", "m88ds3103b",
                         &dev->i2c_adap[dev->def_i2c_bus],
                         0x6a, &m88ds3103_pdata);

V1 and V2 should be combined into one. There is a way to figure out which demod the card is using. See: drivers/media/usb/dvb-usb/dw2102.c

    /* probe for demodulator i2c address */
    demod_addr = -1;
    if (tt_s2_4600_frontend_attach_probe_demod(d, 0x68))
        demod_addr = 0x68;
    else if (tt_s2_4600_frontend_attach_probe_demod(d, 0x69))
        demod_addr = 0x69;
    else if (tt_s2_4600_frontend_attach_probe_demod(d, 0x6a))
        demod_addr = 0x6a;

The correct driver for BAH9 is V1 and not V2 but I think some other cards with same device ID are using different demod

[charrus]

Hauppauge support told me that @b-rad-NDi would be looking into this.

[charrus]

I also went through the rabbit hole with this one - and found https://github.com/b-rad-NDi/media_tree/compare/master...fat-fred:media_tree:master - which at the time looked like what you were proposing, but actually looks likes these have all been merged and a red herring.

[rbollampally]

I have seen those bits of code for supporting m88ds3103b but can't comment if they work or not as I don't have a device with m88ds3103b and there is no documentation available online for these. They are also part of Ubuntu 6.2 LTS (and 6.5) Kernel.

What I'm proposing here is, in em28xx-dvb.c, we have a switch case statements, one for 461e and 461e_v2

    case EM28178_BOARD_PCTV_461E:
        result = em28178_dvb_init_pctv_461e(dev);
        if (result)
            goto out_free;
        break;
    case EM28178_BOARD_PCTV_461E_V2:
        result = em28178_dvb_init_pctv_461e_v2(dev);
        if (result)
            goto out_free;
        break;

The only difference in these two is the address the demod is probed... 0x68 for m88ds3103 and 0x6a for m88ds3103b. The code is assuming that the device is running m88ds3103 or m88ds3103b. Instead of having these as two separate functions, I think it would be better to confirm the device is indeed using the correct demod as it was done in drivers/media/usb/dvb-usb/dw2102.c and get rid of em28178_dvb_init_pctv_461e_v2() function all together.

There are also some fixes the em28178_dvb_init_pctv_461e_v2 is missing.

I also don't know which all revisions use m88ds3103b demod but from different previous issues, it looks like these devices (B8H9) also have same device ID (B8H9) 2013:0461

[rbollampally]

FYI: I also tried modfying the em28178_dvb_init_pctv_461e_v2() to use 0x68 address, it appeared in tvheadend as well but did not function at all. Later on, I discovered the errors in Kernel log that the address is wrong. This is how I came to conclusion that BAH9 is using m88ds3103 demod and not m88ds3103b