Bug #2742
Channelsearch over SAT>IP Server
0%
Description
The search for channels with a client (e.g. DVBViewer) over the SAT>IP Server doesnt work. Though i can see that TVHeadend is searching for something in the stats sheet, in the State column always "Bad" appears at each frequency. And therefor no channels are being found.
Altough there are already channels in the client, the playing of a channels works seamlessly.
I also tested it with another sat>ip server named "minisatip". with that all channels are found.
So i think there must be some issue in the SAT>IP server in TVHeadend.
Thanks in advance for your help.
Kind regards,
Stephan
Files
Related issues
History
Updated by
Updated by Stephan Ramel over 9 years ago
Updated by - File tvheadendlog.txt tvheadendlog.txt added
Hej,
attached you find some logs....
thanks
Updated by Batuhan Topbaş over 9 years ago
Updated by 
- Copied to Bug #2751: Summertime Change incorrect EPG added
Updated by Jaroslav Kysela over 9 years ago
Could you try v3.9-2664-gf6d9813 ?
Also, it would be helpful to compare the "working" parameters for a mux (add mux manually) with a mux added when the SAT>IP the client tries to scan the same mux.
Updated by Stephan Ramel over 9 years ago
Hej...i tried it...but unfortunately no change.
i compared the mux sat>ip adds and scans for channels and the already present mux of the same frequency. they are exactly the same, but FEC is set no "none" at the working one (that was the thing u changed, doesnt make any relevanc how it seems)
whats strange is this:
at first, a tuner, here #1, is allocated, but then "no input source" appears....and also "to channel none".
maybe u got another idea.
2015-03-31 22:10:22.115 mpegts: 314MHz in Kabelplus DVB-C - tuning on STV0367 DVB-C DVB-T : DVB-C #1
2015-03-31 22:10:22.118 subscription: 000E: "SAT>IP" subscribing on "none", weight: 100, adapter: "STV0367 DVB-C DVB-T : DVB-C #1", network: "Kabelplus DVB-C", mux: "314MHz", provider: "", service: "Raw PID Subscription", hostname="192.168.77.70", username="", client=""
2015-03-31 22:10:32.002 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:34.000 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:36.000 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:38.000 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:40.000 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:42.000 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:44.000 subscription: 000E: No input source available for subscription "SAT>IP" to channel "none"
2015-03-31 22:10:44.682 subscription: 000E: "SAT>IP" unsubscribing, hostname="192.168.77.70", username="", client=""
thanks in advance
Updated by Jaroslav Kysela over 9 years ago
Could you compile tvh with --enable-trace and provide output for "--trace satips,subscription,service,mpegts,http" ?
Updated by Stephan Ramel over 9 years ago
for sure...here is the log.
but in the log was no trace for http...
thx
Updated by Jaroslav Kysela over 9 years ago
The tuning just fails for a reason.
2015-04-01 19:07:27.000 service: 314MHz in Kabelplus DVB-C: Status changed to [Graceperiod expired] [Data timeout]
Unfortunately, you don't have enabled traces in your binary (--enable-trace when you configure tvheadend) and "--trace satips,subscription,service,mpegts,http,linuxdvb -l <output_log_file>" as tvh arguments. I added the linuxdvb subsystem to the list, too. Also, could you show me a working mux setup (from log) for 314MHz ?
Updated by Stephan Ramel over 9 years ago
- File tvheadend.log tvheadend.log added
- File muxsetup_freq314.png muxsetup_freq314.png added
aloha,
here is the new log and the mux setup for frequency 314Mhz.
thx
Updated by Jaroslav Kysela over 9 years ago
I think that I found it:
2015-04-02 10:24:44.718 [ TRACE]:http: rtsp://192.168.77.60:9983/{{CSeq=1}}
2015-04-02 10:24:44.725 [ TRACE]:http: rtsp://192.168.77.60:9983/?freq=314&msys=dvbc&sr=6900&specinv=0&mtype=256qam&pids=0{{CSeq=2,Transport=RTP/AVP;unicast;client_port=52030-52031}}
2015-04-02 10:24:44.725 [ DEBUG]:satips: 0/B72056D9/1: SETUP from 192.168.77.70:44782 DVBC/ANNEX_A freq 314000000 sym 6900000 mod QAM/256 fec AUTO pids 0
2015-04-02 10:25:00.395 [ TRACE]:http: rtsp://192.168.77.60:9983/stream=1?delpids=0{{CSeq=3,Session=B72056D9}}
2015-04-02 10:25:00.395 [ DEBUG]:satips: 0/B72056D9/1: PLAY from 192.168.77.70:44782 DVBC/ANNEX_A freq 314000000 sym 6900000 mod QAM/256 fec AUTO pids <none>
2015-04-02 10:25:00.396 [ DEBUG]:satips: RTP streaming to 192.168.77.70:52030 open
2015-04-02 10:25:00.403 [ TRACE]:http: rtsp://192.168.77.60:9983/stream=1{{CSeq=4,Session=B72056D9}}
2015-04-02 10:25:00.403 [ DEBUG]:satips: -/B72056D9/1: teardown from 192.168.77.70:44782
2015-04-02 10:25:00.403 [ DEBUG]:satips: RTP streaming to 192.168.77.70:52030 closed (streaming request)
See where the RTP streaming starts and stops. There's missing 'PLAY' command from the SAT>IP client. Does really minisatip work?
Could you grab network communication between your SAT>IP client and minisatip ? Use minishark or tcpdump.
Updated by Stephan Ramel over 9 years ago
mmh okay but whats this?
2015-04-02 10:25:00.395 [ DEBUG]:satips: 0/B72056D9/1: PLAY from 192.168.77.70:44782 DVBC/ANNEX_A freq 314000000 sym 6900000 mod QAM/256 fec AUTO pids <none>
is this not the play command?
yeah minisatip works. and the tvh satip also works when i have the channels in my channel list. that means when i have searched for channels over minisatip and then switch to the tvh satip server i am able to watch the channels...thus means for me the play command should be sent by the satip client. weird thing. with which satip client have u tested it?
i check the traffic with some of these tools and load it up here then.
thx
Updated by Stephan Ramel over 9 years ago
i tested it again with minisatip...and what i found is, that minisatip changes the symbolrate to 6111. that means i only get channels at minisatip with this rate.
so i thought that could be the same with tvh...and tried it but with no result. not channels are found.
attached the screenshot of wireshark with the connection to minisatip.
Updated by Stephan Ramel over 9 years ago
- File tvheadend_3.9.2675.log tvheadend_3.9.2675.log added
ah and here the tvh log with the new version.
thx
Updated by Jaroslav Kysela over 9 years ago
Stephan Ramel wrote:
mmh okay but whats this?
2015-04-02 10:25:00.395 [ DEBUG]:satips: 0/B72056D9/1: PLAY from 192.168.77.70:44782 DVBC/ANNEX_A freq 314000000 sym 6900000 mod QAM/256 fec AUTO pids <none>
is this not the play command?
Yes, but look to the time.. It's play command which removes pid 0 and then TEARDOWN is issued. There should be a PLAY command after SETUP (immediatelly).
Updated by Jaroslav Kysela over 9 years ago
Could you attach the whole pcap file for the RTSP communication (your client <-> minisatip) ? Your client sends only SETUP command to tvh, but for minisatip there are PLAY commands. Not sure why.
2015-04-02 12:44:09.850 [ TRACE]:http: RTSP/1.0 OPTIONS rtsp://192.168.77.60:9983/{{CSeq=1}}
2015-04-02 12:44:09.857 [ TRACE]:http: RTSP/1.0 SETUP rtsp://192.168.77.60:9983/?freq=314&msys=dvbc&sr=6900&specinv=0&mtype=256qam&pids=0{{CSeq=2,Transport=RTP/AVP;unicast;client_port=52018-52019}}
2015-04-02 12:44:09.857 [ DEBUG]:satips: 0/56F9BF9B/1: SETUP from 192.168.77.70:3576 DVBC/ANNEX_A freq 314000000 sym 6900000 mod QAM/256 fec AUTO pids 0
here is missing PLAY command, so tvh does not start RTP streaming
2015-04-02 12:44:25.666 [ TRACE]:http: RTSP/1.0 PLAY rtsp://192.168.77.60:9983/stream=1?delpids=0{{CSeq=3,Session=56F9BF9B}}
this play command only removes pid 0
2015-04-02 12:44:25.666 [ DEBUG]:satips: 0/56F9BF9B/1: PLAY from 192.168.77.70:3576 DVBC/ANNEX_A freq 314000000 sym 6900000 mod QAM/256 fec AUTO pids <none>
2015-04-02 12:44:25.667 [ DEBUG]:satips: RTP streaming to 192.168.77.70:52018 open
2015-04-02 12:44:25.675 [ TRACE]:http: RTSP/1.0 TEARDOWN rtsp://192.168.77.60:9983/stream=1{{CSeq=4,Session=56F9BF9B}}
immediate TEARDOWN (shutdown for the session)
2015-04-02 12:44:25.675 [ DEBUG]:satips: -/56F9BF9B/1: teardown from 192.168.77.70:3576
2015-04-02 12:44:25.675 [ DEBUG]:satips: RTP streaming to 192.168.77.70:52018 closed (streaming request)
Updated by Stephan Ramel over 9 years ago
- File pcap_minisatip_706_714.log pcap_minisatip_706_714.log added
- File pcap_tvh_706_714.log pcap_tvh_706_714.log added
well...i found something out.
i did a try with minisatip again...and...dont know why...the first frequency never returns any channels... e.g. the frequency 714Mhz. when i only search for channels on that freq nothing is found, but when i make a range search from 706 to 714, so 714 is the second one, 3 channels are found on 714.
so i did the same on tvheadend. but here even when i do a range search, when 714 is not the first frequency, nothing is found.
attached the logs.
Updated by Jaroslav Kysela over 9 years ago
The client is broken for the first tuning request (the server won't give any data, because the PLAY command was not send). The other muxes should be tuned and RTP packets should be sent. It's not clear from the description, what tvh does in this case. Could you attach also tvh log for the multiple scan (multiple muxes) ?
Updated by Stephan Ramel over 9 years ago
okay i see...what client do u use?
attached the tvh log scanning muxes from 706MHz to 722MHz
Updated by Jaroslav Kysela over 9 years ago
- Status changed from New to Fixed
The behaviour seems ok. I only added a little optimization for low-bandwidth subscriptions (like for pids=0), so the services should be detected for all muxes except the first one in your case (the client bug). The change is in v3.9-2678-gd58afc0 . Closing this bug now.