Open lars18th opened 3 years ago
Hi,
Can you upload the log?
Thanks
Hi @catalinii ,
I have exact same issue and please I need your support
One HTTP client is connected and receiving the streaming.
The client closes the socket and ask for a new streaming in another transponder using a new socket.
The HTTP closing is processed by the "main" thread, and the same thread receives the new HTTP request... but the "AD1" thread managing the tuner (a satipc module) don't have already closed the tuner. In this case the HTTP response for the new request is "HTTP/1.0 404 Not Found".
Hi @odehalaa ,
Thank you for reporting this. I'm sure the bug exists. However, I can't fix it. Only @catalinii could do it. So please, provide a full debug when the issue appears. Then it will be more easy to fix it.
Regards.
What clients use HTTP for streaming? Why not use RTSP instead if these issues don't occur then?
What clients use HTTP for streaming? Why not use RTSP instead if these issues don't occur then?
Hi @Jalle19 I'll try to explain it: In fact, almost all users use HTTP. For different reasons. Not all software clients have native SAT>IP support, so in several scenarios the only solution is to use the HTTP protocol. For example, why you think the SAT>IP v1.1 Specs has added the HTTP as an optional protocol? For example, when playing using an Android TV device (TV, Chromecast, etc) the RTSP protocol is out-of-scope. Therefore you need to use the HTTP one.
So please don't forget the necessary HTTP support. This is a must have for minisatip. And I hope that @catalinii will fix this bug soon. In any case thank you all for your contributions to this great project! 😃
Alright, I see. I thought everyone used tvheadend or VDR or similar.
I thought everyone used tvheadend or VDR or similar.
🤣 🤣 🤣 Personally I don't want to use TVHE, VDR and similar clients.
The most simple and powefull environment could be this:
multiple SAT antennas (Unicable) -\
Cable coax --+-> some SAT>IP servers (preferable OpenATV) --> minisatip server ==> Clients
Terrestrial antenna -/
And then clients could be AndroidTV, VLC, WMC, ... Native RTSP or HTTP, doesn't care the protocol here!
So people have regressed from using proper TV backends with EPG data, recordings and channel groups to using raw HTTP URLs and VLC? :thinking: I'm surprised.
So people have regressed from using proper TV backends with EPG data, recordings and channel groups to using raw HTTP URLs and VLC?
No, no! For EPG data you can use scrappers and get the data in XMLTV format. This format is supported by AndroidTV and other IPTV tools. In fact, the TVHE is a huge software that injects anything, generates XMLTV EPG and share channels using (usually) TCP. And regarding the VDR... I prefer a simple OpenATV STB with SAT>IP client support. However, if you want to have PVR functionality I prefer minisatip(source)+WMC(backend)+NovaVideoPlayer(player).
In less words: Let users to use what they prefer! 😉
@lars18th I willneed the logs in order to fix the issue
Hi @catalinii ,
Finally I've discovered why in some cases the a channel change doesn't work. This appears when using HTTP clients, and not when using the regular SAT>IP commands (PLAY with new tunning parameters).
The trouble appears when:
I'm not sure if this case appears using internal tuners (I only use minisatip with the satipc module). But in the LOGs I see that the function "detect_dvb_parameters" is called from the "main" thread when receiving the new HTTP request. And after this call the "get free adapter" fails over the same thread. So I feel some flag indicating that the tuner will be closed is missing. What you think?
Regards.