SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

Zitat von rofafor

Do you have any application that works with the device using RTSP?

Yes.

VLC
vtuner/satip client

Hallo zusammen,

ich habe basierend auf diesem Code hier ein kleines Test-Tool zusammengebaut, was die verschiedenen URL-Möglichkeiten ausprobiert.

Fazit:
* Der Fritzdvbc liefert bei addpids/delpids zwar keinen Fehler, wenn sie im PLAY-Request verwendet werden, sind aber offenbar ohne Funktion.
* Die aktuelle Firmware des Fritzdvbc erwartet beim PLAY-Request immer den "pids=" parameter, sonst gibt es einen "Internal Server Error".
* "pids=0" alleine funktioniert auch nicht, dann gibt es ebenfalls einen "Internal Server Error".
* "pids=all" wird nicht unterstützt

Schade!

UPDATE1:
Entfernt: "* das komplette Neusetzen der PIDs mit einem späteren PLAY-Request bleibt ohne Wirkung"
Nach Neustart des Fritzdvbc funktioniert es.

UPDATE2:
Korrektur: "erwartet beim PLAY-Request immer den "pids=" parameter": das ist nur zwingend notwendig, wenn beim SETUP-Request kein "pids" Parameter vorhanden war.

""

Zitat von rofafor

So, the attached patch should add necessary quirks, but "pids=0", that's basicly a hard requirement if you want to adapt dynamically to any pid changes. I guess VLC is relying 100% to the channels.conf and doesn't use it as a starting point as VDR (Setup/Update Pids).

Thanks, I will try that. That "pids=0" is required for the PAT and therefore for dynamic updates is clear.
The problem with Fritzdvbc is that only specifiying "pids=0" leads to an internal server error. I assume because of a bug, because the whole SAT>IP server service does not work anymore after specifiying it. The webpage does not show the live-status anymore. A reboot is required.
This is wrong: If you specifiy an additional dummy PID (e.g."pids=0, 16") then the PAT is delivered together with the other PID.
Correct: Specifying only PIDs <=20 will produce the internal server error. Example: pids=0,16,17,18,20
Setting a dummy PID for which no packets are delivered, will also result in no delivery of the PID0 (PAT).

One more thing. Isn't this modification missing in your patch?

int cSatipServers::NumProvidedSystems(void)
{
  int count = 0;
  for (cSatipServer *s = First(); s; s = Next(s)) {
  	// DVB-S*: qpsk, 8psk
  	count += s->Satellite() * 4;
  	// DVB-T*: qpsk, qam16, qam64, qam256
  	count += (s->Terrestrial2() ? s->Terrestrial2() : s->Terrestrial()) * 4;
  	// DVB-C : qpsk, qam16, qam64, qam256
  	count += s->Cable() * 4;
  	}
  return count;
}

Zitat von rofafor

You'll have to notice that the Fritz!WLAN Repeater DVB-C isn't a real/certified/whatever SAT>IP device as the actual spec doesn't have the cable support yet.

AVM claims that the product is compatible to the SAT-IP-Standard (Cenelec prEN 50585):
http://avm.de/aktuelles/neues-…fritzwlan-repeater-dvb-c/

The new iOS app version of Fritz!TV now also offers the option to show the internal log.
In the log output it also states "SAT>IP server".

I have written a couple to emails to the AVM support already. I have linked this thread for technical details. Now I hope that they consider fixing the issues in their SAT>IP server implementation.

UPDATE1: Please see above for a minor correction concerning the acceptable "pids" parameter values.

New summary of found quirks:

1) No RTCP packet type 204
Problem:
The SAT>IP specification specifies the delivery of RTCP packets together with the RTP packets. Those RTCP packets of type 204 contain the status information of the associated stream.
Exampe: ver1.0;src=1; tuner1,240,1,7,112,,dvbc,,,,6900,34;pids=0,16,17,18,20
This also includes the status information (e.g. signal quality, lock status, etc.) of the tuner.
Fritzdvbc is does not deliver this kind of packets. The SAT>IP plugin cannot provide status info to VDR.
Workaround:
Until AVM fixes this, two options are possible:
1a) hard-code some dummy information and always deliver the lock status (easy to implement)
1b) Send RTSP DESCRIBE request for the stream on a regular interval to get the SDP record and extract the status info from there. (more complex to implement)
Remark:
Fritzdvbc only sends RTCP packet types 200 and 201: sender and receiver reports.
Strange: Why does it send a receiver report to the client?! The receiver report is supposed to be send by the client to server.

2) No addpids/delpids parameter support
Problem:
The SAT>IP specification specifies the mandatory parameters addpids/delpids to modify the table of delivered PIDs (delta-updates).
However, Fritzdvbc does not seem to support these parameters. The parameters are accepted (RTSP status code 200), but they have no effect.
Workaround:
Do not use delta-updates with addpids/delpids parameters. Only use full updates with the "pids" parameter.

3) PIDs <=20 cannot be delivered if only PIDs <=20 are specified in the "pids" parameter
Problem:
The SAT>IP specification specifies that PIDs from 0-8191 should be deliverable by specifying them with "pids" parameter. This would also include the case "pids=0".
However, Fritzdvbc does not deliver PIDs <=20, when no other PID that is really present in the stream is specified additionally. It issues an internal server error instead.
Not working examples: pids=0,16,17,18,20 // pids=0 // pids=20
Working examples for stream "ZDF SD" (PID100 is PMT): pids=0,16,17,18,20,100 // pids=0,100 // pids=0,21 (<- SETUP-Request returns code 200 (OK), the PID 21 is not used and so a delayed PLAY-Request result in code 454 (Unknown stream))
Workaround:
Only send the RTSP PLAY-request until all the required PIDs have been collected. As a consequence, dynamic channel updates only work if there are already some working channels.conf entries with th correct PID settings.
Make sure that "pids=" parameter does not only contain PIDs <=20.
Remark:
This should really be fixed/changed by AVM

Please also note the second update here: SAT>IP Plugin und Fritz!WLAN Repeater DVB-C
So the PLAY-Request may omit the "pids=" parameter if it was already used in the SETUP request to specifiy the PIDs.

Thanks so far for your support.

Attached you will find a working patch for the satip plugin 0.3.3 that works with the Fritzdvbc device.
It would be nice if you could review the method cSatipServers::NumProvidedSystems(void) again for DVB-C.

In addition to your enum eSatipQuirkPlayPids I have added the enum eSatipQuirkForceLock which is set if a "fritzdvbc" is found.
It forces the methods SignalStrength(), SignalQuality() and HasLock() to return hardcoded values since RTCP 204 is missing.

I have added a small piece of code in UpdatePids() which adds a dummy PID of 100 to the URI if the eSatipQuirkPlayPids is set.
This prevents the SAT>IP server on the Fritzdvbc device from misbehaving if only PIDs <=20 are specified on the URL (example: pids=0,16,17,18,20).
So far I can tell that it works. I do not really know what the intention on this was from AVM.

I have tested the patch against several different channels on different transponders so far and it seems to work.

Emails to the AVM support have been written to bring up the issues and I hope that they will fix them.

Small update:
Today I have received a mail from AVM that the issues have been sent to the developers.

Stay tuned!

Kleines Update:
Noch nichts Neues von AVM.
Ich selbst werde das Thema nicht weiter verfolgen, da ich den Fritzdvbc verkauft habe.