ffprobe binary path declaration fails

[tcrux]

Test OK:

<?php
require '../vendor/autoload.php';

$ffprobe = FFMpeg\FFProbe::create(array(
    'ffmpeg.binaries'  => '/usr/bin/ffmpeg',
    'ffprobe.binaries' => '/usr/bin/ffprobe',
    'timeout'          => 3600, 
    'ffmpeg.threads'   => 12, 
));

$filename = '/var/www/html/LycheeLaravel/public/Test.MOV';
$stream = $ffprobe->streams($filename)->videos()->first()->all();

print $stream['width'];

Lychee-Laravel NOK:

Out of the box
- Upload Video
- DB Insert "Test.MOV"
- DB Log - Unable to load FFProbe
- Server error or API not found
- Laravel Log -  Undefined offset ... Photo.php:250
- DB Delete "Test.MOV"
- Server Ok

Add/Replace binary path (see above):
- Upload Video
- No DB modification
- Laravel Log - Unable to load FFProbe
- Server Ok

[jprokop1]

I had a exactly this problem with video upload (Linux/nginx), by me helped set the path to ffmpeg/ffprobe binary in nginx conf:

location ~ .php$ {
       ....;
       fastcgi_param PATH /usr/local/bin:/usr/bin:/bin:/your/path;
      ....;
      }

you can check your enviroment with testfile.php:

<?php 
    var_dump(getenv('PATH')); 
    var_dump(exec('which ffmpeg')); 
    var_dump(exec('which ffprobe')); 
    var_dump(ini_get('open_basedir')); 
    var_dump(is_file(exec('which ffmpeg'))); 
    var_dump(is_executable(exec('which ffmpeg'))); 
?>

[d7415]

Is ffprobe definitely installed at /usr/bin/ffprobe?

[jprokop1]

Yes (Ubuntu 18.04)

[d7415]

Yes (Ubuntu 18.04)

I was asking @tcrux

[tcrux]

Yes (Ubuntu 18.04)

I was asking @tcrux

Is ffprobe definitely installed at /usr/bin/ffprobe?

Yes (Debian GNU/Linux 9.9 (stretch), nginx/1.10.3).

which ffprobe
/usr/bin/ffprobe 

[kamil4]

Huh... I just tested with the current master and it works for me out of the box...

@tcrux The Undefined offset ... Photo.php:250 that you get out of the box is definitely a bug and I can see how it would happen if we failed to extract a frame from the video. So this one I can confirm...

Back to your main problem, could you include a diff with the changes you made? Did you make them both in app/ModelFunctions/PhotoFunctions.php and app/Metadata/Extractor.php? Also, could you include the actual excerpt from laravel.log when you add a movie file?

I'm also a little puzzled that passing /usr/bin/ makes a difference in your test. I would've expected that to be the default but it clearly isn't in your case. Is there a way for you to find out where it searches by default?

[tmp-hallenser]

I'm having the same issue, but using nginx:alpine as the base docker image.

[tcrux]

In my opinion the problems on my system were caused by a misconfigured nginx in combination with missing FFmpeg paths and perhaps the error handling during the video import and presentation process. FFprobe problems could stop the video import but should not crash the presentation afterwards.

My solution:

Thx to: #223 (comment)

/etc/nginx/sites-available/your_configuration

location ~ \.php$ {
  fastcgi_param PATH /usr/local/bin:/usr/bin:/bin;
}

app/Metadata/Extractor.php:282

$ffprobe = FFMpeg\FFProbe::create(array(
  'ffmpeg.binaries'  => '/usr/bin/ffmpeg',
  'ffprobe.binaries' => '/usr/bin/ffprobe',
  'timeout'          => 3600, 
  'ffmpeg.threads'   => 12, 
));

[kamil4]

I just submitted a PR that fixes the "Server error or API not found" errors when ffmpeg cannot be found.

From the reports here it appears that the use of nginx is the common factor in Lychee being unable to locate ffprobe/ffmpeg (I'm using Apache and it works fine there). We may want to update the installation instructions and/or the FAQ. I guess the addition of fastcgi_param PATH to nginx config should be enough though and there should be no need to modify the Lychee code...

[d7415]

I guess the addition of fastcgi_param PATH to nginx config should be enough though and there should be no need to modify the Lychee code...

Really either should be sufficient. I don't know why that $ffprobe declaration isn't sufficient, unless it was made in the wrong place or only one of the two places. But if apache seems to work, documenting the nginx case seems a sensible option. We might want to leave the other option there as an aside though.

[kamil4]

FYI, I just merged the fix to master. I'm keeping this issue open until we get a confirmation from @tcrux and @tmp-hallenser that the bug is fixed.

[tcrux]

FYI, I just merged the fix to master. I'm keeping this issue open until we get a confirmation from @tcrux and @tmp-hallenser that the bug is fixed.

I can confirm the changes.

[tmp-hallenser]

The ffmpeg/ffprobe issue has been fixed for me.

But, the video is not shown in the folder view next to the photos (small photo size) - it's just a blank.

Console throw the following error on Safari 12.1 (everything works fine on Firefox + Chrome)

Refused to load data:image/svg+xml;base64,<_image_> because it does not appear in the img-src directive of the Content Security Policy.

[kamil4]

If you are not seeing a preview then most likely ffmpeg/ffprobe still cannot be found during the upload of the video file. There should be a message about that in the server log (storage/logs/laravel.log). My fix didn't do anything about that part, only about not crashing if they are not found...

Did you look at #223 (comment) or #223 (comment) above in this thread? It sounds like with nginx you may need to tweak the http server config, or provide full paths to the ffmpeg/ffprobe binaries in the Lychee server code.

The console error is most likely unrelated. I see some very similar ones with Firefox. I never bothered to figure out what exactly causes them; they don't seem to break anything.

[tmp-hallenser]

I did some further testing. I think, the log looks okay. https://pastebin.com/1n7cDzQH

Here's a screenshot from Safari (Video placeholder is missing next to the picture, but clicking on the empty space opens the Lightbox with the video):

Same screenshot using Firefox:

The reverse effect occurs if I first upload the video and then the picture. Firefox works shows video + photo, Safari only show video.

[kamil4]

Sorry for the delay in responding; I somehow managed to miss your update. Yes, I can confirm that the server log looks exactly as expected, so I suspect that the problem is on the front end side.

Can you confirm that the resolution of your video file is 480x270? I may not have tested with one that small when I was extending video support so there could be a bug lurking in the code somewhere.

The weird discrepancy between Firefox and Safari will be difficult to test for me as I don't have access to Safari but I don't like what I'm seeing in the Firefox preview either (there should be a square preview for the video file) so there's definitely something for us to fix here, no matter which browser is used 😃.

[tmp-hallenser]

Yes, the resolution is 480x270 (http://file-examples.com/index.php/sample-video-files/sample-mov-files-download/ -> lowest resolution)

I think I found 2 issues regarding the preview:

1. the img-tag in the preview page points at the .mov file -> it should point at the small/.jpg file
2. A small/*.jpg does not exist, just the thumbnail version

[kamil4]

The reason small does not exist is because the resolution of the source is too small. With default settings, the height of small images is set to 360px. If the source is smaller than that, we skip the generation. In that case, the square thumbnail should be used (which is 200x200).

There are multiple bugs here because even if I switch the photo layout to "Square thumbnails", it still doesn't display correctly for me (it tries to load the "@2x" variant of the thumbnail, which again doesn't exist because it's only generated if the source is over 400px high).

The good news is that this should all be easy to fix though.

[kamil4]

OK, this was a lot more broken than I expected (I thought it would be just a couple of one-liner fixes) but I think I got them all... You are welcome to try the fix-223 branches on both the server and the front end, or wait until they've been reviewed and merged to master.

[tmp-hallenser]

I'd like to give the fix a test, but would again need some help. If I understood the docs correctly, one needs to perform:git pull followed by a npm install and npm start in the Lychee front directory.

The latter results in the following error:
[19:24:14] '<anonymous>' errored after 4.26 ms
[19:24:14] Error: watching ``./scripts/_gup.js,./scripts/api.js,./scripts/csrf_protection.js,./scripts/frame/main.js: watch task has to be a function (optionally generated by using gulp.parallel or gulp.series)
at Gulp.watch (/usr/share/nginx/html/Lychee-Laravel/public/Lychee-front/node_modules/gulp/index.js:31:11)
at /usr/share/nginx/html/Lychee-Laravel/public/Lychee-front/gulpfile.js:374:7
at bound (domain.js:395:14)
at runBound (domain.js:408:12)
at asyncRunner (/usr/share/nginx/html/Lychee-Laravel/public/Lychee-front/node_modules/async-done/index.js:55:18)
at process._tickCallback (internal/process/next_tick.js:61:11)
[19:24:14] 'watch' errored after 13 s
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! lychee@3.2.14 start: "gulp watch"
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the lychee@3.2.14 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2019-05-07T19_24_14_561Z-debug.log

The complete log looks like the following:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'start' ]
2 info using npm@6.4.1
3 info using node@v10.14.2
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle lychee@3.2.14~prestart: lychee@3.2.14
6 info lifecycle lychee@3.2.14~start: lychee@3.2.14
7 verbose lifecycle lychee@3.2.14~start: unsafe-perm in lifecycle true
8 verbose lifecycle lychee@3.2.14~start: PATH: /usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/usr/share/nginx/html/Lychee-Laravel/public/Lychee-front/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
9 verbose lifecycle lychee@3.2.14~start: CWD: /usr/share/nginx/html/Lychee-Laravel/public/Lychee-front
10 silly lifecycle lychee@3.2.14~start: Args: [ '-c', 'gulp watch' ]
11 silly lifecycle lychee@3.2.14~start: Returned: code: 1 signal: null
12 info lifecycle lychee@3.2.14~start: Failed to exec start script
13 verbose stack Error: lychee@3.2.14 start: "gulp watch"
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
13 verbose stack at EventEmitter.emit (events.js:182:13)
13 verbose stack at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack at ChildProcess.emit (events.js:182:13)
13 verbose stack at maybeClose (internal/child_process.js:962:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:251:5)
14 verbose pkgid lychee@3.2.14
15 verbose cwd /usr/share/nginx/html/Lychee-Laravel/public/Lychee-front
16 verbose Linux 4.9.125-linuxkit
17 verbose argv "/usr/bin/node" "/usr/bin/npm" "start"
18 verbose node v10.14.2
19 verbose npm v6.4.1
20 error code ELIFECYCLE
21 error errno 1
22 error lychee@3.2.14 start: "gulp watch"
22 error Exit status 1
23 error Failed at the lychee@3.2.14 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

npm version is 6.4.1 on alpine linux.

[kamil4]

I never use npm start so I don't know why it fails. I just tried it and it fails for me as well. Instead, just run npm run compile after npm install and that should complete successfully. After that, you are good to go (the compilation output will end up in Lychee-Laravel/public/dist/).

Are you following the master branch of Lychee-front? You need to in order to get the front end fixes for ffprobe. git status while in the Lychee-front directory will let you know. If it says something like HEAD detached, run git checkout master.

I hope this helps!

[kamil4]

Also note that @ildyria just updated the compiled front end versions in the Lychee-Laravel repo so if you fetch the latest master, you should be good to go with all the ffprobe fixes we recently committed.

[tmp-hallenser]

Many thanks - fix looks good so far