CT 2017-2 Artikel SATIP Megasat SAT to IP Server 3 - Erfahrungen?

@XX- : Danke, das war eine wirklich interessante Info.

Mal etwas mehr Infos:

Der Sat>IP-Server der MEG-8000 hat eine CLI welche sich hier befindet:

/opt/bin/sat2ip_server/sat2ip_cmdl.elf

Im Spoiler Ausgabe von
/opt/bin/sat2ip_server/sat2ip_cmdl.elf -h

[AS-B3S100-Server]$ /opt/bin/sat2ip_server/sat2ip_cmdl.elf -h
[SAT>IP CMDL] Parsing command line...


 SAT>IP server deamon command line application
        Usage:
        sat2ip_cmdl.elf  -c<command> -t<pool_time> <Preset> [-h]


   -h Displays this help message


   <pool_time> Time in miliseconds to pool command. If 0 command will be pulled only once


   <Preset> Predefined presets (if more than one is present only first will be processed
            and if there is any <command> defined it will be skipped as well):


        -b    Display device info.
        -f    Display frontend detailed info.
   <command>   command for SAT>IP deamon
        fegbe<n> - Get FE n BER. Response: fegbe<n><BER>
        fegci<n> - Get FE n Client IP. Response: fegci<n><IP>
        fegfr<n> - Get FE n Frequency. Response: fegfr<n><freq>
        fegpi<n> - Get FE n List Of Pids. Response: fegpi<n><pids>
        fegls<n> - Get FE n Lock Status. Response: fegls<n><lock>
        fegmt<n> - Get FE n Modulation. Response: fegmt<n><modulation>
        fegpl<n> - Get FE n Playing Status. Response: fegpl<n><play>
        fegpo<n> - Get FE n Polarization. Response: fegpo<n><pol>
        fegrs<n> - Get FE n Reception Standard. Response: fegrs<n><rec_st>
        fegst<n> - Get FE n Session Type. Response: fegst<n><sessiont>
        fegsq<n> - Get FE n Signal quality. Response: fegsq<n><sig_q>
        fegsr<n> - Get FE n Symbol Rate. Response: fegsr<n><sr>
        fegty<n> - Get FE n Type. Response: fegty<n><type>
        fegfe<n> - Get FE n Free status. Response: fegfe<n><free>
        dvgid - Get Device ID. Response: dvgid<id>
        dvgfw - Get FW version. Response: dvgfw<fw>
        dvghw - Get HW version. Response: dvghw<hw>
        dvgmc - Get MAC. Response: dvgmc<MAC>
        dvgnc - Get number of cable FE. Response: dvgnc<ncab>
        dvgns - Get number of satellite FE. Response: dvgns<nsat>
        dvgnt - Get number of terrestrial FE. Response: dvgnt<nter>
        dvgcl - Get number of clients attached. Response: dvgcl<ncli>
        dvgcp - Get CPU usage. Response: dvgcp<cpu_u>
        dvgmu - Get Memory usage. Response: dvgmu<mem_u>
        dvgut - Get up time. Response: dvgut<up_t>
        sigfn - Get Friendly Name. Response: sigfn<friendly_name>
        sigti - Get Session timeout. Response: sigti<timeout>
        sigln - Get LNB Type. Response: sigln<n>
        siglf - Get LNB freq settings. Response: siglf<-freq-hiBandOLFreg-loBandOLFreg->
        sisfn<str> - Set <str> as server friendly name. Response: sisfn<b> - b is 0 if failed, or 1 if sucessfull
        sisti<n> - Set <n> as timeout. Response: sisti<b> - b is 0 if failed, or 1 if sucessfull
        sisln<n> - Set LNB Type: <n>=0 - quattro; <n>=1 - One demod one RF; <n>=2 - quad. Response: sisln<b> - b is 0 if failed, or 1 if sucessfull
        sislf<-freq-hiBandOLFreg-loBandOLFreg-> - Set LNB OL frequencies. Response: sislf<b> - b is 0 if failed, or 1 if sucessfull
        sisxm<str> - Upload /data/device_description.xml. Response: sisxm<b> - b is 0 if failed, or 1 if sucessfull
        stscr<n><param> - Create static session on FE <n> using <params>. Response: stscr<n><b> - b is 0 if failed, or 1 if sucessfull
                          <params>=-msys-src-freq-pol-sr-fec-mtype-pilot-ro-pids-name-lcn-mcastIP-mcastPorts-TTL-
                    order of parametars must be preserved. On missing param place -none-. Example:
                          <params>=-dvbs2-1-10773-h-22000-34-8psk-off-0.20;0,96,255,259-ANIXE HD-0-239.1.0.0-5004_5005-3-
        stste<n> - Terminate static session on FE <n>. . Response: stste<n><b> - b is 0 if failed, or 1 if sucessfull
        srcdg<n> - Set debug mode
        srcen<n> - Close SAT>IP server.

Debugging kann mit dem Kommando eingeschaltet werden:

/opt/bin/sat2ip_server/sat2ip_cmdl.elf -csrcdg2

Hier durch wird die Kiste im /var/log/messages etwas gesprächiger.

So, ich habe jetzt mal grade noch 2 Logfiles erzeugt (s. Dateianhänge)

1. Logfile (1_log_reboot_megasat && 1_log_reboot_vdr_1_tuner_than_playback_switch_channel_stop_playback)*:
* aufgrund der Dateigröße musste ich den "boot" Part in ein eingenes .txt-File kopieren.
- VDR stoppen und satip-plugin mit Parameter -d1 (nur 1 Tuner) konfigurieren
- MEG-8000 neustarten && Debugging aktivieren
- VDR starten, abwarten bis Channel/EPG-Update abgeschlossen
- Wiedergabe von ARD HD über Streamdev-Client
- Switch nach ZDF HD auf Streamdev-Client
- Wiedergabe beenden auf Streamdev-Client

2. Logfile (2_log_reboot_android_satip_playback_switch_channel_stop_playback.txt):
- VDR stoppen und aus lassen
- MEG-8000 neustarten && Debugging aktivieren
- Android Sat>IP-App starten
- Wiedergabe von ARD starten
- Switch nach ZDF
- Wiedergabe beenden

Vielleicht hat ja noch jemand lust und langeweile und kann in den Logs etwas lesen

Ich bin jetzt mal offline, denke ich werde mich morgen wieder dran setzen, dann gucke ich mal ob ich ggf. mit Wireshark noch ein paar mehr Infos raus bekomme

Deine Android app verhält sich ja furchtbar.
Nach jedem einzelnen Befehl wird die Verbindung beendet, um noch in der selben Sekunde eine neue Verbindung mit neuem Port aufzubauen.

Und das satip Plugin hat in dem kurzen Mitschnitt im Halb-Sekundenrhythmus die PIDs 6100 und 6300 getoggelt..
Feb 11 18:53:03 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6300&delpids=6100 RTSP/1.0"
Feb 11 18:53:03 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6100&delpids=6300 RTSP/1.0"
Feb 11 18:53:04 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6300&delpids=6100 RTSP/1.0"
Feb 11 18:53:04 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6100&delpids=6300 RTSP/1.0"
Feb 11 18:53:05 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6300&delpids=6100 RTSP/1.0"
Feb 11 18:53:05 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6100&delpids=6300 RTSP/1.0"
Feb 11 18:53:05 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6300&delpids=6100 RTSP/1.0"
Feb 11 18:53:06 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6100&delpids=6300 RTSP/1.0"
Feb 11 18:53:06 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6300&delpids=6100 RTSP/1.0"
Feb 11 18:53:07 : D satip_cli.c:158:SatIpCliReadSocket client 0 "PLAY rtsp://192.168.1.4/stream=3?addpids=6100&delpids=6300 RTSP/1.0"

Dass sowhl die android app als auch das satip plugin so nicht korrekt funzen ist wohl klar.

Quote from wirbel

Und das satip Plugin hat in dem kurzen Mitschnitt im Halb-Sekundenrhythmus die PIDs 6100 und 6300 getoggelt..

This is due to VDR's PMT scan. The switching interval should be much faster, but the satip plugin artificially slows it down.

Quote from rofafor

Quoted from "wirbel"
Und das satip Plugin hat in dem kurzen Mitschnitt im Halb-Sekundenrhythmus die PIDs 6100 und 6300 getoggelt..

This is due to VDR's PMT scan. The switching interval should be much faster, but the satip plugin artificially slows it down.

Is this a problem or wanted behavior of the satip-plugin?

rofafor: Can you give us some hints for further analysing?

It's a wanted and correct functionality: VDR is constantly going through PMT pids on active muxes and triggering on detected updates on them. One might argue about the implementation: whether receive all PMT pids all the time or just one at a time. The VDR is using the latter.

If so, it should be really changed.

hmm..

there should a program allocation table on PID=0x00 where all PMT Pids are listed.
For each service (TV,Radio, Downloads,whatever,..) there should be one PMT Pid (in this case 6100 or 6300), where all the streams belongign to this service are listed (audio, video, teletext).

So if tuning to transponder, there should be one call to 0x00 (PAT) and after that for each PID listed there one call to this PID.

What we see here is turning over and over again to the same pids..

Please, take a look at the cPatFilter in pat.c. If that particular mux should contain more than 2 PMT tables, there's propably a timing related bug in the satip plugin and you might want to decrease ePidUpdateIntervalMs from 250ms to 100ms.

The PAT pid is always added once at start and afterwards VDR is switching to a next PMT pid right after it has interpreted the current one. This goes on and on until the device is closed.

Hi Rolf,

that would be interesting, because in such case we would hit a bug in VDR's PAT table algorithm thta urgently needs to be fixed..

Probably you're refererring to this line

if (pat.getVersionNumber() != patVersion) {

In which case it would be toggled over and over. This code assumes, that there's *one* PAT table at one time.

may be someone could verify this by hex printing all PAT data for this table.

And another one for debugging is: if (!PmtVersionChanged(Pid, pmt.getTableIdExtension(), pmt.getVersionNumber())) {

I really would like to help here, but..

currently i'm compiling my next linux-from-scratch, so i'm out-of-order for quite a while..

Quote from wirbel

I really would like to help here, but..

currently i'm compiling my next linux-from-scratch, so i'm out-of-order for quite a while..

LFS? Sowas machst du! Must du Zeit haben

vdr-box

Quote from wirbel

may be someone could verify this by hex printing all PAT data for this table.

Is there a way to get the data via a SatIP-Device? DVBSnoop seems only to work with a "native" dvb-devices.

DoubleXMinus: It helps perhaps in your case?
[vdr-plugin-satip] debug rtsp communication for Inverto OEM devices

Quote from Uwe

DoubleXMinus: It helps perhaps in your case?
[vdr-plugin-satip] debug rtsp communication for Inverto OEM devices

Thanks but i already got it.

Is anyone interested in network-dumps using wireshark?
Please tell which fileformat is prefered.

So I think from the dump I can also extract the PAT-Data, but I do not know how to "read"

I wrote a bash script to debug a recent problem with my DD OctopusNet. You have to edit it, but you can easily create any RTSP request sequence:

#!/bin/bash


URL1="rtsp://10.76.1.173/?freq=186&msys=dvbc&mtype=256qam&sr=6900"
URL2="rtsp://10.76.1.173/"
URL3="?&pids=0,144,155,156"
HOST="wlan-173"


PORT="554"
RPRT="25000-25001"
R=`sed -e 's/-.*//' <<<$RPRT`
CSEQ=0


rtsp_play() {
# RTSP PLAY Request
#
REPL="$(printf "PLAY $1 RTSP/1.0\r
CSeq: $((CSEQ+1))\r
User-Agent: Lavf56.40.101\r
Session: ${SESS}\r
\r\n" | nc ${HOST} ${PORT} | tr -d '\r')"


sed -n -e 's/CSeq: //p' <<<"$REPL"
}


rtsp_options() {
# RTSP OPTIONS Request
#
REPL="$(printf "OPTIONS $1 RTSP/1.0\r
CSeq: $((CSEQ+1))\r
User-Agent: Lavf56.40.101\r
\r\n" | nc ${HOST} ${PORT} | tr -d '\r')"


sed -n -e 's/CSeq: //p' <<<"$REPL"
}


rtsp_describe() {
# RTSP DESCRIBE Request
#
REPL="$(printf "DESCRIBE $1 RTSP/1.0\r
Accept: application/sdp\r
CSeq: $((CSEQ+1))\r
User-Agent: Lavf56.40.101\r
\r\n" | nc ${HOST} ${PORT} | tr -d '\r')"


sed -n -e 's/CSeq: //p' <<<"$REPL"
}


CSEQ=`rtsp_options "${URL2}"`


# RTSP SETUP Request
#
REPL="$(printf "SETUP ${URL1} RTSP/1.0\r
Transport: RTP/AVP/UDP;unicast;client_port=${RPRT}\r
CSeq: $((CSEQ+1))\r
User-Agent: Lavf56.40.101\r
\r\n" | nc ${HOST} ${PORT} | tr -d '\r')"


CSEQ=`sed -n -e 's/CSeq: //p' <<<"$REPL"`
SESS=`sed -n -e 's/Session: //' -e 's/;timeout.*//p' <<<"$REPL"`
SPRT=`sed -n -e 's/Transport: .*server_port=//p' <<<"$REPL" | sed -e 's/-.*//'`
STRM=`sed -n -e 's/com.ses.streamID: //p' <<<"$REPL"`


(nc -u -w 5 -p ${R} ${HOST} ${SPRT} >out_stream.ts) &


CSEQ=`rtsp_play "${URL2}stream=${STRM}${URL3}"`
CSEQ=`rtsp_describe "${URL2}stream=${STRM}"`
CSEQ=`rtsp_play "rtsp://10.76.1.173/stream=${STRM}?freq=186&msys=dvbc&mtype=256qam&sr=6900"`
CSEQ=`rtsp_play "rtsp://10.76.1.173/stream=${STRM}?pids=1,144,153,155,156,163,173"`
CSEQ=`rtsp_play "rtsp://10.76.1.173/stream=${STRM}?addpids=1,128,129,130,153,163,164,173"`


for i in `seq 0 1`
do
	sleep 2
	ls -lh out_stream.ts
done


# RTSP TEARDOWN Request
#
REPL="$(printf "TEARDOWN ${URL2}stream=${STRM} RTSP/1.0\r
CSeq: $((CSEQ+1))\r
User-Agent: Lavf56.40.101\r
Session: ${SESS}\r
\r\n" | nc ${HOST} ${PORT} | tr -d '\r')"

Bei mir bleibt der MEG8000 mitlerweile regelmäßig hängen. Gibt es da irgendwas was man tun kann?

Zunächst, sah es die ersten Tage sehr gut aus. Aber jetzt habe ich fast täglich irgendwann kein Bild mehr.
Das eigenartige ist, dass sich die Info bei den Frontends ändert und ich noch freie Ports hätte.
Aber ein Bild erhalte ich weder über den VDR noch direkt über die App.

Welche Firmware nutzt Ihr, die stabil ist? Ich habe jetzt die drauf Version: 3.1.6 drauf aber sehe keine Verbesserung.

Lösch mal alle ungültigen Kanäle aus der channels.conf und schau ob es besser wird.