DFP panels intercom stuck in broadcast receive?

[marcuslee]

Hi All,

Have 9 DFP panels, and I've just noticed (remotely) that 3 of them are in Broadcast Rx mode, the remaining in Mode: ShutDown.

As they're only configured for use as Hands free + Broadcast, or for the door bell to be played (all the other annunciations have been turned off), I suspect it must be from a door bell playing exercise earlier in the day.

I've seen oddities with the door bell broadcast before which is what leads me to suspect that it's the door bell, however is there anything further I can do in troubleshooting why there are some panels still in Broadcast Rx?

Thanks in advance,

Marcus

[marcuslee]

I've since figured out what caused it. A client PC connecting with RDP client, and it was forgotten to disable redirection of Cortex PC, and after disconnection of RDP client, it was left in odd state of not having an audio device to play wav file.

Came across this when checking the log folder.

I'd still be interested to know any troubleshooting tools though!

However regarding the RDP audio redirection, AFAIK it's not actually possible to prevent this on the RDP Server side / this from happening. I don't suppose anyone else has come across this and found a work around??

[spellinn]

This happens to me all the time (several times a week) and I've yet to find a way to stop it other than going round cancelling the broadcast mode on each panel. Very annoying.

I've configured my RDP client to not redirect the remote audio as per the client settings below

rdp_audio.jpg

It would be good if Cortex could recognise this odd state and automatically cancel broadcast mode after a set period.

Regards


Neil

[chris_j_hunter]

just to note, we're getting lots of this - other's must be, too, surely ...

they do time-out, so might go un-noticed ...

in our case, we have MFPs, and we use them for announcements, as well as intercom', and it seems to be with these it happens ...

one sign would be time-out files in the Logs folder ...

everyone ... please have a look & shout if you have any clues as to why & when !

we're running 26.10.2 ...

[spellinn]

one sign would be time-out files in the Logs folder ...

I do see lots of log files that begin with:

Instigator = Sound DecideSoundState exception
Product name = 26.10.0
Product date = 13th June 2014
Licence ID = 01061
Log Date = 04-11-2014
Log Time = 20:36:34

And my DFP panel then stays with the Speak and Cancel buttons illuminate until I press cancel on them.

Regards

Neil

[chris_j_hunter]

interesting - ours begin with :

Instigator = Sound playing on event timeout
Product name = 26.10.2
Product date = 5th September 2014
Licence ID = xxxxx
Log Date = 11-6-2014
Log Time = 16:28:41

and at least one of our MFPs behaves likewise …

[Viv]

When Cortex plays a Sound it requests the windows media player to do it.
Windows responds with an event to say that the Sound playing has finished.
If Cortex does not receive the event within a suitable time it reports it as an error.
This is what the "Sound playing on event timeout" is.

It would seem if another application has re-directed the audio, Cortex does not receive
the event that says the sound has finished playing so that it knows to turn off
the intercoms. It should eventually recover.

The "Sound DecideSoundState exception" is a seperate issue that we were not aware of
until now. This is a default response for an unhandled error. If Neil could send us the
data it will help to locate the issue.

Viv.

[chris_j_hunter]

aha - not sure what if anything might be running alongside Cortex, will have to use Task Manager to find out ...

[Viv]

A similar condition also applies regarding speech synthesis. That is, after speaking, the speech engine within Windows should respond with a speaking complete event which informs Cortex. Cortex can then shut down the panels.

Viv

[Viv]

It would be good if Cortex could recognise this odd state and automatically cancel broadcast mode after a set period.
Neil

Cortex should clear the intercoms after 3 minutes if the media player does not respond in this time. Perhaps the clearing routine is in error. Perhaps this should not be regarded as a error.

Are you playing .Wav, mp3 or other types of file?

In next update cortex will calculate from the file how long it should take to play. With a bit of contingency it will then terminate the session if windows does not respond rather than wait 3 minutes.

Viv

[spellinn]

The "Sound DecideSoundState exception" is a seperate issue that we were not aware of
until now. This is a default response for an unhandled error. If Neil could send us the
data it will help to locate the issue.

You should now have my logs as part of the support request I sent from Cortex late last week (About the annunciation issue..which I wanted to resolve as it compounds this DFP issue!)

My DFP's certainly don't recover..they sit with the two buttons illuminated indefinitely.

I know *why* my Audio system gets disabled..it's a quirk of RDP under Windows 2008R2 server when you connect it. Given I don't use voice prompts this generally isn't an issue although did prevent me from using the Alarm functionality of Cortex.

Cheers

Neil