I believe I’ve found a bug but before I document it in github I’d like to know if others have experienced this problem. I’m using the “monitor” function to record repeater audio. We have one node that mixes audio from three RTCMs plus anyone coming in over Allstar - pretty basic. Audio is recorded to a WAV file (date_and_time_stamp.WAV as filename) each time some keys up until they unkey (one file per key-up). With the “previous” (very old) version of Allstar (many many years old, but unsure which version), every file contained audio, as would be expected. With ASL3 I’m finding that most files are 1K in length and contain no audio. The only files that appear to have audio are from people who are connected to the node via Allstar. Also, every now and then we get a file that is recorded from someone coming in from an RTCM that sounds like some kind of techo music (it’s very musically interesting, actually - maybe an incorrect CODEC or something), otherwise its just a 1K file with no audio content.
The line that activates the monitor feature in our rtp.conf file looks like this:
Yes, permissions are correct (they were incorrect after the install, but I fixed that; another bug I need to report). Per original post, files are being written with EVERY key-up/down, and files with audio are being written when the recording is of someone attached to the node via Allstar, so writes are working properly; just “empty” 1K files whenever attached user is via an RTCM.
I probably need to ask if asterisk has the right to create a subdirectory in your
Because it will want to create the sub (nodenumber) and the files should be going in there.
Each node has it’s own directory by node number when written.
/var/spool/asterisk/monitor/43763
But you could make the directory manually and give it a spin.
Don’t forget to check owner and permissions of that directory before your test.
The files are being written just fine, so asterisk must have the proper permissions. The problem isn’t in creating the files; the files are being created just fine and in the /var/spool/asterisk/monitor/43763 directory. I had to manipulate permissions manually to make that work (so there is a bug in the code regarding this), but that is not what I’m reporting here. The problem is the contents of the files, not the ability to write the files.
It appears that Andriy_Grin has reported the same problem already (above).
You should know that they’re are just a few of us on the development team, that we’re all volunteers, and that our availability is limited.
If you are looking for a status update then you are welcome to post a comment in the GitHub issue. Most of us are available on Community but we don’t always notice every post. For this issue, I think the answer is that it’s just still in the queue. As for escalating, explaining why this needs to be fixed sooner would help.
Also, since you filed the GitHub issue a while back I will ask whether you’ve updated/upgraded/tested with the latest version? Adding a comment to the issue like “Still not working with app_rpt version x.x.x” will help us know that it’s still a bug.