We’ve recently had a few issues in a production environment where users have uploaded very high resolution image into the media library and then scheduled onto players via our automated dataset (we use datasets to schedule meeting rooms signage and client logos).
An example was a 24Mb jpeg image with a resolution of 4912 × 7360px.
When these are uploaded and scheduled, the players (all running Android) seem to freak out and just display the black invalid layout screen, but don’t actually show any reason for the invalid layout in the logs.
The only way to fix the issue is to remove the dataset entry that links to the image, and then remove the image from the media library (or replace it with a lower-res image), then force collect on the players which will then come back to life afterwards.
Is this a known issue?
Can an ‘auto resize’ image be implemented on the media uploaded or system settings so that images over a specific resolution / size will get resized on upload?
Thanks and please let me know if you need anymore info.
CMS version 2.3.10 - however, this issue has been present is older version of the CMS
There is already function in the CMS to do this. Be default, the images you describe would be resized, so I can only assume you’ve disabled that functionality.
In the main CMS settings, ensure you have the following set on the Defaults tab:
That will ensure images > 1920 on their longest side are resized down to 1920 pixels. Images larger than 6000 pixels on the longest edge won’t be resized. You can increase that assuming you also increase XTR’s PHP memory limit to match.
This is enabled, but as you’ve already mentioned the default is 6000px - so it wasn’t resized because the image was larger than 6000px.
I’ve now increased this value, however as this instance is hosted with Xibo cloud, does that mean we need to request an update to the PHP memory limit via support?
If you’re on Cloud then you may be able to increase the limit very slightly, but if you increase it significantly you’ll find your Image Resize task will error and then images will stop being processed - and you’ll then need to open a ticket to have that reset.
It isn’t possible to increase the PHP memory limit on Cloud beyond its current setting. Wherever we draw that line, someone will have an image 1 pixel larger unfortunately.
If the image is larger than the threshold, it won’t be resize and it won’t be released to the Player. The user will see an error in the layout designer, and you’ll see the file blocked on the Player download page. So perhaps that’s the issue you saw - not that the image was causing the Player to behave badly, but that since it wasn’t released it was never sent to the Player and so the Player couldn’t show the layout?
Thanks for providing a bit more info about how this works - all makes sense.
The missing link here, is that in our case, the user doesn’t touch the layout designer so won’t ever see there is an error.
Our workflow is as follows:
User uploads Logo image to Library
User adds row to the ‘Events’ dataset and selects the uploaded Library image
3 Signage displays at its scheduled time with the logo.
What we’re seeing as a result, is that the large invalid image breaks the dataset, and any player that was supposed to receive that image then goes into the invalid state.
So there might be an opportunity for improvement here - let me know what you think.
In that case, in the Media Library, have them enable the Released column in the grid. When they upload an image that is larger than can be resized, they’ll see Released as a cross, and will know that it needs to be manually sized before they can use it in their dataset. You’ll also see an image of that size will not thumbnail. Images that are of a suitable size already will show as a tick, and images queued for processing will show a gears icon.
Alternatively, if you would prefer that if a user ignores that, the dataset isn’t impacted, you can set both resize and threshold settings to 0, in which case those images will then be passed through to the Player to deal with - which may well cause instability as an image of the dimensions you mention will consume more memory than Android allows an app to allocate.
