Server: info/Info 1 not currently working correctly

[Punkley]

"info" and "info 1" are currently returning the same information.

Tools like Justmacros uses info 1 to get the channel information about what is going on.
Currently info 1 isn't working correctly and is just returning the same data as info

info is also showing that a channel is playing even if nothing has started

[2018-03-12 19:14:49.811] [info] Received message from Console: info\r\n

200 INFO OK

1 1080i5000 PLAYING

[2018-03-12 19:14:49.811] [debug] Executing command: INFO
[2018-03-12 19:14:49.811] [debug] Executed command (0s): INFO
[2018-03-12 19:14:49.813] [trace] Ready for a new command
info 1
[2018-03-12 19:14:53.238] [info] Received message from Console: info 1\r\n

200 INFO OK

1 1080i5000 PLAYING

[2018-03-12 19:14:53.238] [debug] Executing command: INFO
[2018-03-12 19:14:53.238] [debug] Executed command (0s): INFO
[2018-03-12 19:14:53.242] [trace] Ready for a new command

[ronag]

@niklaspandersson @5opr4ni I don't remember how this should work?

@Punkley what does it return in 2.0?

[Punkley]

Look at #612 there is an example there for "info "

[ronag]

ah yes, this is xml INFO. That's been deprecated. INFO 1 should return an error.

[Punkley]

That's actually not a good thing to deprecate in my opinion.

It will break tools like justmacros for getting the info about channels.
(and a bunch of my tools)

what has it been replaced with?

Kingsley

[5opr4ni]

for example an info 1 could return this:

info 1
201 INFO OK
<?xml version="1.0" encoding="utf-8"?>
<channel>
   <video-mode>1080p5000</video-mode>
   <stage/>
   <mixer>
      <mix-time>0</mix-time>
   </mixer>
   <output>
      <consumers>
         <consumer>
            <type>decklink-consumer</type>
            <key-only>false</key-only>
            <device>1</device>
            <low-latency>false</low-latency>
            <embedded-audio>true</embedded-audio>
            <presentation-frame-age>160</presentation-frame-age>
            <index>301</index>
         </consumer>
      </consumers>
   </output>
   <index>0</index>
</channel> 

http://casparcg.com/wiki/CasparCG_2.1_AMCP_Protocol#INFO

/o

[premultiply]

In my opinion OSC is no replacement for any AMCP info request/response.

[didikunz]

I still do Flash templates and I also have a lot of existing Flash templates out at my customers systems. And a lot of them use the INFO command to query a video clip loaded from the template for readyness. Some also use INFO PATHS. As OSC is not easy to implement inside ActionScript it would braek all that stuff. And the XML should also not change too much.

[dotarmin]

INFO will come back in v2.2.0, with the reservation that the XML-structure could be changed but is not decided yet!

Cheers! 🍻 😄

[Julusian]

@dotarmin which info commands are returning?
There is the commonly used channel 1, but there are others of varying usefulness.
I ask because I have found a bunch of dead code from info template ... and am wondering whether to remove it

[ronag]

INFO 1 i.e. channel info is implemented. It directly converts OSC state into XML and outputs it. I need feedback.

Ping @5opr4ni @dotarmin

[Punkley]

ive got a pretty big gig this weekend, I will check straight after :)

[dotarmin]

@ronag INFO 1 i.e. channel info is implemented. It directly converts OSC state into XML and outputs it. I need feedback.

I will check this tomorrow as well. However I'm not sure I will be able to give you instant feedback as you hoped until it has been evaluated more, which can be done when I'm back from my vacation.

@5opr4ni will you have some time for checking this while I'm away?

@Punkley ive got a pretty big gig this weekend, I will check straight after :)

Thanks! Good luck with the gig! 😄

[dotarmin]

I have been checking out this now and it looks good. However, I have some questions regarding the XML returned.

Why is there two <fps/>elements? Is the first child always the clips original fps? I have noticed that the second child is either 1 or 0, what does it stand for?

<streams>
  <0>
    <fps>25</fps>
    <fps>1</fps>
  </0>
</streams>

Is it guaranteed that the first <time/> element always is the current time of the playback and second one is always the clips total length? If that's the case then I'm fine with having same name on the elements otherwise we should maybe have other names for those. If we can guarantee the order of the elements in the XML and decide this is the order, then I'm just fine as I wrote, otherwise it would be hard to determine what is what.

<time>10.66</time>
<time>10.720000000000001</time>

Good job Robert! 😄

[ronag]

It's a consequence of converting OSC data into XML. In osc fpsis `25,1´ where the first value is the numerator and the second one is the denominator. I'll see what I can do to improve this.

[dotarmin]

@ronag I'll see what I can do to improve this.

If it's documented well then it's maybe enough?

How about the <time/> element? Can we guarantee the order of those? Especially important when parsing the XML, it would be hard to distinguish those.

[ronag]

How about the element? Can we guarantee the order of those? Especially important when parsing the XML, it would be hard to distinguish those.

Same thing. Numerator & Denominator.

[TondaKrist]

Works great except doubled info.
It is possible to implement info about background media in response XML too?
Like in old INFO command. To have info about cued/prepared video too.

Or is there an anther way how to get it? I can not see it through OSC

[Punkley]

Finally got to have a test,

I noticed that when you loadbg it isn't putting the INFO in the xml to tell you the next video

[euphoricz]

We use "info queues" in 2.0.7 to identify a possible AMCP overflow so the software can automatically restart CCG and reload / replay everything on all the same layers. It seems the command is no longer supported, is this correct? Has the command syntax changed or will it be added back?

The AMCP overflow can be caused by a number of things, broken flash templates, delayed streams while switching content too quickly, etc.

Some of our systems need to run 24x7 so outages or hanging channels are not acceptable, it is much more acceptable for the channel to go black for a couple seconds than for it to be completely broken.

Obviously if there is a problem with a flash template then the as3 code requires more error handling, however there are other scenarios such as delayed streams due to slow internet connectivity which can cause problems.

Point is, new flash templates are created all the time and internet connectivity issues will always be a problem. In the absence of being able to fix every issue as soon as it occurs it is more important for the software to be able to correct the problem should it occur then we can determine why it occurred and release a patch to prevent it from occurring again in the future.

[ronag]

@dotarmin can you please read through this and give me a summary of what we actually should and/or must fix or change?

[5opr4ni]

Hi!

In the latest build, the channel framerate is included in info and OSC, this makes it possible to calculate correct times. Have in mind that the channelframerate is important when doing, for example, seek and length.

[Julusian]

@euphoricz Another way for you to test that would be to do an INFO 1 for each channel and measure the time they take to respond. If over some threshold then it can be assumed that the channel has a blocked up queue.
In general commands shouldn't be blocking the command queue, ffmpeg used to but not anymore so I would hope this is less of an issue now?

[euphoricz]

@Julusian thanks for the heads up, I'll give it a try!

[euphoricz]

I appreciate the response, and I agree, this doesn't seem to be much of any
issue any longer, especially now that we are using HTML templates instead
of Flash templates.

Currently we're watching for the behavior which prompted the use of INFO
QUEUES to begin with, so far it seems non-existent.

Thanks!

On Mon, Feb 24, 2020 at 5:49 AM Julian Waller [e-mail]
wrote:

Closed #923 https://github.com/CasparCG/server/issues/923.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CasparCG/server/issues/923?email_source=notifications&email_token=ADXXNSEGMB4DQNOTOSKLMLDREOX6NA5CNFSM4EUZAEDKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOW2YR4HY#event-3065060895,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADXXNSGHNVYDYS7U2HIY3MDREOX6NANCNFSM4EUZAEDA
.