Issues importing cal recordings from V15.5 to V16

[Aiv]

Hi All,

I hope some of you can help with this very unusual issue.


At this moment we are running a V15.5 server on our local network with a bout 1TB of call recordings ( yes we call so much). These recordings are being stored on a NAS and then get uploaded to S3 bucket for archiving purposes. To allow uploading to S3 we have to rename all files as S3 client does not like [ ] and % .

Our new V16 server that we want to take in production is on EC2 ( its a windows server 2019). Everything looks to work so far as intended for one smal big problem. Our recordings are not displayed in the Recording tab. I have done recording conversion from dashboard and I even tried using this parameter " RECS_SYNC_REQUIRED " that I had found in another forum post. Unfortunately that did not help, but for some reason when I look to dashboard it does recognize there is 1TB of data in recordings folder.

Does anyone have an idea how to fix this? At this moment not being able to look up recordings is preventing us to switch to V16.

 

[JohnS_3CX]

Hi Aiv,

When you built your new V16 server, did you point the recordings folder towards where the recordings are currently stored or towards your S3 storage?

If so, then RECS_SYNC_REQUIRED will search and find them. What is most likely happening now is that the system sees there is data there but if the files were renamed however, the PBX might not be able to relink them back to the database because it sees names it no longer recognizes. Note that the PBX must have block-level access in the recordings folder (i.e SAN/iSCSI and not NFS/NAS)

 

[Aiv]

Hi Aiv,

When you built your new V16 server, did you point the recordings folder towards where the recordings are currently stored or towards your S3 storage?

If so, then RECS_SYNC_REQUIRED will search and find them. What is most likely happening now is that the system sees there is data there but if the files were renamed however, the PBX might not be able to relink them back to the database because it sees names it no longer recognizes. Note that the PBX must have block-level access in the recordings folder (i.e SAN/iSCSI and not NFS/NAS)

Hi John,

When I build our new server on AWS EC2 I used EBS ( Elastick block storage). It had drive letter D and my recordings are stored there. I have uploaded all recording to that folder before installing V16.

Just for a test I had set up another server with exactly the same config in AWS. Installed V15.5 used the same back up file to restore server and that V15.5 server recognizes all files without me having to do anything.

How weird is that?

 

[JohnS_3CX]

The fact that V15 recognised them (if they are in the same D: drive) means theres a good chance you will get them back

Please clarify if the files were renamed though, as the PBX will recognise the files in the conversion stage based on their naming convention of [Name Surname]_ExtA-ExtB_20190409135831(9) so like:

[John Doe]_000-020_20190409135831(9)
means
John Doe with EXT000 called EXT020 on the 9th of April 2019 at 13:58:31 (9th Recording)

If V16 finds these files named properly, it will convert them and show them when you click on Convert Recordings on your management console. This will take a little while if there are a lot of them.

 

[Aiv]

The fact that V15 recognised them (if they are in the same D: drive) means theres a good chance you will get them back

Please clarify if the files were renamed though, as the PBX will recognise the files in the conversion stage based on their naming convention of [Name Surname]_ExtA-ExtB_20190409135831(9) so like:

[John Doe]_000-020_20190409135831(9)
means
John Doe with EXT000 called EXT020 on the 9th of April 2019 at 13:58:31 (9th Recording)

If V16 finds these files named properly, it will convert them and show them when you click on Convert Recordings on your management console. This will take a little while if there are a lot of them.

Hi John,

The files where renamed using a tool called Bulk Rename, this was done originally on the local V15 server. The renamed files have been uploaded to the test servers D drives with all the meta data.

The file names look as fallow: John Doe_505-000000000_20190318064313(6634)

The same set of files has been used on both V15.5 test server and V16. on V15.5 server I dont even have to do a resync even if I add new files.

 

[JohnS_3CX]

I'm sorry Aiv but I don't think V16 will be able to detect them now. They need to follow the original naming convention.

V15 was more tolerant to changing the names (even though this is not something you should be doing anyway) because it only shows the files as files. V16 needs to read the files based on the original naming convention such that it can derive the A-number, B-Number, Date, Extension, Name and build a database for better management and faster performance when digging through large recording collections. The conversion tool needs the original names in order to do this for you.

 

[Aiv]

I'm sorry Aiv but I don't think V16 will be able to detect them now. They need to follow the original naming convention.

V15 was more tolerant to changing the names (even though this is not something you should be doing anyway) because it only shows the files as files. V16 needs to read the files based on the original naming convention such that it can derive the A-number, B-Number, Date, Extension, Name and build a database for better management and faster performance when digging through large recording collections. The conversion tool needs the original names in order to do this for you.

Hey John,

Thank you for all the help. I guess I shot my self in the foot by changing the names.

Guess I will have to find a way to rename everything to the way it is supposed to be.

 

[JohnS_3CX]

Hopefully if you use bulk rename utility you might be able to put the [ ] characters back and you might get away with it or at least reclaim most of the recordings if not all