Two Android Players have randomly stopped updated. They’re logged in and connected to the CMS, but show as ‘Downloading’. I have enabled auditing, and this is the error that is showing in the log:
ID Run Date Channel Function Level Display Page Message 28106 94515e0 2017-02-21 17:09 PLAYER POST ERROR Paterson 1 RequiredFiles syntax error, unexpected '"}}"' (T_CONSTANT_ENCAPSED_STRING), expecting identifier (T_STRING)
Using Android R62, CMS 1.8 RC1.
Please let me know if you need further information.
Can you edit the display record and enable auditing on that display CMS side. This will show the RequiredFiles XML that is being sent down to the Player.
The error shown is from the Display Auditing enabled on CMS side.
Are you saying the required files XML will also show in the log? I can see a couple of other XML files in the log, but the only one relating to RequiredFiles is the error. See screenshot below:
I have worked around this issue as I didn’t have time to diagnose further.
To work around this, I deleted the Display entry from ‘Displays’ and waiting for the display to reconnect to the CMS.
I then set up the display as new and restored the defaults such as Settings Profile, default layout etc.
They now are working correctly. It would be great to get to the bottom of this issue though.
This morning this issue has repeated and is now far worse, with every Display affected by the issue (approx 16 displays). Now all that it’s doing it this:
Furthermore, the ‘Manage’ page of one of the diplays looks like this. the ticker hasn’t downloaded which could be part of the problem. However, nothing has changed with the tickers on these layouts. The tickers pull through dataset data, and I’ve also checked there are no special characters just in case.
Update:
I have tried clearing the CMS cache but the error still persists on all displays. This error is preventing the displays from downloading anything at all - they won’t even change layouts.
Have you checked for duplicate names on displays and layouts. Media, urls, file paths, etc, are not using non standard characters? You don’t have more than say 90 items on a layout/playlist?
Have checked for duplicates. Nothing out of the ordinary with Media, URL’s etc. None of them using non-starndard characters. Each layout only has a couple of regions with one item in each (just displaying dataset content).
I thought it might be dataset content causing the issue, but the screens won’t event change download new layouts.
I tested some of the php files in the cache folder using a syntax checker and some of them returned the same error as shown in the log. This makes me think that the CMS is creating broken layout files to send to the displays.
There was a ‘/’ in one of the dataset rows, however I removed this and replaced with a ‘-’ character instead which I know works from previous use.
Changing this hasn’t done anything unfortunately.
I’ve also searched the dataset for the backslash and there definately isn’t any of these.
I found another Cache folder in the Library folder and deleted. It’s now regenerated the cache and almost all the screens have come back online and updated themselves. I’ll keep monitoring and try and do some further testing soon.
So perhaps it was the ‘/’ in the dataset data that was cached, and therefore causing the issue.
Hopefully @dan might be able to shed some light on this.
I am wondering if the problem will not return if the layout is altered slightly, causing it to re-save and then resync the layout with the client, and re-introducing the problem.
I think it might be arising when the layout is edited. I remember running into something similar in RC1, which we are still using due to bugs affecting us in RC2.
Last post for now. This is the content from one of the cache files that seemed to be the cause of the error in my first post. You’ll notice the extra curly braces. This failed the PHP syntax checker because of this,
I would suggest that this is fixed in 1.8.0-rc2 onward. The cache key you have identified causing an issue is not used anymore due to problems with contention on that key. It is possible that several things might have tried to write to it at once, perhaps causing the corruption you are seeing, but more generally making the cache return unstable.
We’ve adopted a different approach that completely eliminates that key.
1.8.0-rc3 will most likely be out early next week, and if you wanted to wait then blowing up the cache would be a workable solution. Otherwise a quick upgrade to rc2 should help.
