banister

RE: Changing storage from external back to Local.

Previously recorded here by @Wise: Also, you must manually move files, and manually set database for storage engine. UNA will NOT switch from Local if a file exists.

You must move them. Then goto storage database and change the engine manually.

Question: What is this database table called? I can't find it. I have, of course, changed these values in the UNA general Settings, in the Storage section.

THANK YOU!

@PavelS was discussing the big server hit for video processing in a previous post. This issue warrants a separate thread, imo.

Perhaps someone could turn this idea into a mod or even build it into future versions of UNA. The UNA developers host their own servers but still they have made a path for remote video processing, which is certainly going beyond the call of duty.

Here's a short overview of how linux and/or ffmpeg can be adjusted, courtesy of Google. Obviously, in a shared environment, server modifications are limited. Please let us know if your own experimentation produces good results.

1. Using OS-level Commands (Recommended on Linux)

These tools help manage how much of the server's resources the FFmpeg process can consume, which is the best approach for a shared environment. 

• nice: This command adjusts the CPU priority of a process. A higher "niceness" value means lower priority, so the process will run in the background when other tasks need CPU time.
• bash

nice -n 19 ffmpeg -i input.mp4 [other ffmpeg options] output.mp4

• (A niceness of 19 is the lowest priority).
• cpulimit: This utility can explicitly limit the percentage of CPU usage for a process. You will likely need to install this tool if it's not available.
• bash

cpulimit -l 50 -- ffmpeg -i input.mp4 [other ffmpeg options] output.mp4

• (The -l 50 option attempts to limit the process to 50% of one CPU core's capacity. The value depends on the number of cores available; consult the cpulimit documentation for the correct value for your server).
• Combining nice and cpulimit:
• bash

nice -n 19 cpulimit -l 50 -- ffmpeg -i input.mp4 [other ffmpeg options] output.mp4

• (Make sure to add the -- before the FFmpeg command if using cpulimit).
• taskset: This command can confine a process to specific CPU cores.
• bash

taskset -c 0 ffmpeg -i input.mp4 [other ffmpeg options] output.mp4

• (This runs FFmpeg only on the first core (core 0)). 

2. Using FFmpeg's Built-in Options

You can also use options within the FFmpeg command itself to reduce its resource demands. 

• -threads: This option (when placed after the input file) can limit the number of threads FFmpeg uses for encoding. Setting it to 1 can significantly reduce CPU load, though it might not always strictly limit to a single core for all codecs.
• bash

ffmpeg -i input.mp4 -threads 1 [other ffmpeg options] output.mp4

• Encoding Presets: Using a faster encoding preset reduces the computational complexity of the encoding process, thus using less CPU per frame, though this may impact quality. Presets range from "ultrafast" to "veryslow".
• bash

ffmpeg -i input.mp4 -c:v libx264 -preset fast [other ffmpeg options] output.mp4

3. General Considerations

Run Processes in the Background: Use job management systems (like message queues or simple shell job operators like &, wait) to manage multiple concurrent FFmpeg tasks. This prevents new encoding jobs from launching until previous ones are complete or resources are available.

Avoid Concurrent Runs: The core problem with shared hosting is often multiple FFmpeg instances running simultaneously. Implement logic to ensure only one (or a limited number) of FFmpeg processes runs at any given time.

Check Server Limits: Be aware of the specific CPU and memory limits imposed by your shared hosting provider. Maxing these out can lead to your processes being terminated or your account suspended. 

From the UNA Wiki we read about remote video transcoding: Install UNA on separate server(s), but connect to the same DB which your main site is using.

What does a path for this connection like this look like, using example.com as the main UNA server instance?

Does this path belong in the inc/header file of the remote server along with similar transcoding settings? Where might that be?

Ubuntu 24.04 LTS and MariaDB 11.4

Any hiccups?

One quick question... Over the years, I have seen kind members of this forum offer to "give back" and allow other sites to use their Jitsi servers. Is this really possible or practical? It seems like some of the UNA / Jitsi integrations could be "broken" from one url to another.... Settings, memberships, events, etc.

Surely, these kind individuals were talking about more than just testing their new Jitsi servers. Right?

So. Please confirm that more than one UNA site (sites and urls which I control) can access both features (jitsi meet and video transcoding) on a SINGLE external server. IF I control both servers and have them properly configured in the settings and in the inc/header.inc.php file.

In other words, I have TWO UNA sites on one server which I want to use with ONE remote (unmanaged) server for these two purposes. The two purposes which are not possible on a shared hosting plan. Due to resource constraints.

Thank YOU.

Hi All. I've added the app ID and secret for Jitsi in the Messenger settings. Now I get an "exp" authenitication error. How can I get beyond this? It relates to time expiration, no doubt. Part of the token payload, it appears.

The UNA call identifier in the photo below? Does that number actually correspond to my own site? UNA 333Cc6870758486893.... ???

I just need an instance of Jitsi for a few people. Surely with all the Jitsi integration work already done by UNA devs, this is doable.

I asked TMD Hosting about self-hosting a Jitsi server but they said that my plan (over $650 per year) did not qualify.

I just need to get the free version going for now. Thank YOU.

Jitsi has been discussed here for about 5 years. Most questions on the subject were answered but many were not. Yes, we know that Jitsi has changed their usage terms over this timeframe. And like every other internet thing, it becomes a moving target.

Needless to say, today's social site users expect easy to navigate, seamless video of all kinds. If they don't find it, they will keep moving on to sites which do.

Users, however, have no idea how complicated coding is for internet video, audio, and streaming... For example, the video engine here on UNA is based on FFmpeg - which has dozens of pages of just settings. The documentation would fill a large book.

Anyway, it appears that UNA did the heavy lifting and successfully integrated Jitsi into their Messenger app. At present, it connects for video calls which are subject to a five minute limit. A link is provided to "Jitsi As a Service" or JAAS and there is an offer for a free "starter package". The free service is limited to a small group of users, of course. Which is much, much better than nothing.

So for self-hosters, the question is: How do the Jitsi required settings correspond or interface with those in the Messenger settings? I cannot get them to work. Jitsi states that: "All you need to do is to copy the integration code snippet and paste it into your app or website." 

I realize that for the full video services a dedicated server with ample resources is needed. So, I guess the free service is the iFrame variety. But how? And why does it seem so complicated?

Hello dear Unitarians. Several times a year, the Messenger app fails. Connections do not connect. Usually a server restart fixes this issue. Yesterday, it did not. Leading me to ask: Does the Jotserver itself need to be restarted in addition to the server restart?

I checked the certificate. It looked OK. Any ideas why jotserver fails about every 3 months? We're hosted by TMD, by the way.

In the php error log, I see but cannot interpret: .... modules/boonex/messenger/classes/BxMessengerTemplate.php on line 1591[10-Dec-2024 15:02:20 UTC] PHP Deprecated: Implicit conversion from float 1.1333333333333333 to int loses precision in 

This error appears more like a visual template issue than one relating to connectability.

Hello all you UNAtarians. I receive warnings every few weeks from bug bounty hunters. They tell me that the phpinfo . php page makes the site vulnerable to exploitation.

Is this true? Should this page be hidden?