Why there is a considerable delay for any stream to start compared to using STB portal directly about stb-proxy HOT 12 CLOSED

I think the main reason is because I do not cache the channel data.
Each time you switch channel it...

• Gets a fresh token (fast)
• Requests the channel list (slow)
• Finds the channel matching the ID you requested (fast)
• Gets the cmd (fast)
• Requests the stream link (fast)
• Stream is tested with ffprobe (fast)
• Working stream passed to ffmpeg to stream (fast)

The bulk of the time is spent requesting the channel list data. Sometimes depending on response times etc, the normally fast tasks can be slower too. Perhaps in the future I will store the channel data locally. But how long does the info in it stay valid? Does anyone know if the cmd (used to request a stream) ever changes?

To be honest I never noticed the time because I am used to a motorised dish and I don't channel hop. I use the EPG to decide which channel to tune.

from stb-proxy.

Do you happen to have a link to STB portal API documentation? I want to write a similar script that connects to STB portal, gets the channel's link and that keeps the link working by keep sending keep-alive requests, but I don't have any information about how often should the keep-alive requests be sent or what are the available API methods etc.

I could use wireshark to investigate what an actual STB Emulator is doing, but a proper API documentation is better.

How did you learn about these methods yourself? I searched the entire web and I can't find a lot of information concerning this.

from stb-proxy.

I used one of those daily-free-stb-codes sites to get some accounts, then just used wireshark to see the requests.
I never found any documentation and some servers require additional steps that others do not, like requesting the profile before they allow you to get the channel list etc.

If there is a keep alive request (I think I saw one app using it), I wonder what happens if multiple people log in with the same mac?

from stb-proxy.

I honestly don't know. I'll will be delving deeper into stb portal in the upcoming days, if I figure that out, I will let you know.

I guess I will also be use a similar method, but instead of Wireshark I will be using Mitmproxy or Mitmweb as it also support https, so I can get the full picture of what stb portal app is doing instead of just http requests.

Another thing. I was running Stalker Client Kodi addon and I logged in with my account, and I decided to open the stream in external app VLC, when I go to the information tab in VLC, I can view the streaming link, but if I stop the stream and copy that link and past it into VLC again, it doesn't work. Do you know why that happens? I want to have similar thing where my application will get the working link and send it to device where I will be consuming the stream, but I want to know why pasting the link directly to VLC doesn't work.

Also why does your script generates m3u playlist with links from localhost, why doesn't it use the link that it get from stb portal directly, I mean the link with the play token at the end, is this because that link may expire and you want to renew it directly from your script so the stream doesn't get broken when the token gets expired or what exactly?

from stb-proxy.

The channel list provided by the server doesn't contain links. Instead it contains the cmd you need to request the link. All servers behave a little different but basically the link is throw away. This is why the m3u connects to the machine running STB-Proxy passing the channel id. This is so it can request the real link and stream it back. If you look at the old branch of this repo you can see that it can just return the real url with a redirect instead of using ffmpeg.

from stb-proxy.

I had a quick look today and some servers (specifically ones that don't host the channels locally) change the cmd that you need to request the real stream link. This might be because I use a fresh token on each request. We'll have to see how the keep alive thingy works if you can find it. I think I have only seen 1 app use it and I cant remember which one it was. Since it sounds like you have a real box, its probably best to look at what its doing instead of any apps.

from stb-proxy.

I actually don't have a real box, I will be using an Android app called "OTT Navigator IPTV" which seem to run any server quite well.

I have just finished setting up an old tablet that I had laying around, I had to root it so I can install a custom CA certificate so I can see what the app is doing through both http and https request so I don't miss anything important.

Yes I will let you know if I find anything about the keep-alive requests, I can't remember exactly where I read about it, maybe it was one of the projects similar to yours here in Github, I can't recall exactly.

from stb-proxy.

Concerning your comment about the old Branch that used to return real URL instead of using ffmpeg. Can I ask you why did you make this change? Was there something not working by just using URL redirect? also in the current implementation, what are you exactly using ffmpeg for?

from stb-proxy.

I cant/dont know how to occupy an account without using ffmpeg since I don't know if someone stops viewing a link if I just send a redirect. Its not the end of the world since the default ffmpeg command uses basically no CPU as it just restreams the stream with the same codecs. Its important to not reuse a mac address for me since more than one person can be viewing at the same time. Once you start streaming a second channel on the same MAC, the first streams link will break and stop working. Sometimes this happens almost instantly, sometimes after ~60 seconds, depends on the server. Previously with the old version I just ran multiple instances of STB-Proxy for each person/TV. I wanted to handle it all in one instance and thats where we are today.

from stb-proxy.

@movianlost check Proxyman software it's avalaible for both MacOS and Windows perhaps it's en beta for windows, but it's well better then whireshark, and allow you to see the url instead of the IP and etc.. it's much simpler.

from stb-proxy.

From my tests, there is a very considerable amount of delay happening through the testStream function (I used the timebudget library for these checks):

           testStream: 2946.17ms for      1 calls
       getAllChannels:  787.96ms for      1 calls
             getToken:  273.79ms for      1 calls
              getLink:  135.37ms for      1 calls
           getProfile:  129.92ms for      1 calls

So if you don't need the fallback function, youcan simple disable the testStream() (return True at the beginning of the function) and get 3-4s faster zapping time.

Furthermore I found out that it can be more efficient to use simply use wget instead of ffmpeg for streaming through

        ffmpegcmd = [
                "wget",
                "-O", "-",
                "-o", "/dev/null",
                link
            ]

By changing these two points I get a pretty good zapping time with about 1s.

I also did some tests with the lru_cache library. You just import it and make a

         @lru_cache(maxsize=32)

in front of some of the functions in stb.py. However, just using for getAllChannels is not enough, you also have to cache the getToken function as otherwise you get different token Parameter for getAllChannels and then you get a cache miss. For me, the caching did work without problems so far. But maybe one could clear the cache once a day or so.

from stb-proxy.

The test numbers you have there will be more exact than me just counting between prints, but what I do know is different servers are slower or faster at different functions.

In my testing, using the requests library for the test function shaved off roughly 1-2 seconds on most servers.

def test(url):
        try:
            with requests.get(url, headers=headers, proxies=proxies, timeout=timeout, stream=True) as r:
                for chunk in r.iter_content(chunk_size=1024):
                    if chunk:
                        return True
        except:
            pass
        return False

I'm worried that not all servers will work with it though, even with the user agent set to ffmpegs.

I am not sure about caching. I am not against it but I am not sure how to do it elegantly. If another person is using the same account/s as you, when they handshake, your cache is now no good. So the cache would need to be tested each time.

EDIT: Its important to know that broken stream link often report a 200 status code, so actually looking for data is important when testing.

from stb-proxy.