High HTML producer initialization time in CCG 2.3.3

[leftearsons]

Expected behaviour

HTML producer, is expected to be ready to accept CG UPDATE data messages, once successfully loaded.
I would expect to assume the HTML template fully loaded when PLAY command successfully returns.

Current behaviour

I am loading an HTML template with PLAY AMCP command.
Once the PLAY command returns successfully (202 PLAY OK), i immediatelly send a CG UPDATE AMCP command, to transfer data to the HTML template.
In case CG UPDATE command is sent right after PLAY command, CG UPDATE fails with: 403 CG UPDATE FAILED.
In order to make CG UPDATE work, i have to manually wait for about 500 - 1000 ms, after PLAY command has successfully returned.

It seems that HTML producer takes too much time to initialize, before it can accept CG UPDATE messages, as well as that the HTML producer has not fully initialized once PLAY command returns.

The required time that i need to wait before sending the first CG UPDATE command, is not constant and could frequently vary. Sometimes it works after 300 ms but some other times it fails even after waiting for 1200ms.

I am currently at the process of porting an existing project from using CCG 2.07 to using CCG 2.3.3.
The issue is not taking place when using CCG 2.07, where no wait time is required before the server successfully accepts CG UPDATE command, after having loaded the same HTML template

---

Steps to reproduce

1. PLAY 1-1 [HTML] "index.html" 1
2. CG 1-1 UPDATE 1 "<Template>DATA</Template>"

• 2nd command should be sent fast enough (<1sec), right after the 1st one returns

Environment

• Commit: 4de6d18
• Server version: v2.3.3 LTS Stable (Mar 16, 2021)
• Operating system: Windows 10

---

[mint-dewit]

Can you try loading the html template by using CG 1-1 ADD 1 "index.html" 1? I wonder if it's related to mixing play and cg commands.

I'm usually loading templates by using CG 1-1 ADD 1 "index.html" 1 "{ \"data\": \"json\" }" btw and have not seen any missed updates.

[Julusian]

There are some prior issues for this somewhere about similar behaviour with the ffmpeg producer.

In 2.2 the behaviour of PLAY changed to report that the command was accepted rather than it was successful.
This is because the 'protocol is not asynchronous', so if it wants to wait until the producer is ready before responding, then that means nothing else will be executed on that channel while it waits.
So doing 2 PLAYs will run in series, rather than then both running in parallel. The downside is not knowing when the producer has fully loaded.

To help mitigate this, you could try doing a LOADBG of the producer. Waiting a safe amount of time, then issuing the PLAY and CG UPDATE commands. That will load it into the background layer (ensuring it wont be visible), then promoting it to the foreground with PLAY which I believe will be instant

[leftearsons]

Thank you both for your prompt response.

Indeed the issue above seems to take place only when loading the HTML template by using PLAY command.
It seems that this is happening because PLAY command directly returns, even before the HTML producer has been totally loaded, as @Julusian mentioned above.

As @baltedewit correctly suggested, by loading the HTML template with the CG ADD command, the HTML producer is ensured to be fully initialized before allowing the client to continue with next commands (CG UPDATE in my case).
So, to sum up, i can verify that using CG ADD for loading the HTML template solves the issue above!

My only concern here is about the new behaviour that @Julusian described, about the FFMPEG procuder (via PLAY command).
I am aware that the AMCP protocol is synchronous (per channel), meaning that all commands received by the server will be executed one right after the other. Actually this makes totally sense, since some commands would always depend on some other commands - that is why the client has to decide the correct commands order in the first place.
The way i realize it (correct me if i am wrong), is that by using the new behaviour (PLAY command immediatelly returns instead of reporting it's successfull execution), the server somehow transfers the responsibility of knowing when a command has been successfully executed, to the client, but without providing any (at least i cannot conclude to any - please advice if any exists) way of identifying if a command successfully completed or not.
To sum up, my question would be: How is the client supposed to know when a PLAY command completed successfully, in order to wait for it before proceeding with any next steps?