XMDS Error: Cannot delete ticker file

controlon · February 27, 2018, 8:50am

I’ve run Xibo in a Xampp Server.
I’ve a ticker in layout with this RSS feed: <![CDATA[Portada de EL PAÍS]]> with 20’ update interval. The template appearance is “Image overlaid with the Feed Content on the left” and it’s displayed randomly.
The layout displayed correctly in the player, but it generates errors every update:

In the server (media folder and temp folder) those files are not deleted.
But, If I change the template appareance without image (with only title) these errors no loger appear.
Thanks.

Peter · February 27, 2018, 9:12am

It seems to have issues deleting resources from the /temp folder.

If you look in CMS library path (not in web ui) is the /temp folder empty or does it contain any files?

Which CMS version are you using please?

It could be permission issue on the library folder / file permissions, perhaps you could check that.

controlon · February 27, 2018, 10:38am

There are the some files in both folders,

But delete them in each update! although occasionally one is left without deleting

The permissions of the media and media/temp folders are total control for all.

Now I have V1.8.6 installed, but it also happened in V1.8.5.

Peter · February 27, 2018, 10:46am

is the XTR configured and maintenance tasks running fine?

controlon · February 27, 2018, 11:17am

Yes, XTR run every minute in the W10 Task Sheduler, every Xibo task has ok status and if I executed manually php bin/run.php ID_TASK, it ends without saying anything.

dan · February 27, 2018, 1:07pm

I think this is a concurrency problem we hoped we’d solved, but perhaps have not.

Those files will be tidied up by maintenance when it next runs, and their associated records will drop out of the cache in due course.

I assume you have multiple displays accessing the same Layout (with the same ticker on it) concurrently, or potentially concurrently?

controlon · February 27, 2018, 1:54pm

Now, only one display has this layout, but the normal thing is that there are several displays with the same layout.
Once I have seen that the player is “blocked” waiting to download a ticker file (status dowload in Display/Manage) that no longer exists and I can only recover it by disauthorizing the display and reauthorizing.

controlon · March 1, 2018, 7:30am

I’ve updated to V1.8.7 and the same happens, the error of not being able to delete the files is generated ticker_.
We will wait for next updates.

I take this opportunity to congratulate you. You are doing a great job!
Xibo is good!

Thank you.

dan · March 1, 2018, 8:01am

Thanks!!

We’ve created an issue for this problem here and will come up with a solution for the next release.

github.com/xibosignage/xibo

Improve Widget HTML caching and resource download concurrency locking

opened 05:06PM - 27 Feb 18 UTC

closed 11:03AM - 05 Mar 18 UTC

dasgarner

bug

A number of issues have been opened and addressed to try and get to the bottom o…f this. Originally it was thought that a widget shouldn't be responsible for un-linking its images (modified in 1.8.0-rc1), the idea being that maintenance could do that. Then it was discovered that maintenance couldn't reliably unlink and remove files that were still in-use, because it didn't know when a display was finished with that image (even though it had dropped out of the cache the source feed could still reference it). Then there were some concerns over concurrent access to the same resource - the cache was locked against the source feed, but not against the images, meaning images could be downloaded concurrently causing locks. Below is how it should work: --------- Consider the case where there are two displays referencing a layout with a Ticker which has an update interval of 5 minutes. Display 1 connects, pulls the RSS and caches that. It then parses the RSS and pulls any images, caches those. It assigns the images to the Widget so they appear in required files and stops, job done. Display 1 downloads its stuff. Display 2 connects 4 minutes later. It requests the RSS and gets it returned from the Cache. It parses the RSS (which is the same) and links up the existing cached images. It stops and starts to Download its stuff. Display 1 connects again, requests the RSS and gets an expired cache. It repulls and caches it, parses the content, downloads some additional images and removes the links to the existing images. It finishes and starts to download its stuff. Display 2 requests one of the resources it does not yet have, even though they are no longer linked to the Widget, they *are* still in required files, because this display has not yet called required files to regenerate that data. Regular Maintenance happens and removes expired and unlinked files images from the library. -------- In 2.0 it would be better to implement a mechanism for the CMS itself being responsible for updating these resources and managing those in a central fashion. As new resources are made available they are pushed to Players in Required Files and Players no longer call GetResource when they think they ought to.

controlon · March 1, 2018, 11:03am

If you need to enter my system to debug I would give you access.

controlon · March 22, 2018, 7:23am

Hi, How is the bug?
After several days the XMR connection of the player fails and it is trying to download files (ticker_xxxxxx) that no longer exist and I have to delete the player’s campaign to recover it.
The fault appears when the RSS of the ticker has an image. If you only put text (title and description), there is no problem.

dan · March 23, 2018, 8:59am

The bug has been closed as solved and is now waiting for some other issues to be resolved with that release and a release test.

The changes are quite extensive and I don’t recommend trying to patch them into your CMS - but you are welcome to do that if you’d like. Otherwise they will be along in the 1.8.8 release in a few weeks.