I’m sorry, but I do not know what you mean.
Perhaps you could ask in Portuguese and we can translate?
Hello DAN,
Firstly I would like to apologize for the writing. I wrote quickly and did not realize that interpretation was very bad.
Come on!
What I did was remove the file with the LOG modifications that you requested.
I upgraded all the CMS files to RC3.
Unfortunately it is not working yet. CMS downloads the ticker to the TEMP directory, but does not move to the library as expected.
I’ve reviewed if it could be some directory permissioning problem. It’s all set up correctly.
This item is very important to my operation, please please try to help me.
The test server is available so that you can perform the tests, your user is active. If you wish I can give you FTP access.
No problem - yes please send me FTP details so I can add some logging, etc
Tks Dan,
Send to your email now…
OK, so i’ve spend several hours on this now and the bottom line is that your temporary folder (and library altogether) does not allow files to be deleted.
I’ve tried everything I can think of to work around it (copy/delete instead of rename, checking file existence before deleting, etc, etc), but nothing works.
You need to resolve your library file and folder permissions before Xibo can function.
Hello Dan,
You were very fast !!!
I was still adjusting the permissions after I released FTP
That’s why you could not take the test.
Could you please try again?
Sorry, but that is not possible at the moment as I have had to move on to other priorities - I will try again as soon as I can.
Hello DAN, I upgraded from 1.7.9 in a new test environment to version 1.8.0 Stable.
Unfortunately the process of downloading / moving the images by the Ticker still does not work.
We’ve tested the download process on many other installations and it works without issue. I confirmed 100% during my last investigation that the folder permissions on the library were the cause of the issue.
Can you please try a test installation using Docker to confirm it works as expected?
We are no longer able to guarantee community support for non-Docker installations - as the software has become more complex we need a stable, repeatable environment to run it on - this is what Docker provides us.
If you absolutely must get this working outside of Docker, then you can contact us for commercial support on support@springsignage.com (we will need SSH/RDC access to the machine)
Hello Dan,
What I can not understand is that the content upload process is saving perfectly in the library.
Download the Ticker is saving perfectly in the temp directory
What is not working is the engine or the time file for a library (root).
Taking advantage, I have received this log every connection of the player:
[28-Mar-2017 17:13:23 America/Sao_Paulo] PHP Strict Standards: Declaration of Xibo\Xmds\Soap5::RegisterDisplay() should be compatible with Xibo\Xmds\Soap4::RegisterDisplay($serverKey, $hardwareKey, $displayName, $clientType, $clientVersion, $clientCode, $operatingSystem, $macAddress, $xmrChannel = NULL, $xmrPubKey = NULL) in \lib\Xmds\Soap5.php on line 17
For the benefit of any others experiencing a similar issue, this was solved offline - the solution was to change rename to copy/unlink and will be included in 1.8.1.
Regarding the strict standards error - I have seen this before and will investigate (https://github.com/xibosignage/xibo/issues/1121).
1 Like
Dan, about the problem of keeping the file in the temp directory of the library, which mechanism will be used to delete that file in the future? I say this so that the directory does not grow in size indefinitely.
Dan, good morning.
I’m running several testicles on ticker functionality.
What I’m noticing is with the ticker this. It is displayed without loading an image, it appears that it is not checking as dependencies before playing.
Also I’m seeing problems in the logs to step to delete processed files from tickers.
ID Data Menssagem
17746 11-07-2017 – 15:20 Cannot delete file: XXXX\Library\XXX\ticker_49ee89268aeb87beb06a81560da14fb7
The temp folder is cleared out by the maintenance procedure - which is run with the xtr.php script file and status can be checked in CMS → Tasks.
That is correct - tickers will show before all image resources are downloaded. The feed might change every time it is loaded and if we did not show it, we might never show it.
If the ticker has been scheduled in advance, and has a reasonable cache period, then the chances of seeing a missing image are low, because it will have been downloaded in advance and then the feed cached.
If that file really exists and cannot be deleted, then I would say that there is some problem with file permissions - you would need to make sure that XTR is run as a user that has permissions to delete those files.
Dan, I apologize if my question to idiot.
Before we were wrong with the MOVE function, when moving the temp file to the library.
The change that made this doing copy from temp to library, but still keeps the file in temp for another routine to do the removal.
Would not it be appropriate after performing the copy of temp to liberary, to carry out in the sequence the deletion of the file in temp? Am I talking bullshit?
The code will already attempt to delete the file after it copies it (I think you have noticed this already in your other ticket). The problem we had before, which still remains, is that the file cannot be deleted for some reason.
We didn’t work out why that was the case - perhaps some locks, perhaps something else.
I think waiting for the scheduled maintenance task to tidy it up is the best solution we have at the moment.
Dan, I understood your comment on the subject, but resuming the subject …
It is displayed without loading an image, it appears that it is not checking as dependencies before playing
That is correct - tickers will show before all image resources are downloaded. The feed might change every time it is loaded and if we did not show it, we might never show it.
If the ticker has been scheduled in advance, and has a reasonable cache period, then the chances of seeing a missing image are low, because it will have been downloaded in advance and then the feed cached.
Even with your answer I think this is a bad logic line. Each ticker when being processed stores in the Bilbioteca all the data. Like any other Layout / Widget, Ticker has dependencies (all ticker items are processed and stored in the player).
I see no reason why TIcker behaves differently than other CMS items.
Please, if I have not understood, do not fight with me, I am only trying to understand why not check dependencies as is done in all other widgets …
Hello Dan, unfortunately for me in CMS 1.8 this is occurring very often. My tickers are processing every 180 min, returning and displaying the last 3 items in the feed.
My REQUIRED_FILES_LOOKAHEAD parameter is 86400
My SCHEDULE_LOOKAHEAD parameter is set to On.
It would not be possible to create this dependency, that is, the layout that owns the ticker will only be reproduced the ticker after having all the elements, including images.