Thumbnail Display Issue

craig.jamieson · September 14, 2016, 5:52pm

I’m having an issue related to the display of thumbnails. The thumbnails are created properly and even display in the thumbnail tab for the video in the KMC (I can download them directly from the KMC as well). Video flavors seem to all be converted successfully as well. However, the thumbnail doesn’t display on the main page of the KMC and it don’t get overlayed on the player. I suspected it might have to do with folder permissions, but I can’t quite figure it out. The logs are mostly empty, but I did see some errors like that:

2016-09-14 11:22:23 [0.000295] [129.128.36.159] [2106243485] [45] [PS2] [KExternalErrors::dieError] ERR: exception ‘Exception’ with message ‘exiting on error 17 - image resize failed’ in /opt/kaltura/app/infra/log/KalturaLog.php:83

I moved the directory (via symlink) where the videos get stored over to a second drive. The folder permissions look good, but that’s the last big change I recall making. The video flavors and thumbnail are all created successfully, so I’m not really sure.

@jess : you’ll be happy to hear the update to 12 (I think it might have said 12.1 actually) went very smoothly. Thanks so much for your help in the other thread. The thumbnail issue I’ve described actually existed before I did the update and I figured I’d go ahead and see if the update fixed it.

jess · September 14, 2016, 6:04pm

Hi @craig.jamieson,

Delighted to hear the upgrade went well:)
As for the issue, what are the permissions for these image files? and also, I suggest you run:
# kaltlog
from the server’s shell while making the request and check the output, there are bound to be some useful errors somewhere.

craig.jamieson · September 14, 2016, 6:26pm

Most of the files in the /opt/kaltura/web/content/entry/data/0/0 folder are apache:kaltura with permissions set to 640 (including the latest jpg from the video upload). There are a few older ones that are set to kaltura:kaltura with permissions 664.

When viewing the main KMC entry page, I see an error like this:

2016-09-14 12:09:39 [0.000288] [129.128.36.159] [247136258] [45] [PS2] [KExternalErrors::dieError] ERR: exception ‘Exception’ with message ‘exiting on error 17 - image resize failed’ in /opt/kaltura/app/infra/log/KalturaLog.php:83
Stack trace:
#0 /opt/kaltura/app/alpha/apps/kaltura/lib/KExternalErrors.class.php(128): KalturaLog::err(‘exiting on erro…’)

Sometimes I also get:

2016-09-14 12:11:09 [0.000385] [129.128.36.159] [1118263185] [43] [PS2] [KExternalErrors::dieError] ERR: exception ‘Exception’ with message ‘exiting on error 11 - processing capture thumbnail’ in /opt/kaltura/app/infra/log/KalturaLog.php:83
Stack trace:
#0 /opt/kaltura/app/alpha/apps/kaltura/lib/KExternalErrors.class.php(128): KalturaLog::err(‘exiting on erro…’)

But I’m not sure if it’s as relevant. The thumbnail definitely exists and I can even download it via the KMC.

jess · September 14, 2016, 7:14pm

Hi @craig.jamieson,

The ‘exiting on error 17 - image resize failed’ exception is thrown in two cases, here:

github.com

kaltura/server/blob/Lynx-12.2.0/alpha/apps/kaltura/lib/myEntryUtils.class.php#L784


								    
			$forceRotation = ($vid_slices > -1) ? self::getRotate($flavorAssetId) : 0;


			kFile::fullMkdir($processingThumbPath);
			if ($crop_provider)
			{
				$convertedImagePath = myFileConverter::convertImageUsingCropProvider($orig_image_path, $processingThumbPath, $width, $height, $type, $crop_provider, $bgcolor, true, $quality, $src_x, $src_y, $src_w, $src_h, $density, $stripProfiles,$forceRotation);
			}
			else
			{
				if (!file_exists($orig_image_path) || !filesize($orig_image_path))
					KExternalErrors::dieError(KExternalErrors::IMAGE_RESIZE_FAILED);
					
				$imageSizeArray = getimagesize($orig_image_path);
				if ($thumbParams->getSupportAnimatedThumbnail() && is_array($imageSizeArray) && $imageSizeArray[2] === IMAGETYPE_GIF)
				{
					$processingThumbPath = kFile::replaceExt($processingThumbPath, "gif");
					$finalThumbPath = kFile::replaceExt($finalThumbPath, "gif");
				}


				$convertedImagePath = myFileConverter::convertImage($orig_image_path, $processingThumbPath, $width, $height, $type, $bgcolor, true, $quality, $src_x, $src_y, $src_w, $src_h, $density, $stripProfiles, $thumbParams, $format,$forceRotation);

github.com

kaltura/server/blob/Lynx-12.2.0/alpha/apps/kaltura/lib/myEntryUtils.class.php#L799


				{
					$processingThumbPath = kFile::replaceExt($processingThumbPath, "gif");
					$finalThumbPath = kFile::replaceExt($finalThumbPath, "gif");
				}


				$convertedImagePath = myFileConverter::convertImage($orig_image_path, $processingThumbPath, $width, $height, $type, $bgcolor, true, $quality, $src_x, $src_y, $src_w, $src_h, $density, $stripProfiles, $thumbParams, $format,$forceRotation);
			}
			
			// die if resize operation failed
			if ($convertedImagePath === null || !@filesize($convertedImagePath)) {
				KExternalErrors::dieError(KExternalErrors::IMAGE_RESIZE_FAILED);
			}
			
			if ($multi)
			{
				list($w, $h, $type, $attr, $srcIm) = myFileConverter::createImageByFile($processingThumbPath);
				if (!$im)
					$im = imagecreatetruecolor($w * $vid_slices, $h);
					
				imagecopy($im, $srcIm, $w * $vid_slice, 0, 0, 0, $w, $h);
				imagedestroy($srcIm);

In light of what you describe, the file does exist and has content so the first case is not the one, but rather, the second.
I would suggest increasing the log verbosity in /opt/kaltura/app/configurations/logger.ini to 7 [default is 4], moving aside the old logs, so it is easier to look at new errors, reloading Apache and making the request.
Then, look at /opt/kaltura/log/kaltura_api_v3.log and check for debug prints. Specifically ones with the pattern:
“Returned value: $returnValue Output”

Also, in relation to the other exception, can you please make sure your memcache daemon is running correctly and perhaps restart it for good measure? And, can you make sure:
/opt/kaltura/app/alpha/apps/kaltura/lib/cache/
/opt/kaltura/app/cache/
/opt/kaltura/app/infra/cache/
all have apache.kaltura and 775 permissions on them and that the files inside are writeable to the apache user?

craig.jamieson · September 15, 2016, 3:09pm

Sorry about the delay, I didn’t quite get all the way through testing yesterday before I left. I didn’t turn up too much unfortunately. I like your thinking though, it does seem as though it might have something to do with the cache.

/opt/kaltura/app/alpha/apps/kaltura/lib/cache/ is set to 755 with ownership root:root. I tried flipping to 664 with apache:kaltura, but this generated a number permission errors with kaltlog running. Setting to apache:kaltura won’t harm anything, but it seems it needs the execute flag.

/opt/kaltura/app/cache is set to 775 with ownership apache:kaltura (little less restrictive, so I didn’t change)

/opt/kaltura/app/infra/cache is set to 775 with ownership root:root. I didn’t try changing this one after the first path threw some errors.

I flipped the log verbosity to 7 using writers.stream.filters.priority (then setting .name .priority and .operator) according to how it was done for other log files. I restarted httpd, wiped out the log file, accessed a video (so the error 17 was thrown) and checked out the log. There are a lot of debug prints, but I didn’t find any that mentioned returned value. All told it ran for 5 seconds, but it generated 300 KB of data, so I think the verbosity was changed correctly.

I can send you the log file if you’d like to take a look at it.

jess · September 15, 2016, 3:32pm

Hi @craig.jamieson,

I think I wasn’t clear before… the dirs should be apache.kaltura with 775 and the files inside them apache.kaltura with 664.
You can recursively set it with:
# chown -R apache.kaltura /opt/kaltura/app/cache/
# find /opt/kaltura/app/cache/ -type d -exec chmod 775 {} ;
# find /opt/kaltura/app/cache/ -type f -exec chmod 664 {} ;

Repeat this for each of the three dirs, restart memcached as well like I said before, and let’s see.

craig.jamieson · September 15, 2016, 5:03pm

Thanks for clarifying Jess, sorry I misunderstood your original message. I’ve changed all the directories (775) and files (664) with the correct permissions and ownership (apache.kaltura). the infra/cache and lib/cache ones are a little easier since there aren’t any subdirectories.

After flipping the permissions, I restarted memcached. The error 17 does still appear in the logs. I do suspect still feel that your suspicion that it has something to do with the cache is correct.

Did you want to have a look at the api_v3 log that I grabbed earlier today?

jess · September 18, 2016, 1:13pm

Hi @craig.jamieson,

I did not get the log… did you email it to my Kaltura address? can you please resend?

Thanks,

craig.jamieson · September 19, 2016, 3:04pm

Sorry about the wait, @jess. I’ve sent you off a copy of the log file now.

Thanks for your help.

craig.jamieson · September 19, 2016, 5:14pm

We solved the issue via email, but I wanted to put the solution here in case anyone comes across this thread in the future. We found the actual error + info in /opt/kaltura/log/kaltura_prod.log and it was indeed bad permissions on a directory.

The thumbnails get placed in (after conversion): /opt/kaltura/web//content/entry/tempthumb/0/0/ I changed the tempthumb, 0, and 0 directories to be 755 with apache:kaltura ownership and the files inside the directory to be apache:kaltura with 664 permissions.

If that change alone doesn’t fix it, be sure to check the permissions on /opt/kaltura/web//content/entry/data/0/0 as well.

Huge thanks to @jess for finding the solution!