• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 665 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Recovery from BadParameter event in EZSDK.

Stephane St-Hilaire
Prodigy 210 points

This is a general ezsdk question, it applies to pretty much any version though I am using 5.05 at the moment.

How is an application supposed to recover from a component sending a BadParameter after you send the command to transition it from loaded to idle?

In my particular case I am configuring the videnc parameters and none of the configuration calls give any errors. It's only when I request the component to switch to idle that it sends this error asynchronously, at that point it is not clear which parameter is wrong or out of bounds.
Also it is unclear what, if any, steps can be taken to recover from this, as the component is in limbo between loaded and idle states.
Any ideas/recommendations would be welcome. 

Find attached a log from one instance of this problem.

6180.bad_parameter.txt

  • 0
    TI__Guru**** 170625 points

    Hello,

    OMX_ErrorBadParameter means that one or more parameters were not valid.

    Which OMX function you are using for transition from loaded to idle state? What parameters do you pass to that function ? Can you share you code.

    I am not aware of any recovery method when these type of errors occur (full OMX re-init is needed), but I will further check for this.

    BR

    Pavel

  • 0 in reply to Pavel Botev
    Prodigy 210 points

    On the bad parameter side we found the cause and got rid of it, there is still however the general issue of recovery from these sorts of failures.

    When you say OMX re-init you mean reloading all the firmware and the application from scratch? This would be a quite disruptive event from the user of the application's point of view.

    This is not really what one would expect from a professional SDK... Error handling should be more than an after thought.