Considering you have tested this with 2 installs now,
The one thing in common is your soundfile and your script.
Perhaps concentrate on those.
things like owner, permission, correct file encoding etc
But I would try to make it work in testing with an existing file in the system first to increase your chances of finding the error. It may be more than one.
It’s beyond what help might be provided in just guessing.
If you can provide the text of the error that can be seen while watching asterisk in the foreground when this happens might be some help.
asterisk -rvvv
This plays the file fine:
root@allstar-3:~# asterisk -rx ‘rpt playback 49520 /etc/asterisk/rpt/k5fdrepeater-hector’
The absolute path is required. All of the files play fine this way. And again, after restarting asterisk, it will play the idrecording one time, about 30 seconds after restart. Previously it would then play the idrecording sometimes and I’m not sure if anything changed since I opened this thread, but now it seems to only play once after restart and never again. I have heard the tailmessage 3 times ever in ASL3, each after playing a sound file with playback. I can send the sound files to someone if they want to take a look at them, but since they play fine with rpt playback I don’t think there is any issue there. I have tried regenerating the sound files with the same result. I just opened asterisk -rvvv and played the plinuse file, one can see where it did not play without the path and then did play with the full path provided. I heard the sound file play on the repeater system. I will leave it open and see if any errors are generated. I haven’t been able to find anything in the past.
Connected to Asterisk 20.9.1+asl3-3.0.4-1.deb12 currently running on allstar-3 (pid = 16293)
allstar-3CLI> rpt playback 49520 plinuse
[2024-09-29 06:16:12.363] WARNING[16732]: file.c:825 ast_openstream_full: File plinuse does not exist in any format
[2024-09-29 06:16:12.363] WARNING[16732]: file.c:1322 ast_streamfile: Unable to open plinuse (format (ulaw)): No such file or directory
– Hungup ‘DAHDI/pseudo-987402979’
allstar-3CLI> rpt playback 49520 /etc/asterisk/rpt/plinuse
– <DAHDI/pseudo-872204688> Playing ‘/etc/asterisk/rpt/plinuse.ulaw’ (language ‘en’)
– Hungup ‘DAHDI/pseudo-872204688’
[2024-09-29 06:23:27.431] NOTICE[16317]: dnsmgr.c:225 dnsmgr_refresh: dnssrv: host ‘register.allstarlink.org’ changed from 162.248.92.131:443 to 34.105.111.212:443
allstar-3*CLI>
Well this is interesting. While I was watching the cli I got bored, opened another terminal and did this:
root@allstar-3:/usr/share/asterisk/sounds# asterisk -rx ‘rpt playback 49520 hello-world’
and it played just find, then the idrecording played!
[2024-09-29 06:28:27.431] NOTICE[16317]: dnsmgr.c:225 dnsmgr_refresh: dnssrv: host ‘register.allstarlink.org’ changed from 34.105.111.212:443 to 162.248.92.131:443
– Remote UNIX connection
– Remote UNIX connection disconnected
– <DAHDI/pseudo-1059101267> Playing ‘hello-world.ulaw’ (language ‘en’)
– Hungup ‘DAHDI/pseudo-1059101267’
– <DAHDI/pseudo-1355046725> Playing ‘/etc/asterisk/rpt/k5fdrepeater-hector.ulaw’ (language ‘en’)
– Hungup ‘DAHDI/pseudo-1355046725’
[2024-09-29 06:33:27.430] NOTICE[16317]: dnsmgr.c:225 dnsmgr_refresh: dnssrv: host ‘register.allstarlink.org’ changed from 162.248.92.131:443 to 34.105.111.212:443
allstar-3*CLI>
Always messes with me because every once in a while it will play.
Again,
if not in the default directory, the full path must be described.
Again,
If the repeater goes into sleep mode, nothing will play unless invoked by the scheduler or outside event. (it would have to ‘wake-up’)
Some things to watch as you debug.
rpt xnode node#
Will show you state of the vars
tail_type=0
ider_state=2 < when it = 2, it is asleep.
I don’t have any cop commands enabled, there is no sleepmode in any file in /etc/asterisk, and I have never seen it say anything besides idle status in allmon, unless it’s transmitting. Does it go into sleep mode with default settings?
allstar-3*CLI> rpt xnode 49520
3125232 1 IN 00:15:22 ESTABLISHED ~
This morning so far after I opened the cli to watch for messages, the idrecording seems to be playing. I thought that might have something to do with changing ownership of the sound files from asterisk to root, so I changed them back and restarted and still they are playing. I intentionally have not made any other changes today.
I thought this would specify a different sounds dir but maybe I’m misunderstanding what it does
nodenames = /etc/asterisk/rpt ; Point to alternate nodename sound directory
Does sleepmode show up in allmon for status, or is that just the ider that goes into sleepmode? The way idrecording just started playing again for unknown reason sure does sound like sleepmode was on and now it’s off. Now I know how to check that I will confirm if it stops again. Very weird that an entirely new instance of ASL3 was not playing idrecording just like the previous instance and then it just starts playing again.
I just mean that Allmon shows the node status under the node listing under the top blue bar in the light green bar on the Dashboard page. Mine typically says “Transmit - Ide” but will say other things when it’s keyed up or allstar is saying something. When first mentioned sleepmode I thought it would show “Transmit - Sleep” or similar and not sure how I got that idea. No matter really as I can use xnode to find out as you said. I will keep watching it.
ider_state flips between 1 and 2 and seems to have no effect on when the idrecording plays. It will play in the 2 state and not play in the 1 state and vice versa. I uncommented the cop commands 951 and 952, they have no effect on the ider_state. I don’t think sleep mode and ider_state are the same thing, or the cop commands are broken. There is no output after the command in the cli
[2024-09-30 04:33:17.588] DTMF[49070]: channel.c:3894 __ast_read: DTMF end ‘’ received on IAX2/jake-dvswitch-14899, duration 0 ms
[2024-09-30 04:33:17.588] DTMF[49070]: channel.c:3921 __ast_read: DTMF begin emulation of '’ with duration 100 queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:17.688] DTMF[49070]: channel.c:4042 __ast_read: DTMF end emulation of ‘*’ queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:17.749] DTMF[49070]: channel.c:3894 __ast_read: DTMF end ‘9’ received on IAX2/jake-dvswitch-14899, duration 0 ms
[2024-09-30 04:33:17.749] DTMF[49070]: channel.c:3921 __ast_read: DTMF begin emulation of ‘9’ with duration 100 queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:17.849] DTMF[49070]: channel.c:4042 __ast_read: DTMF end emulation of ‘9’ queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:17.908] DTMF[49070]: channel.c:3894 __ast_read: DTMF end ‘5’ received on IAX2/jake-dvswitch-14899, duration 0 ms
[2024-09-30 04:33:17.909] DTMF[49070]: channel.c:3921 __ast_read: DTMF begin emulation of ‘5’ with duration 100 queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:18.009] DTMF[49070]: channel.c:4100 __ast_read: DTMF end emulation of ‘5’ queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:18.068] DTMF[49070]: channel.c:3894 __ast_read: DTMF end ‘2’ received on IAX2/jake-dvswitch-14899, duration 0 ms
[2024-09-30 04:33:18.068] DTMF[49070]: channel.c:3921 __ast_read: DTMF begin emulation of ‘2’ with duration 100 queued on IAX2/jake-dvswitch-14899
[2024-09-30 04:33:18.169] DTMF[49070]: channel.c:4100 __ast_read: DTMF end emulation of ‘2’ queued on IAX2/jake-dvswitch-14899
Idrecording worked for a while yesterday and then stopped a couple of hours after it started yesterday and don’t see why it started again or why it stopped. Going to give allstar 1 a try again. We were planning on using ASL3 with the idrecording and tailmessage features but since neither one seems to work reliably going to have to go back to ASL1 yet again.
Can you please open a GitHub issue @ ASL3 (or app_rpt) with details on your configuration, what you are trying to achieve, details on the audio files you are trying to play (e.g. file type, paths), and any information in the log files around the time frame when you believe the recordings should be playing.
Just a FYI as I don’t want others reading later to be mislead by that comment.
Commenting or Uncommenting a dtmf command will not change it’s
‘state’.
Just allow you or deny you ability to issue the command ‘by dtmf.’
You still have to DTMF the command if it is not commented out.
Commenting it prevents anyone from running it and changing the current state.
It is simply the dtmf digits assigned to the command. You still have to issue it.
*951, *952
You need to talk to someone local who has a better understanding of how the settings work and their format and purpose.and can help guide you through your issues in front of you.
Mike: please carefully read my posts before responding. I don’t want people to see your comments and get confused. It’s quite obvious that the commands need to be issued as well as uncommented, and if you had taken the time to read my post, you would have noticed the cli output that shows me entering the commands.
Yesterday someone linked to the node and keyed down. I heard the idrecording right after. Then I tried dvswitch and keyed down and the idrecoding played. It never plays when someone keys down on the radio, just linked nodes and dvswitch using iaxclient. Once yesterday evening it did not play the idrecording after keying down with dvswtich, it actually played the tailmessage. That is the one and only time I have ever heard the tail message except after using rpt playback. I dont’ see any way to change the config so that it will id when people key on the radio side. I did find that in my new instance the duplex=0 snuck back in there and it had only been iding to iaxclients and not on the radio. With duplex=1 it now will id to both radio and iaxclients, as expected. Still it never ids when people are on the radio only.
No I don’t think so, looking for typical repeater iding. So if the repeater has been idle for more than X minutes and someone keys down, after they unkey, allstar plays the idrecording after some delay. That is what our system has done for many years using a RC96 controller. And I thought that is what idrecording would do in a similar manner. Not doing any idtalkover at this time, just hoping for “normal” idrecording behavior. At the current time, this is working when I key down on dvswitch, it plays the idrecording back on the phone and it goes out on the radio as expected. But, if I key the radio, the idrecording never plays. At least that is what it is doing right now. Sometimes it never plays either radio or dvswitch/iaxclient no matter which way the system is keyed. But since yesterday morning, on a newly installed ASL3 node, it will id when someone linked over iax, another node or iaxclient, but not when someone keys the radio.
idrecording = is the file
idtime = 540000 is the interval of idrecording while awake if sleep enabled. it will not play again till timer expires.
if rpt xnode node# = ider_state=2 (no activity inside of idtime) it will not continue to ID unless sleep mode is OFF and will do so at idtime interval.
Without idtalkover, the idrecording will play over user speech at idtime= interval.
Which is why you should use a cwid for it.
idtalkover = |icallsign a cw id by example.
politeid = 30000 ; time in milliseconds before ID timer expires to try to ID in the tail. (optional, default 30000)
if rpt xnode node# = ider_state=1, there will be one more ID before the node can go into sleep mode and not ID until there is activity which will change the ider_state.
initially,
It will start off with a idrecording on the next keyup and idtime aftwards while active/awake.
If it is not continuously iding at idtime interval, then the node is sleeping and sleep mode is enabled.
sleeptime= ;in seconds of inactivity
This is not consistent with a RC96 controller, but you can come close depending on exact needs.
As I remember it, ACC had a intial ID, a Pending ID and a Talkover ID and could have a Dropout message, not to be confused a tailmessage.
But I may not remember it as well as I think.
You failed to mention dvswitch before, so I might ask
Is your dvswitch connection you are monitoring results from via iax directly to the node,
or is it via a connected usrp private node ?
A usrp private node connection will have it’s own settings within that private node not related to a connected public node and will respond to it’s settings regardless of the public node ID settings.