Couple of questions:- Are the errors related in that they occur as a consequence of each other? In other words, once the first error occurs, then the second error is generated.
- Do they occur if another browser is used (e.g.: Firefox or Chrome)?
- Does every computer the client uses generate the same results or do some client machines successfully run the application?
What I can tell from the messages:- The first error is generated by ToolBook, but it does not mean that it is ToolBook's fault. It is just telling you that you are trying to use a value as a number and it is failing because the value is not a number and may even be null or unset.
- The second message is generated by the PowerPac when the video attempts to load into the object named "VideoPlayer." It seems likely that the first message may be producing the second since the PowerPac is simply indicating it cannot load a movie into "VideoPlayer" with the parameters it is receiving.
- The first message is the one I'm most concerned about because it begins with "http/1.1 Bad Request." This means that your application tried to request information from the server or server database and could not process the request. When you tested this on YOUR server and did not receive an error, it likely because the server-side script requesting information could be processed and finished successfully and apparently returned a value to the application that could be treated or used as a valid number for other tasks. However, on the client's server, (assuming their server is different from yours), the process fails and is probably throwing a string complaining of the problem it encountered. The string returned from the client's server that causes the "http/1.1 Bad Request" is the string you need to know exactly what its content is. It likely holds the key to the problem.
What do I think you will find?The error string in #3 above may be one that indicates a server-side script is using an incompatible scripting language on the client's server to request data. Your server doesn't experience this because it had all the installed server dependencies to process the request and succeeded. An example of this could be you are using a script that requires PHP v5.6 or greater and the client's server has v5.3 installed.
Another possibility:
If an LMS is involved, it could be that the client is requesting a stored value from a previous session that was never actually set. In this case, your application needs a contingency for this sort of thing.
In summary:It is the FIRST error dialog that needs to be addressed and once the issue is tracked down and solved you may eliminate the second automatically.
If it is possible to zip up the export (and dependencies) and send it to me, I may be able to at least simulate the problem. But, it would be best if you could address some of the questions and possible issues above so we can eliminate some of this logic. Otherwise, this would be "trouble-shooting in the dark," which is not very productive.
Would also recommend starting a different topic since I don't think this truly a "bug report."