debug log in stub

Answered

Comments

5 comments

  • Avatar
    lechee lai

    what happen got following queue overflow

    0
    Comment actions Permalink
  • Avatar
    Nx Support

    NX_PRINT (as well as NX_OUTPUT) goes to mediaserver's stderr/stdout. You can see it in mediaserver's console window (if you are running it from the console), or, in case you are running the Server as a service, check the service's log: journalctl -u networkoptix-metavms-mediaserver.service. NX_DEBUG_* macros are not for logging, so you can't see any output from them.

    It seems that pushCompressedVideoFrame or pushUncompressedVideoFrame or pushDataPacket function (I don't know which one of these you are using) works too slow in your case - at least it takes longer for it to work, than the inter frame time interval. That is why the queue of frames is growing.

    Could you please explain what exactly you want to achieve and how? That might help us to understand your problem.

    0
    Comment actions Permalink
  • Avatar
    lechee lai

    Thanks for the tips I just following the standard stub implementation seems using pullMetadataPackets(...)

     

    so does queue overflow is normal??

    0
    Comment actions Permalink
  • Avatar
    Nx Support

    Queue overflow is abnormal and actually means that the time needed to process a frame is longer, than the time interval between 2 subsequent frames. You can try to run the unaltered stub and check its log to see the difference - I think that you won't find any queue overflow messages there.

    Seems that something slows the frame processing a lot, did you make a lot of changes to the plugin?

    Maybe you can think of some change you made that can increase the frame processing time?

    0
    Comment actions Permalink
  • Avatar
    lechee lai

    Thanks Team I leave a sleep inside the loop cause queue overflow :-p

    0
    Comment actions Permalink

Please sign in to leave a comment.