-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How does it work? #29
Comments
Sure! I will remake the whole README in the following days. Regarding your question: There could also be the possibility for restreaming several iptv streams, so multiple users can watch different content. If there is demand for such a feature, it will be eventually get implemented. |
While very cool, I personally don't need sync functionality but it could be VERY USEFUL if you could load several accounts for restreaming different content. You could then attach this to gluetun container for proxying/tunnelling all client streams thru a single VPN endpoint (as a workaround for ISP blocking.) Currently using "iptv-proxy" which works well but in order to have multiple accounts you need to spin up a container for each. Many have raised the "multiple provider" request in that project but there's been no movement on it. Thanks! |
I saw that ticket too, and I completely agree—a restream would be awesome! |
You can turn off synchronization in the frontend ⚙️ settings. This will give you faster load times and may increase the performance.
That is indeed possible at the moment! You can load as many playlists or even single m3u8 channels from different sources/accounts as you want.
I mean at the moment, this is rather a restreaming plattform than a proxy. The stream is not only proxied, it is cached in the backend. Thats done because my own iptv provider detected me even when watching in two seperate browser windows at the same time. If you want to restream multiple channels at the same time, this is currently not possible with my solution. As I said, if there is enough demand, I can surely add the possiblity to watch standalone without channel synchronization. (Still have to think about a proper way to integrate this, because the application is majorly designed for synchronization. Ideas are welcome!). Same goes for a only proxy mode. Just tell me what you need and we can find a way to integrate it. |
I finally had time to review this project, and it’s really impressive. However, it’s not quite what I’m looking for. I’m searching for a proxy solution where we can input an m3u8 file with a single-user limit. The proxy would allow multiple clients to connect, but if the limit is reached, it would display a video message informing users that another client is currently watching the stream and to try again later. Additionally, having the ability to set an alternate source for a given channel (a second playlist) would be fantastic. So far, I haven’t found a project that offers this functionality. |
This is exactly what i'm wanting to sort out on my setup, but also with the channel caching to prevent people watching the same channel taking up an additional connection. Big thing for me is I want to run my IPTV via my VPN without having to put Emby behind it too... |
I see, you all need multiple people watching the different channels. There is already an open issue #36 for this. It will be top-priority in the next stage of development.
My application is primarely for bypassing this single-user limit problem by restreaming the stream (use
This sounds interesting. I'll have to think about it, thanks for the idea.
Yeah, caching to prevent using several connections to the source, is exactly what I was aiming to implement with this project initially ( |
Could you add a brief explanation to the README about how IPTV-Restream behaves when the provider allows only one stream at a time, and another user attempts to watch? I understand the restriction comes from the provider, but it would be helpful if, in such cases, a static image could be shown to other clients with a message like:
"Another user is currently watching. Please try again later."
This would improve clarity and user experience when the stream is unavailable.
The text was updated successfully, but these errors were encountered: