4GB file size workaround for 32bit OS breaks video streaming in iOs clients

[rmufr]

Using Sabredav embeded with Nextcloud 13 (v4.2.3), on a RPI3 Raspbian stretch server (32bit OS). Webserver is Nginx 1.14.0, fastcgi php-fpm 7.0.30.

Video playback in iOs requires partial content requests (range) support.
When starting a Video playback , from the Nextcloud iOs app (>v2.22) or from the Nextcloud Web UI within iOS Safari browser, both clients start with a partial content GET request of the first 2 bytes.
The #74 change ignores the Content-Length header info, resulting in a response body with the entire video file, but with response headers saying "range: bytes 0-1/filesize" and "content-length: 2".
This mismatch in response information headers and body content is not supported by the iOs client. The client breaks the connection and won't play any image.

[kruthoff]

👍

[staabm]

Could you provide a failling unit test describing your issue or anything similar which can be used to reproduce your issue?

Could you work on a solution which works for videoastreaming but does not break files > 4gb?

[kruthoff]

I'm not able to provide a unit test, unfortunately. I've just followed @rmufr 's recommendation and got streaming on my iOS (running nextcloud on a raspberry pi, as described above).

[rmufr]

Hi,
The simplest way to reproduce, talking only about what I experienced, woud be

• have a 32bit OS sabre server, and an mp4 video file (<2GB) suitable for HTML5 video playback (e.g. h264/aac)
  • on this server, serve http requests with an Nginx (eg. v14.0) server. I didn't test with Apache.
• from a iOs device, use Safari browser , try to playback the video file using the an HTML5 embeded video link. (As it happens with Nextcloud WebUI).

My use case is :

• Nextcloud v13 or v14, installed on a RPI3/raspbian stretch., up to date, default conf
  • Webserver Nginx v14.0 or v13.x also running on the RPI , default conf.
• iOS Client = iPhone 7, Nextcloud WebUI in Safari Browser. Tested also with iOs 10, 11, 12. iPhone and iPad.

I'm not skilled developer to propose a target solution, but on my opinion, an acceptable solution would be to go through te 32bit OS workaround only if 32bit OS AND the requested stream size really is >2GB, and not upon the only 32 bit OS condition.

[schoetju]

@rmufr Thanks for the good preparation / issue-description
@phil-davis With #184 being merged into version 5.1.5 this issue can be closed IMHO

[staabm]

Thank you guys