You mean there is another bug?
How can I find out what it is, or how can I file a bug report for it?
Maybe you could ask Moode if their product includes these squeezelite fixes.
and
I asked, this is getting really annoying after such a long time 
Is there any way to see squeezelite output?
I understand this can be frustrating… The use case to use LMS and squeezelite for doing notifications from a home automation platform was not something that was really anticipated by the authors. I’m very appreciative that ralphy was able to push a fix.
Yes. There are some rather extensive debugging options, but I’m not sure how you would enable those in the Moode product. Also note that debugging squeezelite is not for the faint of heart. I ended up compiling squeezelite for my ubuntu box, then spent quite a few days trying to instrument squeezelite in order to find the streaming issue with small mp3 files.
-d <log>=<level> Set logging level, logs: all|slimproto|stream|decode|output|ir, level: info|debug|sdebug
One thing you could try before chasing this down the rabbit hole… If you have a pi, install the latest piCorePlayer to see if the problem you’re having goes away. That might be an indication that there’s an issue with the version of squeezelite in Moode player.
I enabled the logs, but cannot really interpret them:
(Rockantenne is a radio station that is interrupted by the notification stream).
Squeezelite is running with the following arguments (maybe it’s a wrong option?)
root 21638 5.1 32.7 148556 145668 ? S<Lsl 18:28 0:35 /usr/local/bin/squeezelite-armv6l -n Mobile -o hw:0,0 -a 160 4 1 -b 40000 100000 -p 45 -c flac,pcm,mp3,ogg,aac,alac,dsd -W -D 500 -R E
Do you have any idea if this can be tested locally on the raspberry-pi by executing squeezelite with a sample file?
You could copy one of the VoiceRSS mp3 files out of userdata/voicerss/cache, then play it in any player.
You also could manually add that VoiceRSS mp3 file to an LMS playlist, then play it to see what happens.
According to moode the fixes should be included … 
So it must be something else I guess
I am using OpenHAB2 2.3 incl. latest Squeezebox binding (2.3 Snapshot).
All MP3 content is playing well on SqueezeBox sink.
All WAV files (e.g. created by TTS) are not playing.
FLAC files never did (although almost all SqueezePlayers are able to).
I assume the Squeezebox binding has an issue with the file type because other sinks (e.g. webaudio) do not have any issues playing WAV files or creating voice output.
An option to convert TTS to MP3 prior to playing would be a workaround 
The LMS has issues playing some WAV files. Attempting to play a variety of WAV files resulted in some playing and some not playing. I didn’t do an extensive analysis, so I don’t know the specific reason why some play and some don’t.
If you’re using MaryTTS, the LMS will not play those WAV files. I tried adding them directly to the LMS playlist and they would not play. Perhaps there’s a plugin for the LMS that will play them, but I’m not aware of one.
Mark, is it possible to use notification sink in squeezebox to play sound effects instead of speech?
You can use the playSound action in a rule to play MP3 files that are placed in the conf/sounds directory.
Hmm. Yes I use it, however i thought playSound plays via standard “sink” as it works with Volume instead NotificationVolume.
Anyway, when listening some music from playlist and using playSound to play notifications (like “ding dong”) it often happens that notification sound is not removed from the playlist as it should be and so it ramains on the playlist and the playlists stops. It’s very annoying. Any hints?
What version of the LMS are you running?
You can do this, which plays on a specific sink at a volume of your choosing.
// Play the sound on a specific sink at a specified volume level
playSound("squeezebox:squeezeboxplayer:5919BEA2-764B-4590-BC70-D74DCC15491B:20cfbf221510", "doorbell.mp3", new PercentType(45))
I’m using piCorePlayers with LMS installed on one of them and it’s version is 7.9.1.
I guess the problems start when playSound is used before the previous notification ends. How to make sure playSound is not used before the previous sound is still playing ?
While I haven’t tried this, you could funnel all your notifications through a single rule (maybe using one String item as the proxy for the say message and another String item as the proxy for the playSound mp3 file.
Then, by wrapping the rule logic with a reentrant lock, you could ensure that subsequent executions of the rule wait for the currently executing rule to complete.
This only might work if the say and playSound actions block (which I think is the case).
Note the LMS is a bit sensitive to the timing of playlist modifications, which is what the binding relies upon for notifications. Sending multiple notifications that run concurrently likely will cause the LMS to mess up the playlist.
1 Like
My goal is to have a DP for everything. 
This one describes what you are suggesting: Design Pattern: Gate Keeper.
If not then it gets complicated but the overall approach would still work. There would just need to be a way to tell how long it takes to say the text (maybe an algorithm that estimates the length based on number of characters would be close enough) or play the sound (perhaps a map file?)
1 Like
And you seem to be approaching that goal. 
Yes, I think it does. Don’t know how I missed this DP. Thanks!
An algorithm based on the # of characters would work well for TTS, but it would be hard to estimate the length of an MP3. I’m banking on say and playSound blocking.
I meant for the MAP part of my suggestion to handle that. Put each filename in a .map with the number of seconds for the file. Then
val length = new Integer(transform("MAP", "mp3.map", filename))
Of course this assumes you know all the mp3s ahead of time.
I posted a question about this (TTS and add to playlist) a couple of days ago, also added a feature request about it. 