ADC 3.2 vs 3.3

#1
Hey y'all

Following the update from v3.2 to v3.3, some RTS sessions aren't showing anymore (only 2 out of 6 does return the expected data despite the fact that other than the endpoint, the configurations are literal copies of each other).

A "quick" google search return a nothingburger referring to backend/slave nodes being offline(which isn't the case).

rm'ing the /dev/shm directory didn't do anything.

But a rollback to v3.2 resolved the issue.

Enabling debug (and regular error logs) didn't returned anything useful and/or obvious.

Is there anything that I should look into in order to get more info?

thanks!
 
#2
Hi,
It sounds like you’ve already done a good amount of troubleshooting, especially testing the rollback to confirm that the issue is related to the upgrade from ZoneMinder v3.2 to v3.3.
Since the problem only affects some RTS sessions and your configurations are identical, a few additional areas might be worth checking:
1. Session or cache handling
Even though you cleared /dev/shm, it may help to restart the full service stack (web server, database, and ZoneMinder services). Sometimes cached session data or temporary buffers can behave differently after upgrades.
2. Database schema changes
Check whether the upgrade to v3.3 introduced any database migrations that may not have applied correctly. Running the database update script again or verifying the schema version in the database could reveal inconsistencies.
3. Endpoint compatibility
If those RTS sessions rely on specific API endpoints, confirm that there were no changes in endpoint handling or authentication behavior in v3.3. Even small differences in how endpoints are parsed can cause only certain sessions to fail.
4. Monitor or stream configuration differences
Although the configs are copies, it might still be worth comparing the working vs. non-working sessions directly in the database or config files to see if something subtle changed during the upgrade.
5. Increase logging level
If the standard debug logs didn’t show anything useful, try increasing the logging verbosity further or enabling component-specific debugging to see if any warnings appear when those sessions attempt to initialize.
Since rolling back to v3.2 resolves the issue, it could also be a regression in v3.3 affecting certain RTS setups. If you can reproduce it consistently, sharing your logs and configuration details with the community or maintainers might help identify whether it’s a known issue.
Hope this gives you a few more directions to investigate. Good luck tracking it down!
 
Top