Skip to main content

"Failed to save the data" when saving a MagicINFO schedule

On MagicINFO Server 21.1070 this message usually means the server refused the schedule's frame-layout value (400002, [frame.lineData] Not allowed value.), which the web editor sends in the wrong spelling on one save path. Retrying cannot work, and nothing is written to the server logs.

Symptoms​

  • Save or Save and Publish in the schedule editor shows "Failed to save the data. Please try again."
  • Trying again gives the same message, while other schedules save normally.
  • The server's application logs show nothing at the time of the save.

Cause​

Each schedule frame carries a layout type called lineData. For a normal single-frame schedule, the database stores it as ZeroFrameOnly. The REST API that the editor saves through accepts only ZERO_FRAME_ONLY, FIXED, CUSTOM, CUSTOM_LAYOUT, CUSTOM_FIXED or an empty value. It does not accept the spelling the database itself uses.

The web editor normally converts the value before it saves. On at least one save path, which we traced to the save dialog's copy mode, the conversion is skipped, the stored spelling goes to the server, and the server rejects the request with HTTP 400.

The rejection is an input-validation error. Those are returned to the browser only and never reach MagicINFO's logs, which is why the server looks healthy.

note

Not every "Failed to save the data" is this one. Any invalid field produces the same message, so always do step 1 first.

Fix​

  1. Confirm the cause in the browser. Press F12 and open Network. Save again and click the failed content-schedules request (method PUT, status 400). In Response, look for "errorCode":"400002" and the field named in errorMessage.
    • [frame.lineData] Not allowed value.: continue with step 2.
    • Any other field: that field is your clue. Correct it in the editor and save again.
  2. Server-side check (optional). If your server keeps a Tomcat access log, the failed save appears as PUT /MagicInfo/restapi/v2.0/dms/content-schedules/<id> with status 400 and a response size of 188 bytes. That size matches exactly this message, so you can find affected users without asking for screenshots. Windows installs we have seen keep the access log in tomcat\logs or runtime\logs\access, and some keep none.
  3. Something to try. If the error appears when you save a copy of an existing schedule, building the new schedule from scratch or saving it from a normal edit may avoid that path. We have not confirmed this in every case, so check the response again (step 1) after you try it.
  4. Longer term. This is a server-side issue in some MagicINFO builds, not something the user did wrong. Check whether a newer MagicINFO Server build or patch is available for your installation. If a hosting provider runs your server, ask them about it.

How to confirm it worked​

Save the same schedule again. The PUT request returns 200, and the schedule appears with its new version. If you publish it, the publish status moves on for the target displays. On the server, the 188-byte 400 responses stop appearing in the access log.

Checked against MagicINFO Server 21.1070 behaviour, October 2026.

Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.

Last updated on