Trouble playing videos on web interface using Firefox

Nextcloud version (eg, 20.0.5): 23.0.2
Operating system and version (eg, Ubuntu 20.04): Debian 11 (Bullseye)
Apache or nginx version (eg, Apache 2.4.25): lighttpd 1.4.59
PHP version (eg, 7.4): 8.0.16

The issue you are facing:

If I click an mp4 video from the file browser or gallery to view it, I will almost always get an error: ‘Error loading <filename.mp4>’. Smaller mp4 files (<25MB or so) will play correctly sometimes, but larger ones almost never do. If the sidebar is open, sometimes I’ll get an error toast ‘Server connection lost.’ I am able to download the files no problem, and there are correct previews generated for them. Sometimes if I click a file, I’ll see one frame (like what’s shown in the preview) for an instant before the error message appears.

There are no new lines in the Nextcloud log file when this happens. The error message happens very quickly, not like it’s timing out or anything. I have a very fast and reliable connection with the server.

INTERESTING NOTE: If I have a directory with multiple mp4 files, I can click any one of them, and whether or not it successfully plays, if I go to the next video by clicking the > or < arrows on the sides of the screen, the videos seem to play just fine. For example: I have a directory with 5 videos in it, and no other files. I can click any one of them, and maybe it will play or (probably) it won’t. Then if I click the right arrow, I can play all 5 of the videos no problem, just looping through them, but if I click the X to exit the player and just click another video, I’ll probably get the error.

There’s an error that pops up in the lighttpd error log when this happens (pasted below). But, related to the interesting note above: if I click on a video and it plays without error, I don’t get the lighttpd error message; if I click on a video and see the error on the screen, lighttpd throws the error message. BUT if I click a video and then go to the next one using the arrow buttons, the lighttpd error happens sometimes, but not always, even though the video plays successfully every time.

Is this the first time you’ve seen this error? (Y/N): Yes

I have a second NC 23.0.2 instance running on a different computer (on CentOS instead of Debian, plus various other differences) and don’t see this behavior. I can also play the offending videos just fine from the Android app.

Steps to replicate it:

  1. Have a directory with multiple mp4 video files, ideally >25MB
  2. Click one of the video files in the web interface to view it (likely failure in my case)
  3. Click the > or < buttons to increment to the next video file (guaranteed success in my case)

The output of your Nextcloud log in Admin > Logging:

(Nothing shows up in the Nextcloud log when this happens)

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'gibberish',
  'passwordsalt' => 'gibberish',
  'secret' => 'gibberish',
  'trusted_domains' => 
  array (
    0 => 'my.domain.com',
  ),
  'datadirectory' => '/data/nextcloud',
  'dbtype' => 'mysql',
  'version' => '23.0.2.1',
  'overwrite.cli.url' => 'https://my.domain.com',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'gibberish',
  'installed' => true,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'redis' =>.
  array (
    'host' => '/run/redis/redis-server.sock',
    'port' => 0,
  ),
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'default_phone_region' => 'US',
  'allow_local_remote_servers' => true,
  'theme' => '',
  'preview_max_memory' => 6144,
  'enable_previews' => true,
  'enabledPreviewProviders' => 
  array (
    0 => 'OC\\Preview\\PDF',
    1 => 'OC\\Preview\\Image',
    2 => 'OC\\Preview\\Photoshop',
    3 => 'OC\\Preview\\TIFF',
    4 => 'OC\\Preview\\SVG',
    5 => 'OC\\Preview\\MP3',
    6 => 'OC\\Preview\\Movie',
    7 => 'OC\\Preview\\MKV',
    8 => 'OC\\Preview\\MP4',
    9 => 'OC\\Preview\\AVI',
  ),
  'loglevel' => 2,
  'maintenance' => false,
  'mail_smtpmode' => 'sendmail',
  'mail_smtpsecure' => 'tls',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'admin',
  'mail_domain' => 'my.domain.com',
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' => 
  array (
  ),
  'twofactor_enforced_excluded_groups' => 
  array (
  ),
);

The output of your Apache/nginx/system log in /var/log/____:

A representative lighttpd error that comes up in lighttpd’s error.log:

2022-03-14 19:20:17: chunk.c.891) open failed: /tmp/lighttpd-upload-s0o1up: No such file or directory
2022-03-14 19:20:17: connections.c.466) connection closed: write failed on fd 12

… as a note, the web server is able to write to /tmp. /tmp is mounted with options like NOEXEC so to be sure, I created another temp directory with no unusual restrictions, pointed lighttpd to it (with server.upload-dirs in the lighttpd config file) and re-tested, with no change in behavior. Also, as noted above, sometimes playing videos works on the first try and this error isn’t generated; also, sometimes the error happens even if the video plays successfully using the > or < buttons.

The huge preview_max_memory in the config.php file above is something I added during troubleshooting, but the previews all get generated without any problems.

Any hints would be appreciated! I’m especially interested in what the difference might be between clicking a thumbnail to view the video vs clicking the > arrow to view it. If there’s some difference there maybe that will help identify where to look next.

Thanks!

Hi all,

I guess nobody had any ideas on this 6 months ago but I am hoping that maybe today someone has a thought? This server is now running Nextcloud 24.0.3 (yes I need to upgrade) with php 8.1.9, but still has the same problem playing videos.

As before, the only error message on the server side that I get is the one generated by lighttpd that a temporary file failed to be read/written.

Also as before, two other servers (running CentOS 7 instead of Debian 11) play the same videos just fine, and I can play the video using the Android app from the offending Debian server with no problems; it’s only the web interface on the Debian server that gives a problem.

A new bit of information: I watched the Javascript console on the browser while I tried to play the video.

On one of the older CentOS servers, this happens without drama: in the console I see a message from Viewer.vue:

"Opening viewer for file [file]"

On the offending server, I get a bunch of additional stuff:

[INFO] viewer: Opening viewer for file  
Object { app: "viewer", uid: "elliott", path: "[path]" }
ConsoleLogger.js:33:16
HTTP “Content-Type” of “video/3gpp” is not supported. Load of media resource [url] failed. files
Error loading [path] 
error { target: div.plyr.plyr--full-ui.plyr--video.plyr--html5.plyr--fullscreen-enabled.plyr--paused.plyr--stopped, isTrusted: false, detail: {…}, srcElement: div.plyr.plyr--full-ui.plyr--video.plyr--html5.plyr--fullscreen-enabled.plyr--paused.plyr--stopped, currentTarget: div.viewer__file--hidden.viewer__file
, eventPhase: 3, bubbles: true, cancelable: false, returnValue: true, defaultPrevented: false, … }
Mime.js:98:11
[DEBUG] viewer: Closing video stream 
Object { app: "viewer", uid: "elliott", filename: "[path]" }
Error loading [path]
error { target: div.plyr.plyr--full-ui.plyr--video.plyr--html5.plyr--fullscreen-enabled.plyr--paused.plyr--stopped, isTrusted: false, detail: {…}, srcElement: div.plyr.plyr--full-ui.plyr--video.plyr--html5.plyr--fullscreen-enabled.plyr--paused.plyr--stopped, currentTarget: div.viewer__file--hidden.viewer__file
, eventPhase: 3, bubbles: true, cancelable: false, returnValue: true, defaultPrevented: false, … }
Mime.js:98:11
[DEBUG] viewer: Closing video stream 
Object { app: "viewer", uid: "elliott", filename: "[path]" }
Error loading [path]
error { target: div.plyr.plyr--full-ui.plyr--video.plyr--html5.plyr--fullscreen-enabled.plyr--paused.plyr--stopped, isTrusted: false, detail: {…}, srcElement: div.plyr.plyr--full-ui.plyr--video.plyr--html5.plyr--fullscreen-enabled.plyr--paused.plyr--stopped, currentTarget: div.viewer__file.viewer__file--active
, eventPhase: 3, bubbles: true, cancelable: false, returnValue: true, defaultPrevented: false, … }
Mime.js:98:11
[DEBUG] viewer: Closing video stream 
Object { app: "viewer", uid: "elliott", filename: "[path]" }
HTTP “Content-Type” of “video/3gpp” is not supported. Load of media resource [url] failed. files
HTTP “Content-Type” of “text/html” is not supported. Load of media resource https://data.osdap.com/index.php/apps/files/blank.mp4 failed.

This is the same exact video that plays successfully on the other server. An interesting point is that the video format is not 3gpp? VLC says it’s “H264 - MPEG-4 AVC (part 10) (avc1).”

I turned on all of the lighttpd logging I could find but don’t see anything helpful preceding the temporary file failure:

2022-09-20 11:35:40: mod_access.c.139) -- mod_access_uri_handler called
2022-09-20 11:35:40: gw_backend.c.2571) handling it in mod_gw
2022-09-20 11:35:40: h2.c.1788) fd:16 id:81 resp: :status: 206
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-powered-by: PHP/8.1.9
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: expires: Thu, 19 Nov 1981 08:52:00 GMT
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: cache-control: no-store, no-cache, must-revalidate
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: pragma: no-cache
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: referrer-policy: no-referrer
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-content-type-options: nosniff
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-frame-options: SAMEORIGIN
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-permitted-cross-domain-policies: none
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-robots-tag: none
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-xss-protection: 1; mode=block
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: content-security-policy: default-src 'none';
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: content-type: video/mp4
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: last-modified: Tue, 05 Jul 2016 22:40:50 GMT
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: etag: "gibberish"
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: content-length: 7735913
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: content-range: bytes 0-7735912/7735913
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-request-id: gibberish
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: oc-etag: "gibberish"
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-debug-token: gibberish
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: content-disposition: attachment; filename*=UTF-8''[filename]; filename="[filename]"
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: x-accel-buffering: no
2022-09-20 11:35:40: h2.c.1777) fd:16 id:81 resp: strict-transport-security: max-age=63072000; includeSubdomains;
2022-09-20 11:35:40: h2.c.1788) fd:16 id:81 resp: date: Tue, 20 Sep 2022 16:35:40 GMT
2022-09-20 11:35:40: h2.c.1788) fd:16 id:81 resp: server: lighttpd/1.4.59
2022-09-20 11:35:40: chunk.c.891) open failed: /data/tmp/lighttpd-upload-Hw0e3T: No such file or directory
2022-09-20 11:35:40: connections.c.466) connection closed: write failed on fd 16

I can not tell if the failure to write the temporary file is a cause or a symptom of the problem. I confirmed that the web server user is able to write to the temporary directory (it’s reserved just for web services and full of files anyway).

Any ideas?

Thanks!

Well nobody has any ideas here but I did some more looking and found that the problem server did not have ffmpeg installed … I installed that and restarted some services and now I see thumbnails for the videos, which I did not see before! Also - a couple of videos played, which usually doesn’t happen, but then after 2-3 videos played, they stopped playing again. Strange?

Also strange - when videos play, I still get the same error in lighttpd’s error.log (chunk.c open failed), even though the video plays.

More news for all of my friends following along the saga here :slight_smile:

I am now at an interesting place because I still have the problem, but only sometimes. I can navigate to a directory with videos and if I click a video, there is maybe a 20% chance that it will play, otherwise I get the same error as always. But if I keep closing and clicking the file, it will eventually play. Is there some token at work when videos are played? This reminds me of a problem I had years ago, where I would get CSRF errors with some frequency, particularly logging in or during upgrades, that ended up being due to the “url-normalize-required” setting in lighttpd; if the token contained particular characters, lighttpd would “normalize” them to something that didn’t work. Maybe something similar is happening here?

I went ahead and downloaded the shiny new 25.0.1 release and after a few heart-stopping but familiar moments I had a new, rounded, and much slower Nextcloud to enjoy! Sadly, it did not solve all of my problems, or really any of them, though it is certainly shiny and new.

Looks like we are in the same boat @Elliott . Upgraded to 25.0.1 yesterday and now I cant play videos in the web interface. In the app it works as expected.
Very weird and annoying.

I think I just realized what the problem is for me. When recording videos with my phone, I use H.265 to save space. That doesn’t play very well with NC.
Changed to H.264 and uploaded. Worked instantly. So I guess I need to figure out how to add H.265 support in my server :slight_smile:

There is no h265 support on the server. Nextcloud does not transcode the clips to any other format. It simply shows them in your browser. But h265 cannot be played back in most browsers, since there are patent fees for that. Only Safari and Microsoft Edge have h265/hevc playback support in their browsers. Maybe you try those then :slight_smile:

2 Likes

Hey, glad you found a solution so quickly! I checked but that is definitely not my problem; I get the same behavior with any video formats, including much older ones. Ah well.

Well, it’s 2023 and I’m still here :sweat_smile: and still with this problem! But a new find, maybe it’s relevant:

I use Firefox as my web browser, on Windows and Linux and even on my phone. But I was playing with Vivaldi today and … I can play videos just fine? All videos, no problems after several minutes of clicking around. On Firefox, some videos play sometimes, other videos (particularly large ones) play never, but on Vivaldi they all play every time.

So that’s weird? I don’t know what it means at the moment, I’ve been staring at the debugging console on Vivaldi and Firefox and of course everything is very different but nothing stands out as “this is important” other than possibly when GETting the video, Firefox says it will accept

video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5

where Vivaldi just accepts

*/*

:man_shrugging:

Aside from that - when I click a large (~800MB) MP4 file on the web interface, Firefox performs four GETs for the file; 1-2 of those will get a response code of 206 from the server; the second one will take 1.7-1.8 seconds and then after that the server returns nothing. Vivaldi will also perform four GETs; each one will get a 206 response code; the first three will take around 2-4 seconds, then the last one extends on as the video streams. I don’t know how streaming videos works so I don’t know what any of it means, but this is the first time that I’ve gathered data here and felt like it was important.

I haven’t been able to dig into details of this, but I tried a few things:

Trying to view an 800MB MP4 video:

  • On the web using Firefox: doesn’t work
  • On the web using Vivaldi: works
  • On the web using Edge: works
  • Using the Android app: doesn’t work
  • Using Firefox on mobile: doesn’t work
  • Using Vanadium on mobile: works

… so in my (limited, so far) testing it seems like Chrome-based browsers work to play this particular large video, but nothing else does.

Some continued testing: Using Firefox on the desktop, as mentioned earlier in this thread, I can view some videos sometimes, inconsistently, but large videos in particular never work. Using a Chrome-based web browser on the desktop, I haven’t found any videos that don’t work. The mobile app seems to do OK with a lot of videos but won’t play the 800MB one.

I have no new thoughts here, just collecting data.

Hi,

Well for all of my fans watching from home, I made some real progress on this today!

I’m still just trying things at random, but I made a change to my lighttpd configuration:

server.stream-response-body = 1

… the default is 0. Some explanation of the feature is at https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_stream-request-bodyDetails

With this change, videos seem to play reliably both on Firefox and the Android app!

[edit: well, more videos play reliably, but still not all of them. Size doesn’t appear to be as much of a factor anymore? My test video, which was around 800MB, plays fine; another video that’s around 75MB also plays fine, but a third that’s around 32MB doesn’t. A fourth, that’s also 32MB, plays fine. But if nothing else I’m on the right track here, maybe]

There are two continuing oddities:

  1. On Firefox, when the video in question has completed, the error still appears - but the video played successfully.
  2. If I share a video file with another user and that user downloads it, I get the activity alert multiple times - usually 4 or 6.

Anyway - these are much more benign so I’m happy to have finally made some progress! I still don’t understand anything but I view random stabbing as an acceptable troubleshooting method at this point :sweat_smile:

I have the exact same problem. In firefox it sometimes plays videos sometimes do not. Tried chromium and could not get any problems playing videos. Plays all the time without any problems.

Odd thing is that when it makes requests for video it’s 4 times as you said but it’s not for only 1 video which i am trying to play. 1 or 2 requests follows this 4 and is for different video. But this is the same for chromium too.

The only difference in request is what you have said:

video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5

*/*

You have done a great job trying to find issue.

On my side i use nginx and postgresql as database could not find server.stream-response-body = 1 this option for nginx. Do not know nginx that good.

I use firefox and do not want to even have chromium installed on my system. Hope we can find what the issue is and it’s easily fixable. Otherwise i really like nextcloud.

Oh forgot to mention i am running it in docker. In fact i have many services, but if we can’t fix it i’ll have to use some other service with or without nextcloud too like photoprism. I really do not want to use chromium.

Hi,

I still have not found the reason for this. I do think it is somehow related to settings of the web server combined with the multiple requests, but I do not understand the connection.

The server.stream-response-body setting is specifically a lighttpd setting - I think in the Docker image they do not use lighttpd, so I am not sure it will help you.

I also use Firefox and do not want to switch to a chromium browser; I do have one installed but it only for occasions like this where a site is broken on non-chromium browsers :frowning:

I keep hoping someone can help with this - I thought it was just a problem with my setup so it is nice (?) to see the same issue appear on the Docker image because maybe someone will care!

The thing is when/if firefox plays the video it has some delay before it starts playing it. Some kind of buffering i guess? But on chromium it starts playing videos instantly. Even when i switch videos fast it still starts playing them quickly.

I have zero useful things to add, but I’ve been busting my skull up against this for a week, and I really appreciated this thread. Same exact problem here. I’m using Firefox as my main, and reliably can’t playback video files. Works just fine in the Android app and in other browsers. Thank you for your persistence! – Debian 11 + NextCloudPi v1.52.4 (Nextcloud 26.0.3)

So on a whim … I made sure my adblocker whitelisted my domain and disabled Firefox’s enhanced tracking protection and… it looks like videos are loading properly now?

WHELP that was a lie. More of them play now but many do not. This is so freaking strange.

Oh jeez, here I hoped you found the answer!

My theory at this point, which I haven’t gotten around to testing, is still that the problem is actually with the specific version of lighttpd that shipped with Debian 11 (1.4.59).

Specifically, release 1.4.60 of lighttpd fixes 2 bugs that appeared in version 1.4.59, related to the chunk.c error message in the logs:

As far as I can tell, the only sure way to confirm this is to upgrade lighttpd to a newer version, which would mean replacing the version that comes packaged with Debian 11 with a custom version I build myself, which is why I haven’t tried yet :sweat_smile:

Another way to test would be adding

server.feature-flags += ("proxy.force-http10" => "enable")

to the lighttpd configuration, per the comments on the Bug #3046 link above; it would be useful as a test of this theory but I (personally) wouldn’t want to leave it that way. Honestly there’s not a good reason I haven’t tried it, just being too busy. Maybe I’ll try that here soon.

Another way, if it’s convenient for you would be to upgrade to Debian 12, which has a newer version of lighttpd. Not sure if that’s doable on the Pi, and of course there’s no guarantee that it works …

1 Like

I’m having this issue on Apache2.

My current feeling is that it’s a variety of issues that seem to only (at least on my end) impact Firefox playing H.265 encoded videos in whatever situations…

Just brute forced the problem today by using ffmpeg to re-encode them all as H.264/AAC videos and am tinkering with just doing a midnight cron script to do that every single night.

ffmpeg -i boke.mp4 -vcodec libx264 -acodec aac fixed.mp4

… seems to render every video that I tested playable on Firefox and in Chrome. I also note in the output that the broken videos were all recorded on my boyfriend’s iPhone, while the ones that played back with no problem as of my last test were all recorded on my Pixel. :woman_shrugging:

Ah, drat, OK. On my end it doesn’t seem to be an encoding issue, I say that mainly because there’s no consistency about which videos will play and which won’t; sometimes a video will play one time out of ten attempts or something. Weird.

1 Like