[vdr-plugin-satip] Issues with mixed setup DVB-S & DVB-T

  • Quote

    Could you verify that you'll end up using 2 servers?

    Code
    Jan 15 11:11:45 vdr vdr[5203]: [5203] VDR version 2.1.6 started
    Jan 15 11:11:45 vdr vdr[5203]: [5203] SATIP: Adding server '192.168.38.73|DVBS2-2|OctopusNet #0'
    Jan 15 11:11:45 vdr vdr[5203]: [5203] SATIP: Adding server '192.168.38.73|DVBT2-2|OctopusNet #1'


    For simplicity I have now removed the USB device, so only the Octopus sever is involved. Here is a test with channel 1 tuned, timers set for channel 7 and channel 100 (all satellite).


    The attached trace extracted by

    Code
    fdc@vdr ~ $ journalctl --since=11:10 | grep -v 'CloseFilter\|SetPid\|vdpau\|video\|audio\|codec\|softhddev'


    The exact same test with satip started with '--plugin=satip -d 2 -s 192.168.38.73|DVBS2-2|OctopusNet' succeeds. Channels 7 and 100 are recorded and live TV gets preempted to channel 100.

  • Quote

    Thanks for your latest info. I'm now able to reproduce the problem on my system.

    Great!


    I hesitate to wish for another extension while you are still working on this topic, but it is somewhat related. Given a VDR system with SAT>IP server(s) receiving fixed sources, along with a directly connected dvb device with a H-to-H positioner, the current number of disabled sources is insufficient and inconvenient. It is not feasible to store 30 positions in satip.DisabledSources, even if the array size were extended (I assume that there is a limit on setup line length). So, for those with positioners, how about recognizing src=0 in sources.conf as disabling that position from satip, while leaving it available for other devices?

    vdr: 2.5.6, NUC8i5BEH, MANJARO, OctopusNet-Max DVB-S2 Unicable 8 Slots
    samsung tv: ue46d7090

  • Excellent! Thank you very much.


    Initial tests indicate that satip (1.0.2-GIT-d2064f0) works well with '--plugin=satip -d 2 -s 192.168.38.73|DVBS2-2|OctopusNet -S 1'. I assume that I have set the -S 1 parameter correctly?

    vdr: 2.5.6, NUC8i5BEH, MANJARO, OctopusNet-Max DVB-S2 Unicable 8 Slots
    samsung tv: ue46d7090

  • This thread appears to be dormant, but the problem still exists. At least for systems with directly connected dvbdevices and mixed satip dvb-s/dvb-t tuners. vdr overcommits the tuners, leading to "invalid status code 404". The system knows the number of tuners, but it doesn't keep track of their capabilities at the right time. The satip plugin returns 'true' from ProvidesSource indiscriminately. If devices were preassigned as dvb-s/dvb-t/dvb-c (on the basis of the number of each type in the server(s)), ProvidesSource could provide accurate information. As I understand it, the devices are initialized after discovery, so rather than creating 'deviceCount' general purpose devices, it should be possible to create a suitable number of each, marked with a 'tunerType' property (S|T|C), which would later be evaluated in ProvidesSource.


    With this strategy the plugin parameters -d and -S would become redundant. The default would be to use every discovered device. The -s parameter can be used, as at present, to restrict certain server devices. The plugin should avoid creating "phantom" devices. If a server announces "DVBT2-2", that means 2 DVB-T2 devices, which may well be able to receive DVB-T also, but it is still only 2 devices, not 4. For cases such as OctopusNet terrestrial/cable cards, which announce "DVBT2-2,DVBC-2" for 2 tuners, the user must specify, in the -s parameter, what is connected to the 2 inputs.

    vdr: 2.5.6, NUC8i5BEH, MANJARO, OctopusNet-Max DVB-S2 Unicable 8 Slots
    samsung tv: ue46d7090

  • OK, here is a "works for me" patch. The idea is to create devices on demand, after discovery, and assign them a fixed type (sat/ter/cab). I have disabled the logic by which servers are removed and rediscovered. A server can check in but it can't check out.


    I am an old C hacker with limited C++ competence (practically none), so if want to use this, feel free, but check it out carefully.

  • That's exactly the same solution I had in mind, but VDR just doesn't support dynamic devices and therefore this approach is a no-go at the moment. You'll start to experiment crashes when satip servers come and go - you've prevented this behaviour by never cleaning up the expired servers.


    Anyway, the proper way to proceed with this is to get the dynamic devices (aka. dynamite) patch merged into the core VDR.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!