Barracuda09
Freezing when watching encrypted channels decoded by client
Hi, I have issue watching encrypted channels, Every time ECM is updated, picture will freeze for half of a second. Anyone can help me here what could be wrong? FTA channels are running well.
Server: VU+ SOLO 4K, Open ATV 7.3, FBC tuners Client, VU+ ZERO 4K, Open ATV 7.3, EMU: CCcam, ECM < 100ms LAN: 1 GBps SATPI Version | 1.6.2.161~ga9aab2c CC Errors | 4789
------------LOG----
Thu Nov 30 19:37:33.5202 2023 6 Found FrondtendID: 3 (fe=3) StreamID: 102 SessionID: 0259402104 Thu Nov 30 19:37:33.5203 2023 6 Frontend: 3, StreamClient with SessionID 0259402104 Thu Nov 30 19:37:33.5203 2023 6 Frontend: 3, Parsing transport parameters... Thu Nov 30 19:37:33.5204 2023 7 Frontend: 3, Parsing PID parameter: delpids=2960,2910,2920,0,2900,2921,2950 Thu Nov 30 19:37:33.5204 2023 7 Frontend: 3, Parsing transport parameters (Finished) Thu Nov 30 19:37:33.5205 2023 6 Frontend: 3, Updating frontend... Thu Nov 30 19:37:33.5205 2023 6 Frontend: 3, Updating PID filters... Thu Nov 30 19:37:33.5408 2023 7 Frontend: 3, Remove filter PID: 2900 - Packet Count: 000000295:000004 - PMT Thu Nov 30 19:37:33.5610 2023 7 Frontend: 3, Remove filter PID: 2910 - Packet Count: 000156848:000031 Thu Nov 30 19:37:33.5812 2023 7 Frontend: 3, Remove filter PID: 2920 - Packet Count: 000005055:000044 Thu Nov 30 19:37:33.6013 2023 7 Frontend: 3, Remove filter PID: 2921 - Packet Count: 000004910:000010 Thu Nov 30 19:37:33.6215 2023 7 Frontend: 3, Remove filter PID: 2950 - Packet Count: 000000097:000000 Thu Nov 30 19:37:33.6417 2023 7 Frontend: 3, Remove filter PID: 2960 - Packet Count: 000000042:000002 Thu Nov 30 19:37:33.6419 2023 6 Frontend: 3, Updating frontend (Finished in 121 ms) Thu Nov 30 19:37:33.6420 2023 7 Send reply in 121 ms Thu Nov 30 19:37:33.6420 2023 7 RTSP/1.0 200 OK Thu Nov 30 19:37:33.6420 2023 7 Server: satpi/1.6.2.161-ga9aab2c Thu Nov 30 19:37:33.6420 2023 7 RTP-Info: url=rtsp://192.168.1.23/stream=102 Thu Nov 30 19:37:33.6420 2023 7 CSeq: 46 Thu Nov 30 19:37:33.6420 2023 7 Session: 0259402104 Thu Nov 30 19:37:33.6420 2023 7 Range: npt=0.000- Thu Nov 30 19:37:33.6420 2023 7 <CRLF> Thu Nov 30 19:37:35.4949 2023 7 RTSP Stream data from client None with IP 192.168.1.24 on Port 51878: PLAY rtsp://192.168.1.23:554/stream=102?delpids=2941 RTSP/1.0 Thu Nov 30 19:37:35.4949 2023 7 CSeq: 47 Thu Nov 30 19:37:35.4949 2023 7 Session: 0259402104 Thu Nov 30 19:37:35.4949 2023 7 <CRLF> Thu Nov 30 19:37:35.4950 2023 6 Found FrondtendID: 3 (fe=3) StreamID: 102 SessionID: 0259402104 Thu Nov 30 19:37:35.4951 2023 6 Frontend: 3, StreamClient with SessionID 0259402104 Thu Nov 30 19:37:35.4951 2023 6 Frontend: 3, Parsing transport parameters... Thu Nov 30 19:37:35.4952 2023 7 Frontend: 3, Parsing PID parameter: delpids=2941 Thu Nov 30 19:37:35.4952 2023 7 Frontend: 3, Parsing transport parameters (Finished) Thu Nov 30 19:37:35.4953 2023 6 Frontend: 3, Updating frontend... Thu Nov 30 19:37:35.4953 2023 6 Frontend: 3, Updating PID filters... Thu Nov 30 19:37:35.5157 2023 7 Frontend: 3, Remove filter PID: 2941 - Packet Count: 000000019:000000 Thu Nov 30 19:37:35.5159 2023 6 Frontend: 3, Updating frontend (Finished in 20 ms) Thu Nov 30 19:37:35.5159 2023 7 Send reply in 21 ms Thu Nov 30 19:37:35.5159 2023 7 RTSP/1.0 200 OK Thu Nov 30 19:37:35.5159 2023 7 Server: satpi/1.6.2.161~ga9aab2c Thu Nov 30 19:37:35.5159 2023 7 RTP-Info: url=rtsp://192.168.1.23/stream=102 Thu Nov 30 19:37:35.5159 2023 7 CSeq: 47 Thu Nov 30 19:37:35.5159 2023 7 Session: 0259402104 Thu Nov 30 19:37:35.5159 2023 7 Range: npt=0.000- Thu Nov 30 19:37:35.5159 2023 7 <CRLF> Thu Nov 30 19:37:36.4949 2023 7 RTSP Stream data from client None with IP 192.168.1.24 on Port 51878: PLAY rtsp://192.168.1.23:554/stream=102?delpids=18 RTSP/1.0 Thu Nov 30 19:37:36.4949 2023 7 CSeq: 48 Thu Nov 30 19:37:36.4949 2023 7 Session: 0259402104 Thu Nov 30 19:37:36.4949 2023 7 <CRLF>Frontend Info
---Frontend Info-- Stream Index 3 Enable Attached no Type DVB-S(2) FBC (Slot A) Name Vuplus FE Path /dev/dvb/adapter0/frontend2 Freq Range 950000 Hz to 2150000 Hz Symbol Rate Range 1000000 symbols/s to 45000000 symbols/s Linux DVB API version 0x050A Stream Info Stream URL URL Link Channel Info Network Name Not Found Channel Name Not Found Delivery System UNKNOWN DELSYS Tune Frequency (kHz) 0 Modulation Fec Symbol Rate 0 Monitor Info Status 0 Signal Strength 0 snr 0 ber 0 unc 0 PID CC Errors 4789 Configuration DVR Buffer (MB) 5 RTCP Signal Update Freq 1 Filter PCR for timing Wait On Tuning Lock Timeout (ms) 1000 Turn off LNB Voltage during teardown Enable slightly higher LNB Voltage List of PIDs to add to requests (CSV) 0,1,16,17,18 Transformation Info Transformation enable Advertise as DVB-S2 Transformation Mapping M3U mapping.m3u Transformation Frequency 0 FBC Configuration FBC Connection A FBC Linked Send DiSEqC Via Linked Root Tuner DiSEqC Configuration DiSEqC Unicable (EN50494) Repeat DiSEqC 0 Channel Freq (MHz) 1680 Channel Slot (0-32) 2 Delay before write 10 Delay after write 15 PIN (256 disabled) 256 LNB Configuration LNB 1 Lof High (MHz) 10600 Lof Low (MHz) 9750 Lof Switch (MHz) 11700
Hi @sekinooo
Is the decoding takes place in the Client: VU+ ZERO 4K?
Edit: sorry, it was a question
Hi @Barracuda09
I'm aware that decoding is taking place on the client side. ECM is recieved under 100ms, so this is not the issue with latency, I think... When physically connecting Client instead of server, local decoding is working without freezing. ECM is updating sometimes 200ms - 300ms but still not freezing...
Any idea what can cause the freezing when decoding on client side? Can something be changed in config to avoid this?
Hi @sekinooo
I do not have a idea yet, but a few questions:
- But the PIDs are not changing in between?
- Could you try to decode it in SatPI with OSCam?
Hi @Barracuda09
I just got an idea to install OScam on client instead of CCcam, I will give it a try...
Hi @Barracuda09
So using OScam, didn't solve the issue.
But the PIDs are not changing in between?
Where can I find if PIDS are changing? In SATPI log? Or Frontend Monitor?
Could you try to decode it in SatPI with OSCam?
I have empty tab in SATPI > OScam, I downloaded version from openATV feed. I need another version?
Hi @Barracuda09
running OScam directly in SATPI solve the issue with freezing!!! Hooray 👍
but 2 new issues arised:
-
SERVER: OScam on Server box, is no longer decoding channels on local box while viewing, due to change in DVBAPI. Can I have 2 DVBAPIs? Or how to solve that?
-
CLIENT: OScam must be turned off on Client box, while watching channels from SATPI, (if turned on it's freezing again, client decoding channels, why???) but I need OScam to watch channels on local box from other sat. position. How to block OScam on Client to not decoding channels from SATPI (other sat position), but decode from other satellite pos. ?
Answers:
- You can try to set in (SatPI) the OSCam Configure Page option OSCam Aadapter offset to 10
- i do not exactly what you mean with this. So the decoded Channels from SatPI still go through the decoding on client side?
You can try to set in (SatPI) the OSCam Configure Page option OSCam Aadapter offset to 10
What will this do? How can I add another DVBAPI entry in oscam.conf? Will it work with 2 DVBAPIs? 1 for SATPI and 1 for local box?
i do not exactly what you mean with this. So the decoded Channels from SatPI still go through the decoding on client side?
YES, If I turn ON OScam on Client, the decoded Channels from SatPI still go through the decoding on client side and freeze. Looks like channel will pass undecoded at first, when no decoder is found then using Server OScam... That was from my quick test...
As far as I know you can not add an extra entry (or connection), you should be able to do the same with the offset in SatPI
OK, so I have 1 DVBAPI. I can choose to feed OSCAM in SATPI or in SERVER box, what should I do to have both things working same time? Should I remove this from Oscam.conf?
[dvbapi] enabled = 1 au = 1 pmt_mode = 4 listen_port = 15012 user = TEST read_sdt = 2 boxtype = pc
and put this?
[dvbapi] enabled = 1 user = auto au = 1 pmt_mode = 0 request_mode = 0 boxtype = dreambox
and both will be working?
I don't think SatPI will work properly with boxtype = dreambox (I use/tested with boxtype = pc)
- Does client not work with
boxtype = pc - Did you try to increase
OSCam Aadapter offset to 10
When I choose in OScam.conf boxtype = dreambox local box is decoding local channels, SATPI will NOT connect to OScam.
When I choose in OScam.conf boxtype = pc local box is NOT decoding local channels, SATPI will connect to OScam.
I think OSCam Aadapter offset to 10 has no effect here when mentioned situation above :(
Can you make SATPI version to work with boxtype = dreambox ?
Maybe I will need to ask on OScam board to help solve this issue with DVBAPI ...
Or you(we) should try to figure out why during client decode the picture freezes?
But it seems that decoding in SatPI works correctly.
I made some tests looks like latency/delay is making picture to freeze ?! Decoding is using Irdeto system.
Client Local decoding - freezes picture and sound everytime ECM changes for half second SATPI decoding - OScam connected to Client's OScam server - freezes picture maybe 1-2 times a minute for a fraction of second, sound running OK SATPI decoding - OScam connected to local OScam server - no freezes
Running on LAN 1GBps, router RaspberryPI4
Hi @Barracuda09
I made some test (SATPI decoding - OScam connected to Client's OScam server) watching LIVE LOG from SATPI and watching TV and found out that freezing has something to do with log, please check. This is happening in cycles, every time "freeze part" appears in the log the picture in TV will freeze for a fraction of second. Looks like cause of freezing is not on client side ?!
NO, LAN cable, 1GBps switch in between. Reconnect is doing every 30 - 60s. Sometimes after 3-4 minutes SATPI stops streaming completly and I need to manually switch channel to reconect.
Is there some buffer settings? What is doing DVR Buffer (MB) in Frontend settings? I'm Using Frontend 3, disabled 1 and 2, does it have any impact? As I use tuner 1 and 2 for local decoding on VU+ SOLO 4K.
Do you have the web interface of SatPI constantly open? and maybe on more devices?
It is for me a bit difficult to debug, because I do not observe this problem.
- I'm Using Frontend 3, disabled 1 and 2, does it have any impact? -> no that should have no impact
- What is doing DVR Buffer (MB) in Frontend settings? -> that is how much the 'driver' should allocate for DVR buffer, you could increment this for testing
I made some more tests. LAN capacity is not an issue here, I can stream FTA 4k channel from other receiver without any issue.
- SATPI Streaming FTA channels - no freezes at all, working flawless!
- SATPI decoding - OScam connected to Server's OScam server - no freezes at all, working flawless!
- SATPI decoding - OScam connected to Client's OScam server - 99% working without issue, I would consider this pretty same as streaming from OScam running on server. There is reconnection every few minutes which doesn't affect picture, no freeze.
- Decoding via Client box - OScam/CCcam everytime when ECM is updated there is reconnection in SATPI log = picture freeze for half of a second.
If decoding via client box is not working reliable when ECM changes, this makes me think that this is probably an issue in the client.
- Client and Sever are on the same internal network? or is there an internet connection between client OSCam etc.
- Which client do you use? satipclient?
SatPI is just passing the requested PIDs to the client without interruption when client handles the decoding. When SatPI is decoding, only a few requested (by OSCam) packets are send to OSCam, so no big bandwidth is needed.
Client and Server are literally 10 meters away, there is 1 Gigabit switch between them.
If client is decoding same channels localy connected to satellite antena, same OScam or CCcam, it's working without issue.
If client is decoding same channels localy connected to SATPI via LAN, same OScam or CCcam, it's freezing everytime ECM is updated, there is also everytime reconnection in SATPI log. This can't be related to network performance, but I think to some software bug or incompatibility.
Also it's very interesting why it's also doing (decrypting) again when stream should be already decrypted on Server side via OSCAM in SATPI. I checked Rewrite PMT in SATPI > OScam config, but is still decrypting on client side, when I turn on local decrypting via OSCAM.
What do you mean with there is also everytime reconnection in SATPI log
When decoding on client box, everytime ECM is updated, there is reconnection in SATPI log. That's why I think it's some kind of bug. To be precise, there are 2 reconnections in a row, everytime ECM is updated. Never 1 reconnection.
Sorry i do not understand what is reconnecting.
Could you show it in/with a log file and point to what (you) think is the re-connection?
Please see my screenshot above from yesterday. I think when there is text Found FrontendID ... it's reconnection. At least that's what said @Saentist yesterday. It's always 2-3 reconnections when client is decoding stream and ECM is updated = picture freeze.
When streaming FTA channel or stream is decrypted on Server, there is 1 reconnection every 3-5 minutes, which is not affecting picture.
- Which client do you use? satipclient?
SATIPclient from Open ATV 7.3 feed.
Looks like everything is ULTRA real time, even some few miliseconds reconnection will do picture freeze, is there any buffering implemented in the SATIPclient ? When I disconnect LAN cable from receiver in that very moment picture stop streaming, there is no 1 second or more buffer as I can see, right?
The re-connetion @Saentist is talking about was maybe the WIFI.
Those entries are requests from satipclient and probably PMT scans. Satipclient is scanning them very often, why is a question to me. So it is no re-connection nor should it have anything to do with ECM changes.