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.

TMDSCSK388: Display freezes after 30 seconds

Part Number: TMDSCSK388

When running the application on the TMDSCSK388 starter kit board, configured (via the web app) to only stream MJPEG via WiFi (and display the RTSP stream via VLC on a PC) and simultaneously display on an HDMI monitor, the stream stops (i.e., the screen freezes and VLC loses connection) after about 30 seconds.  Has anyone else had more success with this configuration?  I want to use this as a reference design, but I am concerned that the software is not robust.

  • Hi John,

    Could you give more details about the application running on TMDSCSK388 starter kit board. Do you have some console logs. Could you observe the cpu load and processes using cpu with "top" command before, during issue appears and after that.

    BR
    Tsvetolin Shulev
  • I am running the IPNC RDK 3.9.1 reference application from the supplied binaries.  Here is the console log and the cpu load information.  They are mixed together since the application background processes spit to the console, while top is also writing to the console.  It is hard to pin down exactly when the application freezes, but it is somewhere between 60 and 90 seconds after startup; there is really no indication of a failure in the console that I can see.  My primary concernwas whether or not anyone else has gotten this to run reliably for several hours, so we know that the code and hardware configuration are fundamentally sound.  RDK_3_9_1..log

  • FYI, I think I have narrowed the issue a bit.  It seems that it only happens once I have configured the application in the web-app to be single-stream MJPEG.  Once I remove the settings from NAND and restart, the application seems to run without issue.  This suggests that there is an issue with the application-level implementation, but not with the lower level libraries or the hardware, which alleviates my biggest concerns.

  • I've noticed that it does seem to make a difference if the system was started in single-stream mode (i.e., the system was initialized from the settings in sysenv.cfg) or if it started in tri-stream mode and was changed via the web interface to single-stream.  While this seems to make no difference when single-streaming H.264 encoded video, MJPEG encoding causes the display to freeze and generally kills the system after a short period of time when started in single-stream, although it seems to take much longer to die, if it started in tri-stream mode and is changed via the web interface to single-stream.  This is definitely a bug, and since single-streaming MJPEG video is our target configuration, this is a concern.