HansF

Hi there Brebenac, Thanks for your answer. I checked the firmware and it has the most recent version (v1.000.0000 dating from 14-04-2017). I can’t find any newer version anywhere. I contacted Dahua Benelux to see if they are planning an update but they couldn’t confirm that, nor did they say anything about building in a choice in which audio you can use as a ringtone. It seems I am left to my own devices here, as Dahua is not willing to help out.

Hello everyone, My name is Hans, I live in The Netherlands and I am new to the world of cctv. Recently I have bought a Dahua VTO2111D-WP video door intercom for my front door. I am not very satisfied with the “ringtone” it has: the person pressing the button at the door hears a voice message instead of a regular ding-dong sound. So I would like to replace it with a sound that resembles a door bell rather then an answering machine. The VTO has an embedded Linux OS (DaVinci) to which I have root access. When I connect with PuTTY I can see that the audio file I want to replace is /mnt/data/Sounds/Dutch/call.mp3. /mnt/data is a cramfs mounted from /dev/mtdblock10 so you can browse it, but you cannot modify it with new audio files in any easy way as it is off course read only. So far I managed to get mtdblock10 from the VTO to my Ubuntu 14.04 system with ftpput. On the Ubuntu machine I mounted it and copied the fs with the cpio -pdm command to a new directory that is rw. I replaced the call.mp3 with a an mp3 with the same name, bitrate and frequency containing the sound of my liking. The new file turns out to be about half the size of the original, 6 Kb instead of 13 Kb. With mkcramfs I made the modified fs into a file again called mtdblock10_new (thanks to https://kaarthik.wordpress.com/2007/12/31/modifying-cramfs-image). As I compare mtdblock10 and and my home brew mtdblock10_new with file- and stat-commands I get some strange differences: > mtdblock10: Linux Compressed ROM File System data, little endian size 806912 version #2 sorted_dirs CRC 0xdf7cbaaa, edition 0, 384 blocks, 216 files > File: ‘mtdblock10’ > Size: 1179648 Blocks: 2304 IO Block: 4096 regular file > Device: 801h/2049d Inode: 2228234 Links: 1 > Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2018-02-21 17:47:13.301951177 +0100 > Modify: 2018-02-10 23:40:55.000000000 +0100 > Change: 2018-02-21 17:47:12.289951177 +0100 > Birth: - > mtdblock10_new: Linux Compressed ROM File System data, little endian size 798720 version #2 sorted_dirs CRC 0xcd73551a, edition 0, 382 blocks, 216 files > File: ‘mtdblock10_new’ > Size: 798720 Blocks: 1560 IO Block: 4096 regular file > Device: 801h/2049d Inode: 2228236 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2018-02-21 17:54:49.049951177 +0100 > Modify: 2018-02-21 17:54:24.761951177 +0100 > Change: 2018-02-21 17:54:24.761951177 +0100 > Birth: - The biggest difference is the size and the number of blocks, which I can't explain because ultimately there is only 6 or 7 Kb difference in the file I replaced. When I mount mtdblock10_new however then it is exactly the same size as the original. So I gather the new cramfs is compressed more then the original. Now as I only have a basic knowledge of Linux I am a bit wary of having done this not in the right way, risking the vto getting bricked or otherwise rendered useless when I deploy the new cramfs on it. So I turn to this forum, hoping to find someone who has experience with this kind of action and who knows and can explain the pitfalls, which undoubtedly are there, or even just give a big warning if this is an entirely bad idea all together. Thanks!