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

Zitat

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

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).

fdc@vdr ~/src/satip-1.0.2 $ sh ~/set-timers
220 vdr SVDRP VideoDiskRecorder 2.1.6; Thu Jan 15 11:12:33 2015; UTF-8
900 SATIP tracing mode: 0x0100
221 vdr closing connection
220 vdr SVDRP VideoDiskRecorder 2.1.6; Thu Jan 15 11:12:34 2015; UTF-8
250 1 BBC One HD
221 vdr closing connection
220 vdr SVDRP VideoDiskRecorder 2.1.6; Thu Jan 15 11:12:35 2015; UTF-8
250 44 1:7:2015-01-15:1114:1122:50:99:Test1:
221 vdr closing connection
220 vdr SVDRP VideoDiskRecorder 2.1.6; Thu Jan 15 11:12:36 2015; UTF-8
250 45 1:100:2015-01-15:1114:1122:50:99:Test3:
221 vdr closing connection

The attached trace extracted by

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.

fdc@vdr ~ $ journalctl --since=11:30 | grep 'VDR version 2.1.6 started\|Adding server\|switching'
Jan 15 11:42:38 vdr vdr[5592]: [5592] VDR version 2.1.6 started
Jan 15 11:42:38 vdr vdr[5592]: [5592] SATIP: Adding server '192.168.38.73|DVBS2-2|OctopusNet #0'
Jan 15 11:42:40 vdr vdr[5592]: [5592] switching to channel 4
Jan 15 11:44:12 vdr vdr[5592]: [5592] switching to channel 1
Jan 15 11:45:06 vdr vdr[5592]: [5592] switching device 4 to channel 7
Jan 15 11:45:17 vdr vdr[5592]: [5592] switching device 4 to channel 100
Jan 15 11:45:28 vdr vdr[5592]: [5592] switching device 4 to channel 7
Jan 15 11:45:39 vdr vdr[5592]: [5592] switching device 4 to channel 100
Jan 15 11:45:50 vdr vdr[5592]: [5592] switching device 4 to channel 7
Jan 15 11:46:00 vdr vdr[5592]: [5592] switching device 4 to channel 7
Jan 15 11:46:01 vdr vdr[5592]: [5592] switching device 3 to channel 100
Jan 15 11:46:02 vdr vdr[5592]: [5592] switching to channel 100

Zitat

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?

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?

Ok. Of course I would like to use mixed front-ends...

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.

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.