You are on the wrong website for RMC support.
As noted in another of my replies, I used Applian Replay Media Capture for many years. First it was their code. They dumped it, and went to reselling Jaksta but with their own GUI front end. Applian dumped the GUI front end, and went to just reselling Jaksta. Applian sucked for support. They don't do support. Any defect reported to Applian got redirected to Jaksta, wait for Jaksta to fix the problem, Jaksta reported to Applian the problem was fixed, and Applian sometimes got back to me the problem got fixed. I gave up on Applian, and went to Jaksta which is what Applian was selling, anyway.
I am in the correct forum. I have Jaksta Media Recorder, and that's what I meant to ask about.
So, do you have a clue why JMR is creating the D:\RMC file? It happened when I had Applian's RMC when it was a resell of JMR. It happens in JMR. Why? Nothing in settings says to use the D: drive. Nothing in JMR's settings has the "RMC" string. I even did a hex search through JMR's files (in its installation folder, and in the apppath folders), but no RMC string.
No I dont have any idea unless you have that set as your output path for something.
Debug logs may tell me more.
It could be many days or weeks before I happen to notice D:\RMC (file, not folder) got created. Having debugging turn on when JMR starts could result in a huge log file (apparently in some SQLite database file), or maybe the logs get discarded after exiting JMR. I might incur many sessions with JMR before the rogue file shows up.
I modified the batch file used to start JMR to halt and alert when it detects the presence of D:\RMC. That will be too late to enable debugging in the prior JMR session to catch the cause for creating this file, but it might help me to remember what I was doing in the immediate prior session of JMR to try to replicate it.
I could also use SysInternals ProcMon to monitor when a process touches the D:\RMC file. However, Procmon captures all events, and filtering on a file create of D:\RMC just filters the event list to show just those create events for that file. Because all events are captured (but can be filtered down to those of interest which does not reduce the log size), the log can get huge in a quick hurry, and this will slow down Windows to eventually become nearly unusable.
I will keep investigating on what is creating the D:\RMC file, but it only happens after many sessions of using JMR, plus I have to check when the file got created which is usually a side effect of reviewing my backups on D:\ which usually only occurs when there is a backup error. Halting the batch script used to load JMR when D:\RMC is found might help.
I think I found it, and it wasn't with JMR (or even back when it was happening with RMC). In VLC media player, the output folder for video snapshots was D:\RMC. This was the output from JMR of where to save captured videos, and I reused the folder for when taking snapshots in VLC. I was actually trying to resolve a different problem in VLC regarding playback (not immediately looping back to beginning of video, but showing a black screen for a second, and then starting from the beginning). It was when I was looking at VLC's settings that I noticed the D:\RMC output folder for taking snapshots when playing a video.
I couldn't find anything in JMR in its settings, or even when doing string searches into its files. Now I know what D:\RMC was so erratically appearing: I rarely take snapshots within a video, and usually it's because I click the toolbar button accidentally.
I'll leave my batch script checking for D:\RMC after exiting JMR, but I think I found the culprit. Instead of reusing JMR's output folder, I'll use a different one just for the VLC snapshots, so I know what that folder appeared.
Back in Replay Media Capture (RMC) version 7, and now in version 2022 version, RMC is sometimes creating a file at D:\RMC. This is not a folder, but a file having no filetype. No setting in RMC is configured to save data on the D: drive. D:\ is where I store backups, and I don't want applications polluting that drive. Maybe in an older version, D:\RMC was used for the Output Folder, but E:\JMR has been used since version 7, specified now in 2022, and perhaps used even back to version 6. The D:\RMC file is binary, so its content is all gobbelty-gook to me.
The D:\RMC file is not always created when RMC is started, or even after a session of recording videos. I'll notice it sometime later. That's why I have to use a batch file to run RMC, so the batch script has commands to cleanup the pollution that RMC leaves behind (*), like D:\RMC (the unknown file in question here), and the Jaksta subfolders under %appdata% (local and roaming) since I have no desire to have RMC recover a prior session (but no options to disable a resume function), and also to ensure all jmrp.exe processes get killed (they can be get hung, perhaps due to a lack of communication, like status from the ffmpeg.exe process was lost when it was done capturing a stream, to get left behind after exiting RMC).
(*) There is also an "%localappdata%\Jaksta_Technologies_Pty_L" folder created by RMC, but that holds the user-configured settings for RMC, so my cleanup batch script does not delete that folder.
I've done a content search on all files under the RMC installation folder, but no file has the "D:\RMC" string. Didn't find the string under the Jaksta subfolders in the %appdata% or %localappdata% paths, either. I cannot find anywhere in RMC settings where D:\RMC is specified, yet occasionally RMC decides to create a D:\RMC file.