Feature #2855
Ignore scrambling
0%
Description
Well this is a super special use case request, so feel free to just say now and declare me insane :-)
In my efforts to get some PowerVU stations in my channel list, I have installed DVB-Viewer Recording Service in a KVM virtual maschine which uses tvheadend as a SAT>IP server. I then mapped some channels back, now being the Recording Service the SAT>IP server and tvheadend the client. This is working fine after some workarounds, so I can scan through Recording Service as it would be a local device. I made sure PowerVU channels work fine on other SAT>IP clients (with the help of some plugin on the DVB-Viewer Recording Service) and can also use DVB-Viewer Recording Service as a UPNP Source for these encrypted services without issues. When I try to open these channels through tvheadend, tvheadend still thinks that these services are encrypted (as I assume only the video and audio data is simple decrypted in the plugin without altering anything in the PMT etc) and tvheadend stays at testing, trying to request a key from capmt which it cannot and in fact must not do. So I now search for a way to simply ignore decrypting, maybe globally for the whole tuner as it can be done when tvheadend is the SAT>IP server.
History
Updated by B C over 9 years ago
Updated by thinking of this again, it should be sufficient to let the payload flow when it is not scrambled....
Updated by Jaroslav Kysela over 9 years ago
Updated by Just set "Descramble Services (Limit Per Mux)" value in the SAT>IP server config to zero. But it will apply for all services which you probably do not want. There is no "per-service" config to skip the descrambling, but it's easy to implement it. Basically, the filter logic is in rtsp_validate_service() - src/satip/rtsp.c .
Updated by B C over 9 years ago
the problem is not on the path from tvh to DVB-Viewer Recording Service (I alredy did set 0 as limit), but on the way back, or more precise when Kodi tries to open the channel as it remains in testing due to not beeing supplied with keys. Although all CA/ECM is present on the way back, the a/v elementary streams are already descrambled and should be passed to the output stream. I will take a look at rtsp_validate_service() if I do understand it :-)
Updated by B C over 9 years ago
rtsp_validate_service is on the output path, as I can disable descrambling in general (which is sufficient as it makes no sense to "proxy" services which tvh can handle natively through an external descrambler anyway), there is no need to filter special CA ids. So what I'm searching for is the function which actually causes the testing state
Updated by Jaroslav Kysela over 9 years ago
OK. I see your point. You can completely filter out the CAIDs using stream filters for some services or CAID/ProviderID definitions.. In this case, tvh won't try to get any keys for them.
Updated by B C over 9 years ago
Filtering is working, thanks for the hint. One problem left, if tvh requests the channel it still stays in testing. If I open the same channel via upnp streaming before on another device (or on another SAT>IP client) it is also working on tvh. Have to check if there is any difference in the pids requested, I need to investigate this a bit further.
Updated by B C over 9 years ago
so I looked in the log of DVB-Viewer Recording Service and compared a request from DVB-Viewer and tvheadend:
DVB-Viewer:
19.05.15 10:43:17.213 TRTSPUDPClient SetTuner TType: 1, Freq: 11804, Symrate: 27500, LOF: 10600, Tone: 1, Pol: 1, DiseqC: 5, FEC: 3, APID: 1520, VPID: 1560, PMT: 5005, SID: 5, SatMod: 1, DiseqCVal: 0, NID: 9, Flags: 25
tvheadend:
19.05.15 10:40:56.039 TRTSPUDPClient SetTuner TType: 1, Freq: 11804, Symrate: 27500, LOF: 10600, Tone: 1, Pol: 1, DiseqC: 5, FEC: 3, APID: 0, VPID: 0, PMT: 0, SID: 0, SatMod: 1, DiseqCVal: 0, NID: 0, Flags: 0
so all pids are missing, maybe a missconfiguration on my side, tried with varios settings on the SAT>IP client settings side but always the same result. Any suggestion?
Updated by Jaroslav Kysela over 9 years ago
No idea, but tvh add pids incrementaly - it may be the reason. But it's bug on the server side.
Updated by Jaroslav Kysela over 9 years ago
Also, I would compare the RTSP communication between working setup and the tvh client - dvbviewer setup (wireshark).
Updated by B C over 9 years ago
well without knowing the serviceid, how should a satip server with a ca device ever know which channel to descramble? Although tvh opens pids later the server must know which channel to serve, otherwise if descrambling happens on the server side it can never work....
Updated by Jaroslav Kysela over 9 years ago
B C wrote:
well without knowing the serviceid, how should a satip server with a ca device ever know which channel to descramble? Although tvh opens pids later the server must know which channel to serve, otherwise if descrambling happens on the server side it can never work....
TVH uses the PID list to look for audio/video PIDs for known services. There is nothing about the sid in SAT>IP spec, so dvbviewer might use a proprietary extension.
Updated by B C over 9 years ago
right, although it must not use a proprietary extension as it might use m3u.
from satip specification 1.2.2:
Additionally or alternatively SAT>IP clients can also rely on service lists made available offline (as files) or online (from a web server) which list all the services available from one or more satellite positions. Clients implementing this type of scheme are refered to as thin clients.
well i think as an alternative I can pipe it through an additional vlc proxy, as I don't think I can add the upnp source stream directly????
Updated by Jaroslav Kysela over 9 years ago
B C wrote:
right, although it must not use a proprietary extension as it might use m3u.
from satip specification 1.2.2:
Additionally or alternatively SAT>IP clients can also rely on service lists made available offline (as files) or online (from a web server) which list all the services available from one or more satellite positions. Clients implementing this type of scheme are refered to as thin clients.well i think as an alternative I can pipe it through an additional vlc proxy, as I don't think I can add the upnp source stream directly????
.m3u lists are for standard HTTP streaming, nothing to do with the SAT>IP protocol. It's just an extension. You may use these URLs as IPTV source in TVH.
Updated by B C over 9 years ago
m3u is used in SAT>IP, either as addition or to support thin clients, but never mind, I will look into the IPTV way
A <satip:X_SATIPM3U> capabilities element may be included in the XML description of a SAT>IP server in order to provide clients with a pointer to a channel list in the m3u format (described in Appendix A).
Updated by Jaroslav Kysela over 9 years ago
B C wrote:
m3u is used in SAT>IP, either as addition or to support thin clients, but never mind, I will look into the IPTV way
Yes, but it serves playlist for HTTP clients - not SAT>IP clients (using RTSP/RTP).
A <satip:X_SATIPM3U> capabilities element may be included in the XML description of a SAT>IP server in order to provide clients with a pointer to a channel list in the m3u format (described in Appendix A).
It's HTTP playlist...
Updated by Jaroslav Kysela over 9 years ago
Jaroslav Kysela wrote:
B C wrote:
m3u is used in SAT>IP, either as addition or to support thin clients, but never mind, I will look into the IPTV way
Yes, but it serves playlist for HTTP clients - not SAT>IP clients (using RTSP/RTP).
A <satip:X_SATIPM3U> capabilities element may be included in the XML description of a SAT>IP server in order to provide clients with a pointer to a channel list in the m3u format (described in Appendix A).
It's HTTP playlist...
Sorry, it seems that playlists were upgraded in latest specs. It allows also rtsp:// URLs now.. OK, It's missing in tvh...
Updated by B C over 9 years ago
no need to be sorry or to apologize, it should be doable with IPTV anyway nor is tvh expected to support anything
Updated by Jaroslav Kysela over 9 years ago
- Status changed from New to Fixed
B C wrote:
no need to be sorry or to apologize, it should be doable with IPTV anyway nor is tvh expected to support anything
Yes, rtsp:// is supported by IPTV in tvh now, too. It has been tested against the SAT>IP server, so it should work. I believe that fetching and managing m3u should belong to bouquets rather than the SAT>IP section in TVH (there might be an autodetection/auto-add from the XML description for SAT>IP, indeed).
Anyway, I believe that dvbviewer should detect the services using dynamic PID lists, too. It's a missing feature for this server / software.
It's beyond the reported issue now, so I'm closing this bug - you may open a new feature request for m3u playlists, if you like.
Updated by B C over 9 years ago
yes, way beyond. I'm fine with the IPTV aproach, it took some time setting it up but the result is what counts. The only cosmetical issue with it is that for each channel I add (which must be done on muxes to be able to specify the sid in the url), tvh finds all services on that mux. So in my case I do have about 30 services from a single mux with 41 services --> 1200 additional redundant services which do not work, but as they are only in the background, no need to really care.