catalinii / minisatip

minisatip is an SATIP server for linux using local DVB-S2, DVB-C, DVB-T or ATSC cards
https://minisatip.org
331 stars 81 forks source link

BUG: Not free adapters when fast changes #813

Open lars18th opened 3 years ago

lars18th commented 3 years ago

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:

  1. One HTTP client is connected and receiving the streaming.
  2. The client closes the socket and ask for a new streaming in another transponder using a new socket.
  3. 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".

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.

catalinii commented 3 years ago

Hi,

Can you upload the log?

Thanks

odehalaa commented 2 years ago

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".
lars18th commented 2 years ago

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.

Jalle19 commented 2 years ago

What clients use HTTP for streaming? Why not use RTSP instead if these issues don't occur then?

lars18th commented 2 years ago

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! 😃

Jalle19 commented 2 years ago

Alright, I see. I thought everyone used tvheadend or VDR or similar.

lars18th commented 2 years ago

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!

Jalle19 commented 2 years ago

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.

lars18th commented 2 years ago

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! 😉

catalinii commented 2 years ago

@lars18th I willneed the logs in order to fix the issue