Video files still being load in background even file isn't viewed anymore

[AykutCevik]

Describe the bug
Playing a larger video selected from the file list within the browser, the viewer opens and plays the video. If you now switch to the next file with the arrow keys you can view other images and videos like any other gallery. But until you close the viewer the videos which you went through or viewed shortly are still being load in the background. This happens until you close the viewer totally. If you now to continue to view several videos it adds up and all these files to the download and not only slows down the whole connection but also increases data usage/traffic.

To Reproduce
Steps to reproduce the behavior:

1. Open nextcloud within your browser and find a folder with several video and image files
2. Click on any video and it opens in the viewer to play the video
3. Switch now to another media file, do this several times if needed
4. See that the previous videos are still being loaded in the background until the whole file is loaded or viwer is closed

Expected behavior
Download of any file should be stopped once the file isn't viewed anymore

Desktop (please complete the following information):

• OS: Windows 10
• Browser Firefox
• Version 88
• NC: 21.0.1

[skjnldsv]

Duplicate of nextcloud/server#8161 maybe?

[AykutCevik]

@skjnldsv not related since this is an issue within the client as it continues to download. The ticket you have referenced seems to be related to the server which still reads the file.

[skjnldsv]

Ah, then I was right the first time: #840

[AykutCevik]

Not sure, your reference is regarding the CPU load, my issue is regarding the network load. Maybe these are related, has to be debugged to find out.

[skjnldsv]

viewer/src/components/Videos.vue

Line 102 in 1e82b23

this.player.pause()

We pause the viewer on prev/next, but we should maybe stop manually the load

[AykutCevik]

@skjnldsv this makes sense for me, at least if stop will also stop it from downloading the file.

[szaimen]

@skjnldsv what happens if you change this.player.pause() to this.player.stop()? Does it stop the video stream correctly?

[skjnldsv]

No idea, but resuming a previous play is a feature, so we must be careful

[pierreozoux]

I commented here, but I can give more details:
since I posted the issue, we updated Nc, optimized php, and increased the number of app servers, and it seems the problem is gone.

[zyphlar]

Based on @szaimen 's suggestion I watched a video until the very end (fortunately it didn't take too long to download) and then I was able to delete the file. Attempting to delete a video I had just partially watched, however, failed multiple different ways beforehand. This was especially irritating when trying to prune multiple large videos to recover storage space, since before this advice I had to reload the page every time I wanted to delete what I'd just reviewed. (The lack of thumbnails for my videos is also a problem here.)

[tgrimminger]

I experience these exact problems with my own nextcloud docker containers.

Problem: very slow stream even locally (no bandwidth concern), very high CPU usage (95-100% while playing video) and extremely high bandwidth usage (saturating the 1Gbit link) between application (nextcloud) server and file server (SMB). This persists about 30s - 1min after attempting to watch a file (MP4, 1-5gb)

What I've tried:

• mount locally (mounted via cifs on the host os)
• mount via smb - external storage
• used Linuxserver.io's image and official
• used mariadb and postgres

I've made partial progress by using an old nextcloud version 15 container - works as it should, low bandwidth usage, low CPU usage.

Amy idea what could cause this? I can't run nextcloud 15 in production because of security concerns ofc.

[pierreozoux]

@tgrimminger did you tune php?

[skjnldsv]

@pierreozoux could you elaborate your php tuning? :)

[pierreozoux]

@skjnldsv If I recall well, this is this https://lab.libreho.st/libre.sh/docker/nextcloud/-/commit/cc95740eb724233559757035cc3f237e8fbdec98
(nothing fancy, but just the defaults are too low, and my intuition was that reading one video was exhausting the php processes)

But you can see our setup here:
https://lab.libreho.st/libre.sh/docker/nextcloud/-/tree/master/base

[skjnldsv]

Nice! Thank you! If it make sense, it would benefit others to edit the documentation 😉

[MadMakz]

Those PHP configs don't solve the issue but rather "delay" them. Processes won't die if player is closed / moved to next file.

You'll end up with a bunch of zombie processes evntually resulting in a complete unresponsive system.

Recently tested with PHP 8.0. (Untested:) You could probably set max_execution_time to a low value, but that'll affect the timeframe you have for uploads (i think)

Processes shown below remain there without any continued user presence on the frontend. (Except for the fpm-status script ofc)

My guess is that those run untill either max_execution_time or maybe EOF is reached.

[Glide01]

@MadMakz Does this mean that PHP 8.0 is the solution?

[kescherCode]

@Glide01 no, it merely means the bug is still present.

[skjnldsv]

Should be force requesting the browser to stop loading any background stream
#1206