It seems that when trying to delete a widget via the API, sometimes it will fail for an unknown reason. If we refresh the page it then seems to work. We have no idea why this is happening. It doesn’t seem to be a specific file as we get it randomly with all video and image files. (We haven not tested anything else at the moment)
With Debug on, this is what the Log show when it happens:
177 4ca21cd 2016-02-06 23:04 API DELETE DEBUG /playlist/widget/:id Storage rollback.
176 4ca21cd 2016-02-06 23:04 API DELETE DEBUG /playlist/widget/:id Widget not found
The widgetID’s we are trying to remove, are showing in the database for Xibo. (Update: They are there, but they are not the correct ones for what we are trying to work with.) We see the widgetID up till we send it via the API.
Update: Problem identified and the issue all boiled down to this:
Sometimes we don’t get the desired result.
We see that an enhancement was made, but how do we go about using the enhacement?
returning isNew on the response of the add call was put in place so that you could look through the widgets returned and pick out the new ones added by that call.
I can’t see how the widgetId on those elements could be different to the one that was actually saved - at the point of the return the data is actually saved…
Are you sure you are recording only the isNew ones?
We are investigating this more. The problem we are facing come from some code of ours before the isNew enhancement was made. We loop through a bunch of media adding it to multiple playlist all at once. (Sometimes 40+ media adds at once.) Somewhere in this process for us, occasionally our system records the same widgetID for different media being added. The CMS does not show any problems that we see,
We attempt to add more logging to see what is happening. More than likely we will find the problem within the code we have.
We are still running into this. Our most recent test show that we added media and was returned was 332, then again we added media and was given 333, added again, 332, added again 333, again 334.
How is this possible? If a media item is assigned to multiple playlist, can it get the same widget ID? Or if media is assigned to the same playlist multiple times, can it get the same widget ID? Could this be a problem with browser cache?
The ID is an autonumber in MySQL terms and is guaranteed to be unique for each widget. Widgets are unique on their playlists (they are direct children).
I really don’t see how you can get 332, 333, 332, 333, 334 out of 5 sequential calls. When this happens what is the actual result in the CMS database if you look at the last 5 records inserted into that table?
It appears to be something with the version of PHP we were using. Sometimes “== true” would fail and also “=== true”. We changed our code a bit and the problem is solved.