Posts by rofafor

The only drawback is slowing down channel changes when no lock can get acquired.

Take a look at the README. The easiest way is to statically configure the servers and assign satellite positions:

vdr -P 'satip -s 192.168.0.1|DVBS2-8:S19.2E|OctopusNet1;192.168.0.2|DVBS2-8:28.2E|OctopusNet2'

I guess this is related to this issue: https://github.com/pesintta/vdr-p…mment-411814037

Just rename your devices as "fritzdvbc" and the both quirks should be enabled automatically. You can verify this in logs at the startup.

-d 1 -s 192.168.178.1|DVBC-1|fritzdvbc

or you can define those in the command-line as stated in README:

-d 1 -s 192.168.178.1|DVBC-1|FritzBox:0x6

Your channels.conf entries defines only modulation (M), but you'd need to define also inversion (I) if you want to fully comply with SAT>IP specification. VDR is interpreting a missing value as "AUTO", which isn't supported in the specs.

I'd try the following tricks:

- add all necessary channels.conf entries for your cable channels as the standard doesn't support VDR's auto: I couldn't spot at least the coderate and inversion

- limit available devices to one - now you've banging the server with two simultaneous clients

- enable PlayPids (0x2) quirk - you're getting errors with PLAY commands and there have been servers (old Fritz!Box hardware) that can't handle addpids/delpids commands correctly and always requires a full pid list. Also the ForceLock (0x4) quirk has been required with those ones as well.

Sorry, I gave wrong instructions! You're correct, the port 554/TCP should be the one for capturing.

Captured RTSP-only (554/TCP) traffic dump and the VDR logs from the same session should be enough for the initial analysis.

Do you have the latest firmware on your ONet? If yes, you might want to try out the latest beta firmware as well. Your logs indicate messed up state machine between the plugin and server (455 Method Not Valid in This State) and these have detected with earlier firmware versions, IIRC. However, your issues might be related to this bug report: https://github.com/rofafor/vdr-plugin-satip/issues/42

FYI. ONet doesn't support RTSP-over-TCP.

Quote from wirbel

Das Plugin sollte diese channels.conf settings nur noch 1:1 weitergeben. Hier immer 'on' zu senden ist doch definitiv falsch.

The problem here is, that VDR defaults to pilot auto and the setting isn't mandatory entry. Most the SAT>IP servers are Linux based and drivers defaults to the same setting, and therefore omitting the "plts" setting is fine for them, but some do require it. For these strictly compliant servers I've enabled the ForcePilot quirk, that defaults to set the pilot tone on for channels missing the channels.conf information - otherwise these servers are returning internal errors. Now, it could it better to default to the off setting, but without forcing this setting most of users don't have to go through and edit their channels.conf.

You can limit the allocation space for RTP/RTCP ports by using --portrange command-line parameter.

Have you verified that you aren't getting those "Receive buffer errors" mentioned in plugin's README?

FYI: vaapidevice doesn't support atmo grab service and therefore is using totally different code path in the dfatmo plugin than with softhddevice.

Quote from kls

What is the purpose of cSoftRemote in vaapidevice?

Exactly same as in softhddevice - it dispatches detected Xkeysyms into VDR for remote control handling. Badly named class, I agree.

We're not going to downgrade the libva requirement, but we might even upgrade it to 2.1. There's no point using any media library from 2016.

Quote from mighty-p

Ein paar Anpassungen musste ich trotzdem in der Datei video.c machen, da in meinem System (Mint 18.3, entspricht in etwa Ubuntu Xenial, mit in /opt nachinstalliertem ffmpeg 3.3.2) eigentlich die libva zu alt ist. Das kann man aber mit ein paar Anpassungen umgehen (falls jemand sie braucht, kann ich nen Patch hier anhängen).

Could you share the modification you needed as a Github issue?

FYI: the vpp_support branch was never tested with VDPAU card, so I wouldn't say VDPAU is supported on it, but it might work somehow.

Well, NTSC users could provide a pull request supporting libavfilter's telecine or just keep using VDPAU.

Those were VDPAU-only settings and had no effect under VAAPI, so they had to go.

Quote from HelmutB

But is the SSI/SQI representation really country-specific? And if, is there any DVB complient way to do this?

Well, you were referring to Nordig standard earlier.

...and a reminder that any Nordig specific implementation should be hidden behind a proper standard compliance: Setup.StandardCompliance==STANDARD_NORDIG