Jaksta

recently experiencing problems with live stream recording whereby jmr appears to become increasingly unresponsive, so that stream recording appears to continue way beyond their broadcast termination, with any subsequent stream captures starting late and finishing even later, as if the captured streams are being buffered. noticed that task manager often reports total cpu usage at 100% during such episodes, even though the sum of the individual processes is much less than 100%. have not so far been able to capture any debug logs for such events, as there doesn't seem to be any pattern to their occurrence. wondering if anyone else is experiencing similar. this seems to be unrelated to the blank/black video stream problem i posted about previously.

easier said than done. but here's an example of a camcast that ended with a 0 bytes download. had to use the myfreecams debug controls to force dash. and use the jmr prompt settings, which means unattended captures are out of the question. mostly jmr just doesn't seem to detect streams when i try to pre-select the quality and format. which is why i resort to the prompt settings. even when dash is set, there are signs of the memory leak.and, in fact, i had to kill the jmr process a couple of times when the application stalled, before i was able to capture an example for you. stalling is almost guaranteed if a flash recording happens to be triggered while a dash download is occurring. i have no idea how to get you logs of that, as the only way to recover is a re-launch of jmr. is log data preserved over a re-launch?

fyi, the log may contain a short flash recording at the start, as that was the default broadcast format of the first cam i opened, and before i enabled the debug forced dash setting. the second stream in the log was videojs/dash and lasted about 10 minutes before being ended by the broadcaster, resulting in a 0 bytes 404 error result.