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.

the random nature of the problem has meant that i have not yet been able to generate debug logs for this problem, which occurs when capturing live feeds from live streaming sites like myfreecams and chaturbate. however, inspecting windows task manager while the issue is occurring suggests that there might be some sort of memory leak involved. the problem is associated with a sustained period of 100% cpu usage during which time jmr process consumes an ever increasing amount of memory, until all systems resources are used, the ethernet connection fails and jmr crashes. typically, the issue arises when capturing multiple streams simultaneously. it doesn't seem to happen when capturing single streams. the problem with providing debug logs is that once the problem becomes apparent, jmr has to be terminated and restarted. and often a system reboot is required to regain internet connection. and once you've done that the problem does not reoccur. at least not immediately. mostly i use jmr to make unattended recordings, and i only discover there's been a problem when i return to discover jmr has crashed. occasionally, i'll find jmr still apparently recording streams that have long since finished. sometimes if such recordings aren't interrupted, they will eventually complete. but if new streams come online, they won't start to record, unless jmr is terminated and restarted. at which point, everything seems to return to normal. the ever increasing memory usage seems to be significant to the issue. if anyone else has experienced similar, perhaps they might contribute their experiences?

have at long last managed to capture logs for this issue, although they may also include evidence of other misbehaviours, as the captures kept dropping prematurely requiring the streams to be refreshed.

here attached logs for another capture session where the captures first appeared to stall, but then continued long after their stream broadcast had ceased. one stream actually started after its source webpage had closed.

yes. definitely a memory leak problem of some sort. it's not just task manager that displays ever increasing memory consumption by the jmr process. several times now the jmr application window displays some kind of "out of memory" error message when it's crashed, bringing the whole operating system down, and requiring a os reboot.

i use jmr to record rtmp streams from both myfreecams and chaturbate. currently, i'm viewing both sites via chrome Version 75.0.3770.100 (Official Build) (64-bit) on windows 8.1. as i tried to explain previously, it's virtually impossible to get log dumps of this problem that i've been experiencing, because mostly it causes a system crash, and always requires jmr to be restarted. so it's never clear whether the logs that i have managed to produce actually capture the problem or not. also as i've mentioned before in another post, with some myfreecams hi-def streams jmr does this weird thing of recording a few seconds of a stream before stopping and starting a new recording of the same stream. i don't know, but i've always assumed this was related to the bitrate of the stream being altered/adapted.

i've just this minute tried viewing myfreecams using firefox, after reading the recording webrtc on myfreecams post. mostly jmr records rtmp streams. the streams of broadcasters using webrtc do not appear to be being detected. for me at least, chrome seems able to detect streams from all broadcasters on that site. it's just that some of the streams appear to cause a memory leak in jmr.

If its a system crash then it might be due to winpcap on your Windows 8.1 system.  

Try npcap - https://nmap.org/npcap/#download

When installing ensure winpcap mode is selected via the checkbox.

Strange that you are getting RTMP streams from these sites as I dont, no matter which models I click on and Im using chrome to, but on windows 10.

Anyway see how it goes with npcap ....

thanks for the suggestion.

in fact, i have already tried using winpcap (supplied with jmr), win10pcap (download), and most recently npcap (download). i am currently using the jaksta legacy network monitor. in every case (what i'm now going to refer to as) the memory leak problem has arisen, the first signs of which are that the size and duration fields on the details view stop advancing. the problem can be confirmed by opening task manager which shows 100% total cpu usage (even though the sum of the individual processes is nowhere near 100%) and an ever increasing memory usage for the jmr process. sometimes if chrome is closed, at this point, the "stalled" stream recordings will eventually resume and complete, and can even include new streams that weren't even listed in the details view when the first stream recordings stalled. but most times, jmr just continues to consume more and more memory until it crashes and, or the system loses internet connection. i have not been able to associate these stalls with any particular broadcaster on either site. they just seem to happen at random. i'm guessing that some sort of stream error causes jmr to start caching the stream data that it is receiving. perhaps if there is some process in jmr that does that, it could be monitored, so that corrective action could be taken when too much data is being cached? i have also trawled the internet without success for information about spurious 100% cpu task manager reporting problems, hoping that it might shed some light on the jmr problem. and although i previously reported that the problem seemed to be associated with multiple simultaneous stream recording situations, i've since experienced jmr slowdowns/ghosting/crashes with single stream recordings when only chrome and jmr have been running on the computer.

here's a log of a capture session that stalled using npcap, though i've had to switch back to the jaksta legacy network monitor, as it seems to work better for me. also uncovered the myfreecams debug controls by poking around in the clientside code which allows me to force the video_player mode to something other than flash. didn't get very far with that as jmr only seemed able to detect flash streams. at some point in the past jmr was detecting and downloading (hls/dash/webrtc, i not sure which) broadcast streams just from the myfreecams popup cam previews. but that hasn't happened for me in a while. so maybe my jmr settings are funked up?

Try disabling flash in Chrome and dont click the link which appears at the top as per image below.  You can disable just for the page by clicking the lock icon next to the domain name and selecting block or ask.

That should force Dash, which can be downloaded (instead of recorded) and hopefully perform better on your machine.

Also can you please use this one.  Its been in beta for about a month with a few users.  May thing is performance improvements to the monitor function.  Not sure if you use that for your cam sites.

Also deploys npcap now instead of winpcap (but still supports winpcap).

http://downloads.jaksta.com/release/jak7/JMR7/7.0.2.0/JMR7-7.0.2.0.exe

employed your tip for forcing dash and did a clean install of the beta you recommended and everything seemed to be going swimmingly, except for the fact that two copies of the camcast were downloading, until the camcast i was test viewing ended, at which point the download status of both recordings changed from "downloading" to "complete (errors)" "the remote server returned an error: (404) not found" "size: 0 bytes time: 00:57:20" which was unexpected. the next couple of tests just threw up "this stream protocol is currently not supported" errors. the download properties revealed both to have been webrtc camcasts. using the myfreecams debug controls i was able to force dash, which allowed the streams to be downloaded, so long as they were manually interrupted before the camcasts ended. because it seems that if the camcast is allowed to end the result is a 0 bytes download as before. this is all kind of new to me. but i seem to have gone from a situation where i was able to make unattended camcast stream recordings, somewhat unreliably, to one where i can make 0 byte unattended downloads more reliably.