Pagination unstable release question

Can someone shed some light on pagination unstable release? Which unstable have the Pagination code?
What do we expect to see when we’re testing? What is the “Tile view” behavior when testing hiding video thumbs for non-video?

1 Like

The pagination is already deployed on meet, you can test it there, you should not see any difference in general

3 Likes

This is awesome news!
Do you know how many tiles is set per page? Is this available in the latest unstable for testing?

Thank you @damencho
This is great news! Can you please elaborate on the hiding video thumbs for non-video? this issue: https://github.com/jitsi/jitsi-meet/issues/7687

I believe with pagination a large meeting with say 500 users can be conducted?

Yes.

We haven’t added some participants reordering for now.

Yep, that’s latest unstable and on meet.jit.si. The versions on meet.jit.si are RC for stable and are now in the testing repository.

3 Likes

Hello @damencho,

After this update, what is the realistic estimate for a maximum number of participants in a single room without octo if we have no resource limitations (like CPU, bandwidth etc)?

Not sure …

1 Like

Can we test pagination on meet.jit.si? I have created a meeting and joined 25 people, I couldn’t see any different usage from the previous build.

Am i doing something wrong? Or in a different test environment where I have to create a room for pagination testing?

You’re not going to see anything different per se in the UI for now, but you will be able to host meetings with up to 500 people. So the ‘test’ would be to try running a large meeting.

is this already available in last stable? and can it be used without using Octo , meaning single server have no constraint on cpu, memory and bandwidth.

What I understood from Pagination is that, as in Webex, no matter how many people are in the meeting, only the videos of the people in a certain window (lets say 6 people) will be sent from the server to the client. Thus, an optimization will be provided in the client’s cpu and data consumption.

Therefore my main expectation from Jitsi is to provide an optimization on the client side. Because my server installation I use now support more than a hundred people in a meeting without using OCTO. But in such a case, the client side has serious problems.

No, this has not rolled out to stable yet. You can try it on meet.jit.si.

Your understanding is correct. Only requested endpoints in the visible area are rendered with pagination.

Here, I understand that the user proceeds by selecting the users specifically. If so, it’s different from the usage in webex. Because in a meeting of 300 people in webex, there are 50 pages according to 6 windows size. And the user doesn’t particularly bother choosing one.

What do you mean? The user doesn’t do anything with pagination. What pagination does is that it only renders events for the tiles of users within the visible area. If the user scrolls through, then the events for the new visible area are rendered. Perhaps you’re thinking of a forward button to move to the next page instead of the scroll?

Ok it is clear now.
How many people has to be on a page right now? Because when I tried with 25 people, no second page appeared.

I’m unsure of the exact number, but I believe once you hit 30 or so, you’ll need to scroll down for more tiles.

Can this number of people in a page be adjusted parametrically? For example, Can I make a fixed number of people appear on the page? lets say 6,7. Otherwise 30 people in a page if they all enable video streaming, client cannot be handle traffic.

You can set channelLastN in your config.js to govern how many videos to show.