**Adaptability **
To enable a player to adapt to the bandwidth of the network, the original video is encoded in several distinct quality levels. The server serves an index, called a "master playlist", of these encodings, called "variant streams". The player can then choose between the variant streams during playback, changing back and forth seamlessly as network conditions change.

https://en.wikipedia.org/wiki/HTTP_Live_Streaming#Adaptability

The webtorrent selection UI in the settings is a bit odd (and the peertube documentation has no search functionality), so your writeup should hopefully help any future travelers figure it out.

I was able to find the the relevant section in the Peertube Docs now that explains these options a bit. HLS is actually the recommended setting by them as well:

We recommend you to enable HLS (and disable WebTorrent if you don't want to store 2 different versions of the same video resolution) because video playback is really better

https://docs.joinpeertube.org/admin-configuration?id=webtorrent-transcoding-or-hls-transcoding

I wonder why I haven't hit this issue then?

P2P and Webtorrent is on by default. If I open up your video it plays nice even if it does not have direct/instant download speed but you seem to have Webtorrent disabled and use HLS instead. Try something with more bitrate like a 4K or FullHD file with 10-25mbit. Does it still work well? (I would assume yes)

There are different player modes depending on the P2P/Webtorrent/HLS settings (right click a playing video and choose stats for nerds to see player modes):

Player-Mode: HTTP
P2P: deactivated
--> Plays instant and nice but does not follow the approach of Peertube because of no P2P. This is what I considered as a workaround or "stable" default but it is not really desirable.

Player-Mode: p2p-media-loader
P2P: activated (or disabled in some cases?)
--> @jdaviescoates this is what your instance does. Seems to work and supports P2P so if there are no other peers, the video is downloaded just from your server. This should work for everyone and I would consider it as a good default option.

Player-Mode: webtorrent
P2P: activated
--> This is the default configuration and it does not work well. Slow download and unplayable. There is also a difference if you're logged in or not. I opened a video in 5 different browser windows --> got 5 peers --> video started to download/play nicer for "everyone" but still really slow. Without another peer connected, the download is terrible (20-150kbs) so the feature works but heavily relies on federation and multiple peers which is not suitable for starters or stand alone instances.

Explanation at the offical documentation about webtorrent/HLS streaming.

You can find the UI configuration for the features here:

I would recommend to turn webtorrent off unless you have a huge federation and a lot of peers. Not sure if it would be okay to enable HFS as default since it requires ffmpeg but it is recommended.

@girish I think the docs (Disable P2P) should be adjusted since we now know that it is webtorrent and not P2P (also possible through WebRTC) in general. You can turn off webtorrent within the UI but you need to restart the app afterwards (or at least it did not switch instantly for me). The biggest problem with webtorrent on as default is that files that were uploaded with "webtorrent on / HLS off" still are "unplayable" after switching the settings. They need to be reencoded and I'm not sure if this triggers automacially or at all. I tested the behavior with two files and different settings enabled.

Another hurdle: From this point, all the following keys can be overridden by the web interface ~~ the modification of the following keys will have no effect starts at L360 in the example yaml. However in my production.yaml (Cloudron app) it is at L162 so you could end up doing configuration that gets ignored.

@girish said in Unusably Slow Playback on Peertube??:

Thing is we don't generally touch upstream defaults

Thats a fair position. Though, I have installed a fresh peertube on my private Cloudron server, gave it enough ressources and was able to reproduce the problem. Normal playback is not possible out of the box and the P2P functionality seems to be the culpid. P2P works within your browser and my public (client/browser) IP is displayed correctly but I still think it has something to do with the way Cloudrons setup works.

Since I as a user assume that every app in the Cloudron store works without further configuration, I see a problem here. I wonder why this wasn't noticed earlier, since the P2P defaults have been in peertube for over 3 1/2 years and the app is not new at Cloudron. To make my point: Just because it works upstream as a default, does not necessarily mean it works for us ^^

I wonder why I haven't hit this issue then? Pretty sure I've not done anything to turn P2P stuff off on https://video.uniteddiversity.coop

Thing is we don't generally touch upstream defaults

Thats a fair position. Though, I have installed a fresh peertube on my private Cloudron server, gave it enough ressources and was able to reproduce the problem. Normal playback is not possible out of the box and the P2P Webtorrent functionality seems to be the culpid. P2P works within your browser and my public (client/browser) IP is displayed correctly but I still think it has something to do with the way Cloudrons setup works.

Since I as a user assume that every app in the Cloudron store works without further configuration, I see a problem here. I wonder why this wasn't noticed earlier, since the P2P defaults have been in peertube for over 3 1/2 years and the app is not new at Cloudron. To make my point: Just because it works upstream as a default, does not necessarily mean it works for us ^^

I will put this in our docs.

face palm on my part for not looking directly for a config file to turn off federation....

Thanks for the lift @subven This came up big!

Download speed is around 51-61KB and it does not play play well at all (30 second 18mb file).

Got it working on the Cloudron demo instance! Go into file manager and edit production.yaml. This is what I changed:

- line 123 --> accept_from: 'nobody'
- line 201 --> enabled: false
- line 238 --> enabled: false

line 130:

tracker:
  # If you disable the tracker, you disable the P2P aspect of PeerTube
  enabled: false

After disabling the tracker (and peertubes P2P function), download speed was instant and every video played just fine. If this works for you, this might be the solution! Ressource usage was standard - app memory at 512mb and redis at 150mb. No other changes made.

I did something nasty...installed a Peertube on the Cloudron demo server and uploaded a video Download speed is around 51-61KB and it does not play play well at all (30 second 18mb file). Okay after some minutes passed I got 1mbit download speed with Chrome after a page refresh but this might be because of caching. You can check it out here until someone purges the instance ^^ I know this deployment is the worst case scenario but at least I have a fresh instance that somehow behaves the same like you described.

It's definitely not the device or the network—the clip kindly provided by @jdaviescoates downloads and plays just fine on same network/machine.

No sign of crash notifications. The app is responsive, the download speed of the video is just slow.

If your app crashes because of memory (OOM), Cloudron would notify you. If something is going wrong with your Peertube instance, the apps logs would show it. We try to think methodically and look for answers at the right spots other then guessing. Many times, the answer is blank obvious and most of the times just user error.

Only bottlenecks I can think of are:

1. memory( i would think this would show up in the usage graphs)
2. cpu
3. disk i/o ( Vultr advertises SSD)
4. network connection ( seems unlikely)

CPU seems the most likely culprit. Server has "4 vCPUs", CPU usage chart shows a spike from 18% to just under 30%:

Outside of my expertise here, but I believe by default Docker containers are single-threaded. On Cloudron I've got processor resource availability set to 100%, but perhaps it's possible this gets "under-reported" in the Vultr CPU usage chart because it's actually maxing out 1 of the 4 "vCPUs", but the PeerTube process is nonetheless maxed out......that's my current remaining feeble idea.

I'll open a ticket with Vultr as well.

On your instance I can see the download speed spike to a more reasonable speed to get the video buffered as shown on the peertube interface:

This doesn't happen with mine.

So unless there was some sort of configuration that you improved (i haven't been able to find anything in the Peertube Admin), so at least thanks to your help we've ruled out that it's something to do with the basic function of Peertube.

https://video.uniteddiversity.coop/w/9346Si65wcjFCRuGWquPEz