GPIO en Cartwall problem

You found a bug or have any issues? Please post them here!
moogwill
Posts: 389
Joined: 28 Feb 2016 12:31
Re: GPIO en Cartwall problem

Post by moogwill »

This morning same issue again, "autoplay" switching on/off like in a fast loop. After closing and rebooting GPIO the loop is gone, but then it sounds like if automation was late to the software (The early begining of each sound is missing). Nothing in the GPIO error Log. I'm gonna reboot with with GPIO debug mode on, to try to understand what is wrong. My problem is I can't stay up all night or wait all day in front of the screen to be there at the moment it goes wrong. :-/

Edit: Maybe not related, but I discovered that sometimes, the waveform in the player are not the one from the file (that is probably something I did wrong with MLS)
User avatar
radio42
Site Admin
Posts: 6990
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: GPIO en Cartwall problem

Post by radio42 »

See my post above... I assume your D&R mixer is sending messages like crazy... unplug the mixers USB cable or use the 'Monitor' function to validate this... and then probably call the D&R support.

To your 2nd issue:
I am sorry, but I have never heard, that the WaveForm is not the one from the file currently being loaded to a DJ Player ;-)
Have you maybe saved the WaveForm to a file (.pfwf) and then changed the physical audio file without updating the WaveForm file again?
Else, I believe this is merely impossible.
moogwill
Posts: 389
Joined: 28 Feb 2016 12:31
Re: GPIO en Cartwall problem

Post by moogwill »

Hi Bernd,
can you have a look at these. it looks that midnight is the fatal hour.. but I still don't understand the cause of this.

Thanks.
Attachments
GPIOdebug.rar
(73.09 KiB) Downloaded 365 times
User avatar
radio42
Site Admin
Posts: 6990
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: GPIO en Cartwall problem

Post by radio42 »

It is pretty much evident, that your Airlite (starting at almost 00:00:00) permanently and constantly sends (multiple times per second) a STATE_NON_STOP (Active and Inactive) event!

04/05/2017 00:00:00: AirliteCallback: Type=EVENT, ID=STATE_NON_STOP
04/05/2017 00:00:00: DispatchCommand: PLS_CURRENT_AUTOPLAY_OFF
04/05/2017 00:00:01: AirliteCallback: Type=EVENT, ID=STATE_NON_STOP
04/05/2017 00:00:01: DispatchCommand: PLS_CURRENT_AUTOPLAY_ON
04/05/2017 00:00:01: AirliteCallback: Type=EVENT, ID=STATE_NON_STOP
04/05/2017 00:00:01: DispatchCommand: PLS_CURRENT_AUTOPLAY_OFF
...

As this leads to permanently turning AutoPlay on and off.
So I guess (as already said), it sound like it is time to call the D&R support!!
Maybe your NonStop switch has a defective connection or the firmware is buggy?! Nothing I can solve, but only D&R I am afraid...
moogwill
Posts: 389
Joined: 28 Feb 2016 12:31
Re: GPIO en Cartwall problem

Post by moogwill »

Bernd,
could it be a timing problem, that @ midnight the change of day & playlist takes too much time to respond and then get's contrary reaction between the software and the Airence?

Here's the feedback from D&R support:
Dear Thomas,

You wrote:
“The state of the airlite goes from normal to a strange loop that make « non stop » goes from on to off.”

- I don’t think this is Airlite related since the Airlite doesn’t have any idea of current Time.
- Airlite simply responds to commands from proppfrexx OR send a message on an occurred event like button pressed.

03/05/2017 00:00:00: DispatchCommand: EXEC_SEND_DRAIRLITE_REMOTENONSTOP 1
03/05/2017 00:00:00: DispatchCommand Reply: OK
03/05/2017 00:00:00: AirliteCallback: Type=EVENT, ID=STATE_NON_STOP

From the log above one can see the nonstop command is sent from proppfrexx to the AIrlite.
The airlite responds with an EVENT with ID=STATE_NON_STOP

Important is Proppfrexx should not react on the nonstop EVENT by for example sending again the EXEC_SEND_DRAIRLITE_REMOTENONSTOP 1 command.

To test the nonstop feature, close proppfrexx and start the Airlite Meters application.
You can click on the NON_STOP button/light indicator on the right side of the application.
If you are able to remotely turn on /off the nonstop of the mixer, you can assume everything is ok.
meisterpropper
Posts: 86
Joined: 03 Aug 2012 09:36
Re: GPIO en Cartwall problem

Post by meisterpropper »

I discussed the problem with moogwill and perhaps it´s related to the start type "soft", because Airlite seems not to work well with start types, which open up a new playlist for a new show while another playlist from the past program is opened at the same time. Is it possible to have a warning at the scheduler, whenever GPIO Airlite is activated and somebody tries to use start types except the timeupdatesync start types?

I´m not 100% sure, if this will solve the problem, but as other broadcast software doesn´t use different playlist windows it could be the reason, why only ProppFrexx users get this problem?
moogwill
Posts: 389
Joined: 28 Feb 2016 12:31
Re: GPIO en Cartwall problem

Post by moogwill »

Anyway I changed all my starts type in the scheduler.. will keep you updated about the result...
thanks again, both of you.
T.
User avatar
radio42
Site Admin
Posts: 6990
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: GPIO en Cartwall problem

Post by radio42 »

As said: I don't think, that this has anything to do with your StartType!!!

You should better try to understand where exactly you issue the "EXEC_SEND_DRAIRLITE_REMOTENONSTOP" command(s)!
This is your problem... because you actively change the NONSTOP switch!
User avatar
radio42
Site Admin
Posts: 6990
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: GPIO en Cartwall problem

Post by radio42 »

No.
It might be not time related, but what I see in the log is, that ProppFrexx receives STATE_NON_STOP messages from the Airlite.
These events originate in the Airlite resp. the airlite.dll provided by D&R.
I cannot generate them myself.

As D&R indicated: OR send a message on an occurred event like button pressed
That's why I said, it might be a 'defective connection' of the NonStop button?!

But as I don't know your setup and mapping and control-commands you are using... maybe it is you yourself sending the EXEC_SEND_DRAIRLITE_REMOTENONSTOP constantly... ;-)
But I guess this is nothing to ask me - but rather yourself.
You should know, if you are sending the EXEC_SEND_DRAIRLITE_REMOTENONSTOP command somewhere?!
ProppFrexx doesn't do that by itself...
User avatar
radio42
Site Admin
Posts: 6990
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: GPIO en Cartwall problem

Post by radio42 »

I don't understand, why this should be handled.or a warning should be given.
Nor do I believe, that the issue of "moogwill" is related to multiple playlists being open.
a) this is a pure event and control-command handling issue
b) it is more obvious, that "moogwill" or who ever implemented the Airlite events/comamnds/mapping somehow configured a loop:
- ProppFrexx sends "EXEC_SEND_DRAIRLITE_REMOTENONSTOP 0" command
- in return the Airlite STATE_NON_STOP event is received and captured, which
- triggers to send a "EXEC_SEND_DRAIRLITE_REMOTENONSTOP 1" command
- in return the Airlite STATE_NON_STOP event is received and captured, which
- triggers to send a "EXEC_SEND_DRAIRLITE_REMOTENONSTOP 0" command
etc.
you are now in an endless loop.
This has nothing to do with a program starting 'Soft' or 'Fixed' or as a 'TimeUpdateSync'.

Note, that your can even handle the state of the playlists in your events/commands mapping - so there is no restriction of how a D&R console handles or expects things - a console is always agnostic on how a playout system works.

Post Reply