CRT6900N Version 6 Service Manual.
Other names this rig is known by are Anytone 5555, Alpha 10 Max and many more.

https://www.computersense.co.nz/forums/a...ERVICE.pdf

The QRM Eliminator X-Phase has a PTT port to bypass circuitry of the Eliminator during Transmission to prevent damage.

The positive (12-Volt) central tap of the PTT RCA Port needs to be shorted to Ground to activate the bypass circuitry of the Eliminator to prevent damage to both Eliminator (mainly) and Rig. 

The problem is that the CRT6900N Rig (also known by many other names like AnyTone 5555N and Alpha 10 Max) does not have a PTT (Ground) Jack.

One would think that it would be a simple wiring up of the PTT function on the Microphone Jack but DON'T do that! It won't work and may cause damage to the Rig.

It was suggested that the voltage from the Red Transit LED be used to trigger a Transistor which, in turn, would be used to ground the positive terminal of the Eliminator.

I found that the voltage over or before or after the Red LED's Resistor and LEDs was either too erratic or too low to make any sense of. The Red/Green LED doesn't share a common Ground to chassis so this seemed to be too problematic and also hard to physically access.

I found a suitable point that gives 8 Volts on Transmit and was easy enough to get to and solder a wire.
I tried at first a Solid State Relay but it would activate the Eliminators TX LED but not its Internal Relay.
I then tried an Opto Isolator, it behaved pretty much the same and couldn't keep up and popped.

Using a BC547 Transistor produced promising results but the Transistor got hot.

With the help of a Radio Specialist (Andy Bosworth), I was told to use a couple of Resistors of suggested values but had no success. The Eliminator's TX LED would light up but not the Relay. Eventually, and through trial-and-error and trying 50 different values I got this working.

Andy mentioned that, in a normal situation, the values he provided should have worked but he was unfamiliar with the X-Phase Model I am using (pictured here).
   
   

So, with this in mind, I share the details here but take NO Responsibility for damage caused.

   

Error:
Cashbook Complete
It looks as though the installation is still running!
Please wait for it to complete, or else re-run it if it has failed.

   

Have re-installed CB Version 6.50d multiple times and also rebooted the Computer multiple times.
Cannot get past this error no matter what we do.

Anyone?

After initial Server "unplanned" Shutdown (BSOD/Crash, hang or power failure), Windows creates Registry flags which are used to prompt the User/Users after a reboot for reason of unplanned reboot.

In a normal situation, after the User acknowledges the prompt, those Registry flags are removed/reset.
In many situations the Registry flags are not removed/reset even after acknowledging the prompt which leads Windows to perpetually prompt after every clean reboot.
Some say that that recent Security Updates are to blame and some with a focus on .NET.

The actual cause is insufficient Permissions on the Registry keys that are flagged - only Local Administrator has the Permission to successfully acknowledge the Prompt to clear the Registry flags.

You need to provide the correct Permissions to the Registry Key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability
In this case, we have given Domain Administrator's Full Control of this Key (not just Local Administrator). As this Server is also an RDS (Terminal) Server, we have given Domain Users Full Control too but that is your personal choice and may not be desirable if only you, the Domain Administrator, want to acknowledge/see this Prompt.

   

To manually clear the Registry Flags remove (delete) the Registry Values DirtyShutdown, LastAliveStamp, TimeStampInterval under the above Registry Key (or reboot the Server and acknowledge the Prompt again)

The native Windows Ping command can't record timestamps in the results without a lot of fussing around.
Use PowerShell and bang-out the following command to get timestamps on the ping results (replace COMPUTERNAME with either the Host Name or IP Address).

ping.exe -t COMPUTERNAME|Foreach{"{0} - {1}" -f (Get-Date),$_}

To send your results to a text file, pipe the results by appending the following.

ping.exe -t COMPUTERNAME|Foreach{"{0} - {1}" -f (Get-Date),$_}>c:\temp\pingresults.txt

Full Error Message when backing up Exchange with GRT enabled:

V-79-57344-862 - Backup Exec Agent for Exchange not used for last full backup of this database.  You must use the Exchange Agent to run a full backup before you run a differential or incremental backup.

Completed status: Failed
Final error: 0xe000035e - The Backup Exec Agent for Microsoft Exchange was not used to create the last full backup of this database.  You must use the Exchange Agent to run a full backup before you run a differential or incremental backup.
Final error category: Resource Errors

For additional information regarding this error refer to link V-79-57344-862

I have seen this on all Versions of Backup Exec when using Incremental backups on Hyper-V and other Data using separate Backup Jobs.
Although, indeed, other types of Backups will cause this (Windows Backup or other Backups performed by other Software).
Full Backup Jobs are not affected by this error.

Incremental Backups rely on the Attribute set on a file to determine if it has been backed up since modified/created. These Attributes are then flagged (unflagged) during the Backup process. If other Backups of the same Data are run prior to your Backup Exec Job then Backup Exec will get confused and throw this error. 

For us, we run separate Incremental Backup Jobs for Hyper-V and Data.
Turns out that, if we first run the Hyper-V Job then the Data Job, the Backup will fail with this error on the Data Backup.
If we first run the Data Job and then the Hyper-V Job then the Backups "usually" go through without this error.
Backup Exec somehow "thinks" that the previous Hyper-V Backup Job was to blame - not sure how but we have been able to reproduce it.
The problem still lays with the next Incremental Backup (second Incremental Backup after the Full Backup) - some sites, using different Windows Server and Hardware Versions, have unpredictable results - some work flawlessly and others throw these errors.

At some sites where there is ample storage available on the destination media and time-slot available, we do Full Backups instead of Incremental and lengthen the retention period.

If you're backing up Hyper-V with Server 2016/2019 you will notice additional files created with extensions of MRT and RCT.
These files are created by new features of Hyper-V introduced in Server 2016/2019 called "Resilient Change Tracking".

   

The "Resilient Change Tracking" feature is manipulated during the backup of Virtual Machines in which these additional files can aid in recovery of VMs - personally, I don't understand the mechanics involved so I will leave that research up to you.

While not every environment is a clustered one, there have been questions relating to the simple copying of VMs from one Hyper-V Host to another while these files are present.
In our test lab we found that Data was consistent when copying with or without these MRT or RCT Files present.
We found that, if the MRT and RCT Files were copied alongside the VHDX File, the files would become realised and active (not orphaned) and life continued as usual.
If we didn't  copy the MRT or RCT Files there was no Data loss and life continued as usual.

So, if you are here looking for reasoning over what effect these files have on Data integrity during a move/copy, rest assured that there is no Data Loss if you are accustomed to manually copying Virtual Machine Files from one host to another.

This CCTV system is a step above the cheap Chinese ones that I have been using over the past 15-years. Cost has always been a factor in my decisions (isn’t that the same with everyone?).

The initial installation did not go as planned.
Initial setup was positive as we used 0.5M Network Patch Cables to each Camera to test before replacing existing Cameras.
It was a simple plan: to remove the existing PoE Cameras and DVR and replace them with the Reolink Cameras and DVR.
This plan soon turned to custard after days of trying to figure out why none of the 6 Cameras would connect but the old ones would continue to work OK.
It turned out that these new Reolink Cameras demand CAT6 Cabling – all would work OK with CAT5 as long as the cable runs were not longer than 5M.

So, mission accomplished; replaced all CAT5 cabling with CAT6 (400M in total) and all Cameras working as expected.

I’ve been running CCT since day zero but always limited to the cost-factor and ending up with cheap Chinee crap – forever upgrading hoping that things would get better but never did.

I had two simple demands.
1) be able to identify number plates and
2) provide Video evidence to the police without stuffing around.
My biggest peeve was always having to apologise to the Police that it took so long to firstly download the footage and then convert the Video from some weird and bizarre CRAP Video Format to something they could actually use without losing quality.
The Reolink system “partially” solved these issues as I will explain here:
Downloading Video footage directly to MP4 file format is a saviour (no more of that crap H264 to deal with)!
No more having to dick-around with third-party programs to convert while loosing quality.
The downloading of Video takes a long time and not what I expected from a brand with high score marks but still quicker than having to dick-around by converting H264 crap afterwards.
The Video Quality (compared to my previous 1024--resolution HD H264) is not that amazing and I was disappointed in that number plates were still not decipherable when they should be.

What pissed me off was:
1) Reolink 5Mp Cameras came on to the market (Amazon) two weeks after I received my 2Mp Cameras AT THE SAME PRICE!
2) That the Reolink Cameras you purchase are dedicated to their own DVR – meaning you cant use the Reolink Cameras on a non-Reolink DVR – or even use Reolink 4Mp Cameras on a Reolink 2Mp DVR!
3) The CPU usage is mostly maxed out (using 6 of the 8 supported cameras) - seriously underpowered CPU.
4) Response at switching quickly to the Software (Reolink Client) to check on something is sluggish and if left for more than 30-minutes or so shows all feeds as blank (white) screens until one is double-clicked to bring into the foreground. I suppose this would not affect some users who have the Software open all the time on a dedicated monitor but, for me, by the time you have messed around you have missed the live action.

Edit: Tried downloading footage today for an incident. The Software (Reolink Client) kept crashing after the first few video clips. It took multiple attempts to download one or two clips at a time.

Still experiencing...

Try as you may, you are probably here because, no matter what you do, you cannot turn off the Screen Lock of Windows 10 or it annoyingly logs you out after a time-out period (even though you have disabled all of what you could through Power settings).

Apply this Registry Patch to fix the problem.


  ScreenTimeout.reg (Size: 5.87 KB / Downloads: 307)

BackupExec Console Crashes when trying to open it:

   
 
Turns out that .NET Framework 4.8 is the culprit – in particular the security update for it.

Remove one of the following Updates to resolve the issue:
Windows Server 2012 R2 - KB4486105
Windows Server 2012 - KB4486081
Windows Server 2016 - KB4486129
Windows Server 2019 - KB4486153

I suspect that future Versions and Updates to .NET Framework will also result in a broken Backup Exec Console so keep this in mind.