Could there be a second package with Live-streaming configured?
-
Ah - doink, sorry about that. Okay, I ticked the box to turn that on. Still not seeing any changes in the app despite the configs being set. We're still missing something, but not sure what it is. Could be my upstream proxy, will try to route around it to test.
-
Sounds like the official apps will be in the apps stores in a month of so.
https://mastodon.social/@pixelfed/110312061392315948
Perhaps those are what is needed to use this?
Presumably everything mentioned in the docs here are now included in the package?
https://docs.pixelfed.org/running-pixelfed/optional-features/livestreaming/
-
@jdaviescoates ah, that's great news. Yes, we have integrated all that's possible. Now, we need something to test it with.
-
I was hoping the testflight (ios) app just started working when the app is configured. I also set the web app to be a broadcaster (it was an option in the configs) but that didn't change anything either. Perhaps he's holding the code back for the next release or something
-
Sorry for my absence - I will go through this thread tomorrow and see what needs to be done because so already was able to stream (on another instance)
-
@girish At the moment you need the Pixelfed Live App to stream. Get the apk here: https://dl.apps.pixelcdn.net/pixelfed-live/android/pixelfed-live-v1.0.1-release.apk
As far as I know it should be merged into the iOS and Android App but I do not know the status at the moment. I asked upstream to provide some more info.
-
@jaschaezra OH! Booooooooo.....
-
Update:
-
Port 1935 is the question for me.
Pixelfed wants to use this port by default for livestreaming, and there is a notification saying that only the default works.
However, a couple of other Cloudron packages want Port 1935, too:
PeerTube (and apparently port 1935 is/was hardcoded into it, so you can't/couldn't change it.)
OwnCast (which will work on port 1936 to allow PeerTube to keep port 1935)So, would Pixelfed livestreams work if you had PeerTube on 1935?
-
URL and hostnames are only available depending on the used protocol. Since we are talking about TCP ports here, this usually does not apply. On Linux only one process can listen on a TCP port.
In the more common HTTP case, a reverse proxy will listen on the port and since it understands the protocol, which has a concept of for example hostnames, it can then proxy the traffic accordingly, but that is rather special to HTTP and thus does not apply to other use-cases, which are not HTTP.
-
-
-
@girish We asked for more licenses because we wanted to separate our services on separate servers, but when we asked for this we got asked why? And to explain how this would be a benefit to us?
For example, we have a server for our websites like this https://www.mhgresource.directory/
But we have websites like this https://www.landingstrip.social that we would like to keep this websites apps on one server to keep them running at all times, and so that it is not interfered with by other apps or server issues.
We wanted to separate mastodons, discourse etc on servers only for that type of app, to help better manage them and so that not all apps are affected by a server issue.
Also got told to upscale servers to compensate by adding more apps, never getting a reply to my answers to the questions I was asked, so we did not chase it up.
But to answer your question no not really, I want to be able to host multiple Pixelfed apps on one Cloudron server.
But if Pixelfed is locked to using the default port only like in the setup instructions,
I don't understand why it says "only default works" and then shows a port range "1024-65535" when Pixelfed says the default port is 1935. It says to the novice that you can use any port between 1024-65535 even though it says about the default being the only one to work.
And can not use other ports or the same port for all Pixlefed apps then it seems like we would have to host each Pixelfed app on a separate server.
Hope this all make sense.
-
I guess the issue here is, that the Cloudron dashboard UI for the port configuration is too generic for this. In theory all ports from that range can be used and this works for many apps, but in reality pixelfed can only use one specific port. There is not really much we can do from the platform side to support multiple pixelfed instances on the same server (not really a Cloudron limitation though).
-
I ran into the same/similar issue recently but with peertube* and pixlefed both wanting the 1935 port, i think i ended up switching peertube to 1936 but have yet to test that it works....
Seems like we should make an upstream request to pixlefed to make the port variable?
-
@nebulon thanks for clearing that up, but for us that is a limitation, we were told that we can run any number of the same app on one server. In reality this is not possible, due to port limitations.
I have used different ports but yet to test them on pixlefed, I need to get around to that.
It's fine if it's mastodon, we have multiple masto instances on one server without issues. But now I do wonder what if mastodon or other apps that might update adding streaming services and let's face it it would not be hard to see it happen or that they would not add simular as streaming is becoming more popular, that it would become a major issue in the future, this would mean that we would have to move all instances to their own server.
This is why I say multiple apps should be able to share a port like RTMP or simular streaming services by using domain/url to direct the stream to the right app on cloudron.
Hope it makes sense, it maybe unrealistic as I don't know much about ports and deeper workings of software etc.. I can just see using some apps for our services are going to be an issue either now a d for some in the future.
This is one of the many reasons for the need of more then one license.
I suppose it is lucky the for the moment cloudron has a free plan allowing two apps, we will take advantage of this.
