1.8-rc1 Image in Dataset doesn't always load

I’ve had this issue since Xibo 1.8 alpha3 and it also seems to affect 1.8 rc1.

When using a Library Image in a dataset, the client doens’t always display the image (Both Windows and Android).
Sometimes it does display, sometimes it doesn’t. When it doesn’t, it will just show as image not found like so:

Any ideas why it would be doing this?

Is that after a recent change to the image in the library? It could be that the player has not yet finished downloading the file.

No, it can happen randomly.

I thought the issue would be that the dataset is updating before the player downloads the new image, however, the image can have existed in the Library for hours and it still happens. I’ve got the players configured to pull content every minute and the dataset to update every 3 minutes).

Justin

It can still happen under those circumstances - the library media is not linked to the dataset widget (and therefore the display) until the dataset content is requested. We can’t know what we need to link to, until the dataset is rendered.

Depending on the duration of the dataset widget, it might reload in the player before those additional resources are available.

You could try increasing the duration of your dataset.

Hi Dan,

I’ve just checked my configuration again of the layout again.

The players pull data every minute, the dataset widget updates every minute, and the duration of the dataset widget is 2.5 minutes.
As the dataset is supposed to update every minute are you sure a longer duration is going to help?

We can’t really afford to make the duration of the dataset widget much longer, as the information needs to update fairly quickly once changed in the CMS.

Hope that makes sense.

Justin

It does seem odd in those circumstances -

Is there any way these images could be pre-assigned to the display? For example are there a preset number of images you use, which are assigned to the row according to the data?

Or do you potentially have a new image for each row?

Hi Dan,

Sorry for the delayed reply on this one.

Each dataset row in an entry for a Conference / Event directional signage.

So we potentially have a new image for each row of data as they can be separate clients / rooms.

I think the behaviour does make sense (although may not be optimal).

collect interval = 60 seconds
update interval = 60 seconds
widget duration = 120 seconds

Widget loads, has expired its update interval and calls GetResource for the next time it reloads itself. GetResource detects a new image is required and links it to the Display. At this point the player has the new resource description, including the image that it does not have yet. ** Collect Interval expires and downloads the new image so that it is ready for when the widget reloads.

** If the Widget reloads at this point, it wont have the image.

Collect Interval might also trigger a new copy of the resource to be downloaded, but only if the Layout or DataSet has been edited.

In this case you also have exposure - because collect triggers a new resource, which triggers the new image to be linked, which means the next collect gets the download. Again you are exposed if the Widget reloads between the 2 calls.

I think there are improvements to be made here (although I am not sure exactly what they are). One thing we could definitely do is ask any failed images to retry themselves without the widget reloading. This would mean that as the image got downloaded, it would be backfilled into the layout.

We can also make the “missing image” image better, such that it doesn’t show at all - or is a 1px transparent square or similar.

I’ve submitted an enhancement for that: https://github.com/xibosignage/xibo/issues/990

Hi Dan,

I’ve been using images in 1.8 RC3 from Datasets, and it’s still not working as expected.

In this scenario, I’ve got a layout with duration of 5 mins. Within this, I have a ticker showing Text dataset data that updates every 1 min.
I have another Ticker that is the same as the above, but only shows a logo from the dataset.

The text loads fine and refreshes correctly. The images don’t always load and often takes 10 to 15 minutes to update.

It’s strange the dataset text will always load fine, but not the images - why wouldn’t they both download at the same time?

In summary, what can be done so that images load correctly and as expected?

The player calls the CMS to get its updated widget content, this is generated on the CMS and sent to the player immediately. The text is embedded in the document that gets returned (because it is small it can be). Images are added to the required files queue and downloaded in the next “collection interval”.

If push messaging is being used, the next collection interval will happen straight away - the images downloaded at that point.

The changes we made for rc3 were related to the Widget retrying images after it had been rendered - not changes with how the images are downloaded.

I am not sure what we can do about it - short of embedding the images in the original response (which we have tried before and wasn’t good due to the size of the document).


In your case, are the logo’s pre-known - by which I mean a resource that is already in the library? If so, you could assign the logos directly to the display ahead of time using the “Assign files” functionality.

Thanks Dan.

Unfortunately, assigning images directly to displays defeats the purpose of the automation achieved by using a dataset with images in the first place.

Images embedded in the Dataset / Ticker response makes the most sense for keeping the content up to date and displaying as expected.
As you said though, this could make the response size much larger, but in this use case (meeting room displays), it only will be pulling one image at a time due to the filter in place. Also, we’re running Xibo locally, so bandwidth / speed isn’t an issue.

I’ll see if I can get XMR up and running now Android 1.8 player is officially released. Maybe we’ll have better luck with it.

Justin

I don’t recall if we’ve asked you before whether we can get remote access to this system to experience the issue for ourselves?

You’ve explained it very well, but there’s nothing like seeing it.