[SOLVED] 9.3.7: BASH script that runs after moOde startup completes

[Tim Curtis]

Quick test and both autoplay (radio station) and readychime play, although I can't the see the usage scenarios for having both.

20250627 173702 worker: -- Miscellaneous
20250627 173702 worker: --
20250627 173702 worker: Software update:   Automatic check off
20250627 173702 worker: Auto-CoverView:    off
20250627 173702 worker: CoverView timeout: Never
20250627 173702 worker: Auto-shuffle:      off
20250627 173702 worker: Auto-play:         on, playid 4
20250627 173702 worker: Maintenance task:  360 mins
20250627 173702 worker: Current view:      reset to Playback
20250627 173702 worker: Active flags:      all false
20250627 173702 worker: Reset flags:       skipped
20250627 173702 worker: Session check:     ok
20250627 173702 worker: --
20250627 173702 worker: -- Startup complete 
20250627 173702 worker: --
20250627 173702 worker: Mount monitor:    started
20250627 173702 worker: Radio monitor:    off
20250627 173702 worker: Watchdog monitor: started
20250627 173702 worker: Responsiveness:   Default
20250627 173702 worker: Ready
20250627 173702 ready-script: Started
20250627 173702 ready-script: Wait 3 seconds...
20250627 173705 ready-script: Play OSDISK/System Sounds/ReadyChime.flac
20250627 173705 ready-script: Finished

[ils1974]

Use case: When playing the readychime you know the system is ready. When next, the radio station (or playlist) starts playing, than it's all fine.
When you don't hear anything afterwards, you know the system is up and running, but there's likely an issue with the radio station or playlist.

[Tim Curtis]

Use case: When playing the readychime you know the system is ready. When next, the radio station (or playlist) starts playing, than it's all fine.
When you don't hear anything afterwards, you know the system is up and running, but there's likely an issue with the radio station or playlist.

It could be a valid scenario. I'll have to see how much code is involved. Currently, autoplay happens before ready chime in the startup section of worker.php and it also has some checks regarding auto-shuffle which now that I'm thinking of it may also need to be part of ready chime.

Now I know why I avoided this for so long ;-)

[ils1974]

Is this pseudo code not an option? :-)

Code:

if currentQ not empty {
    tempQ = currentQ
    clear Q
    currentQ = ReadyChime
    play Q
    clear Q
    currentQ = tempQ
} else {
    currentQ = ReadyChime
    play Q
    clear Q
}

[Tim Curtis]

I don't think people want the Queue cleared :-0

[ils1974]

I don't think people want the Queue cleared :-0

According the pseudo code, the Q is not cleared. When you first put the current Q in a tempQ, play the Ready chime, and thereafter you set the Q back to the tempQ

[Tim Curtis]

Looking at the code in worker.php it appears that the auto-play block could be moved after the ready-script block but there are some complexities.

1. ready-script.sh can be user modified meaning there is no guarantee that its going to play the default ReadyChime.flac track or any chime at all. For example the script could be modified to turn on an Amp instead of playing a chime.

The program header from ready-script.sh

Code:

#
# To use this script for something other than the Default action
# add your own code below followed by an exit statement
#
#exit 0

#
# Default action is to play the "System Ready" chime
#
.
.

2. Auto-play uses the 'songid' tag from the MPD status block to determine what the last played item was. If the ready chime is played first then it becomes the last played item. This means that 'songid' has to first be saved to a temp variable before the chime is played.

3. How to determine whether ready-script.sh is going to play the chime? Prolly a new var in cfg_system table that can be set by ready-script.

4. If it's going to play the chime then some code needs to be added to wait for playback to complete before continuing on the auto-play block.

[ils1974]

1. ready-script.sh can be user modified meaning there is no guarantee that its going to play the default ReadyChime.flac track or any chime at all. For example the script could be modified to turn on an Amp instead of playing a chime.

Only my personal opinion, but for me the, readychime, is a nice way of moOde saying "I'm ready for it!". Definately when you use moOde (like me) headless. 
So, maybe just have the option to play a ready chime or not at start-up, and not having the option to execute a script? And maybe, provide the choice to select the preferred chime, but nothing more than that?
Users looking for the more advanced actions when moOde is up-and-running know perfectly how to create a bash script, and can start this alongside moOde (via /etc/rc.local for example). 
If you allow to bring in custom scripts, as part of the moOde process, you risk people will screw-up moOde because of a poor script.
Just my 2c.

[Tim Curtis]

All good points. The ready-script actually used to be a part of moode a long long time ago but I don't have anything in my notes indicating why it was removed. My guess is that it was done during one of the big code refactoring efforts.

There have been occasional requests for something like a ready-script so I thought I'd use it to implement the ready chime and tick two things off my TODO list :-)

As far as how ready chime has been implemented, of course there are alternate ways to do it as you have mentioned.
"So, maybe just have the option to play a ready chime or not at start-up, and not having the option to execute a script? And maybe, provide the choice to select the preferred chime, but nothing more than that?"

I'm not up for re-implementing it but if another dev wants to do it I'll certainly have a look at the code and help out a bit if needed.

[Tim Curtis]

Just an FYI that I was able to move the autoplay code after the ready chime.

This means that the ready chime will be played to completion followed by the Autoplay item.