I'm using Jaksta with LiveJasmin/Chrome.
My naming scheme is set to the default option. However, I lost 3 files as Jaksta seemingly replaced them. For example a ~230MB file was replaced with a 120kb 2 second clip of a different model's room, automatically.
Jaksta has the correct thumbnail in the list (along with size, duration, etc) but when I right click and try to "Play" the file, it just returns an error about the file not found/existing, etc.
I saw it do this to another file when I opened up the output folder. I saw the video I wanted to play, and as soon as I clicked on it, the windows thumbnail changed from the correct thumbnail to the new one.
It seems like a bug with Jaksta replacing files and not correctly naming them. It might have something to do with removing the list of files from Jaksta. For example, I might record a bunch of stuff, "Remove" the list in Jaksta, then start recording more stuff...
I was unable to recover the files using any recovery tools so I'm not sure if they're lost forever or what.
It's happening to me as-well on Jasmin. If a performer goes offline and they have a video that plays in their absence, sometimes an entire capture is replaced with the video. The recording, nor its thumbnail appears to change in Jaksta (or at least I haven't noticed). I'm guessing Jaksta accepts those videos as FMP4 at first before correcting the format and starting afresh.
Having said that, this build has been completely stable for me, unlike it predecessor.
Could you please provide debug logs showing this issue.
Haven't managed to replicate it yet today but the other thing that happens is the recording doesn't stop as a new one is created for the video.
I can't post the debug log because it is 21.5 MB. Could you please change the regulated size for attachments here. Hopefully later I'll get a normal size log of a recording being wiped.
A recording only stops if their server closes the connection or you close the connection by stopping the capture.
Wait til you have logs showing the issue. You can then share a link from any 3rd party file sharing services such as dropbox, google drive, jumpshare etc if the logs are two big. We use freshdesk for support and are limited by the size they accept as attachements. Sorry about that.
Ill try and replicate here but havnt seen it in our testing. My understanding is that when a model goes off line a video starts streaming and at that time the video replaces the main stream that was just captured? Correct me if that understanding is incorrect.
That is correct but not all performers have videos and you could be waiting ages for one to go offline, let alone replicate the issue. There's a performer with videos that I know who's around tonight, so hopefully I'll have logs for you later. If I have to use some cloud space to host the log, I'd rather not publish its address here.
Ok send the link through to support AT jaksta.com and reference this forum post in your email and ask them not to post it but just to notify me. Thx.
Im not sure how that is possible as you describe it for JMR to delete a file automatically as there is no delete in the code.
Even when you as a user delete a file and are prompted, files are moved to the recycle bin. To make it actually delete the file (instead of moving to the recycle bin) you would need to change the setting Setting > Personalization > "Delete to Recycle Bin".
If you "Remove" all as you are doing is clearing the library list - no files are deleted. Any new captures can not overwrite and existing file on your file system. The code doesn't allow it.
Can you leave debug on as per the following and do some captures and then send the logs when you see the behaviour so I can ascertain what is happening.
Please also let me know what browser you are using.
Note that LiveJasmin has its own protocol that we have implemented (its not a standard one).
They stream fragment mp4 which results in an fmp4 file which is then muxed to mp4 once the capture is complete. Most players cant play fmp4 files.
You should see this in the UI and also the files in the file system.
Perhaps the mux is failing for some reason and resulting in a small file. But in that instance the fmp4 file should still exist.
Thanks for your logs. Please try the following which corrects the issue of the muxing overwriting an existing file with the same name in certain situations.