The most important change is regarding RTSP sources and the new BUFFERED mode which is now the new default (may not be the case if you upgrade from another 1.2.x version).
Due to the fact it’s now buffering before actually displaying / dispatching the images the keyframe drift / artefacts shouldn’t occur anymore (excepted if the CPU usage is very high).
The potentially unwanted effects may be higher memory usage (due to the buffering) and cpu (due to faster / smoother streaming).
For this reason, the previous mode (INTERNAL in 1.2.8) is still available (now called UNBUFFERED) in case it has more disadvantages than benefits for you. You can switch back to UNBUFFERED mode and either reset the connection to each cameras or restart Netcam Studio and it should work as it was the case in previous versions.
Please let us know how this version works for you…
The installation packages for this version are available here until they are getting updated on the official servers: Dropbox - File Deleted (32-bit) Dropbox - File Deleted (64-bit)
Unfortunately, I am having the same playback issues as described in this thread: Only small portion of recording available for playback
To summarize, playback from the web client is perfect. Also playback from outside the program using VLC, Quicktime, Windows Media Player, and Movies and TV all play perfectly. The problem is when I am in the “Netcam Studio Client - Library Manager” and click to play a clip. I tried all 3 decoding settings and they all result in the same issue, in fact, I couldn’t tell them apart, and I did restart the service in between tests.
I am running Windows 10 on a fast machine with lots of ram, and a variety of SD and HD cameras.
In this case (playback from the library) the decoder type has no influence (since it’s the decoder used for decoding the camera’s stream in RTSP not the decoder for playing files from the library).
There is something that VLC doesn’t like when the videos are sent through HTTP from Netcam Studio (rather than being read directly from HDD like when you double-click on them from explorer) but I still don’t know what makes that it works sometime and it stops before in other cases since it’s not a problem in the file itself.
Thanks for the clarification on the decoder part - I was wondering whether the setting affected playback.
Yes, it’s an odd thing with VLC not liking the videos from NS. Not sure if this will help you figure it out, but when I watch a clip through the library manager, especially a longer clip, I can see the video degrading as it’s played so the video quality is definitely different than when played from explorer. It’s like the artifacts from the compression never get refreshed and the video degrades to a point where it hits some VLC threshold and VLC aborts playback. It’s also not random. If I have a clip that misbehaves, it will misbehave in exactly the same way every time. Too bad someone from the VLC team wasn’t on this forum.
It seems to come from the fact that VLC seems to seek (change the position in the requested file) after it has sent the request to play the file from the begining so NCS is already sending the the full file from the begining.
NCS’s internal server support the headers allowing to resume downloads / seek but VLC is not doing this in the same way than VideoJS does. I would need to analyze more in deep with wireshark to understand what happens and is not handled properly by NCS’s web server. Since VLC doesn’t receive the part of the file that he wants it is reseting the connection 2-3 times and then giving up (apparently). I’ll try to spend a bit more time on that issue for the next release…
Good news, I’ve got it and have managed to fix the problem.
When VLC was requesting the end of the file, I was still sending too much data instead of just a few kb. This is why VLC was not happy and reseting the connection. It will be in there for 1.3.1
Edit: it’s still not 100%, it’s better but still giving up before the end of movie sometime
Hi there. Sorry for the long delay in my response, but you nailed it! Videos now play back perfectly from the library.
I really appreciate you taking the time to solve this one. Thanks!!
Everything seems to work fine, except when I click into Global Variables, where I get an error window pop up: “RuleActionManager has not been initialized for this App Domain!”
Try renaming the file C:\ProgramData\Moonware\Netcam Studio\Server\server.config and see if it also happens with clean settings or if something was wrong while upgrading settings from previous version.
Happens only after one of the variable has changed and if the grid is being refreshed. It’s probably here since many versions but I have never noticed this behavior before. Will check how to fix that.
While testing and playing with this 1.3.5 on my different test systems for the last couple of days, I have observed an abnormal decrease of performance and smoothness of the streams.
My feeling has been confirmed and I have finally been able to identify where it comes from and fix it. I’m surprised you didn’t notice but even I didn’t at first
Anyway you should uninstall your current 1.3.5 and reinstall the one I have just uploaded and I suppose that you will feel the difference since the problem was impacting all kind of sources and making it almost impossible to generate video streams (using the Live view mode).
The current 1.3.5 should offer at least the performances of 1.3.2 + the latest features and improvements, I have also modified the file generated by LPR so that it includes country, confidence and a separator between the fields.
I did not notice anything since I am only running 1 camera on the 1.3.5 with the LPR for testing. Thanks for your vigilance and finding the issue. Have a with your coffee.
Interesting. Using the client to view the source, I am getting 30fps on all of my 30fps cameras. I have 8 cameras in total. I haven’t noticed any issues, but I’ll grab the new version anyway.
Thanks for your vigilance and finding the issue. Have a 
with your coffee.