zm_event: Can't insert frames: You have an error in your SQL

[ratatine]

I'm surprised others haven't run into this issue but I've been debugging zm_event.cpp and have tracked down a problem. Now the question is - what's the right way to fix it.

Basically, zma_m1 is creating 200 pre-capture frames (by my choice) and then attempting to write them to the database on line 523 on zm_event.cpp as one big SQL statement. However the sql variable size is set to 8192 (ZM_SQL_LGE_BUFSIZ) bytes and the SQL statement being created is well going beyond this buffer size (by probably about 2k). This results in a SQL statement that isn't terminated and the whole event fails to be inserted.

Now of course I could probably reduce the size of this SQL statement by reducing my pre-event image count buffer size. However, I want it to give me the 8 seconds preceeding an event (because it always seems to kick in half way through the event otherwise) and at 25fps, this is how big the buffer needs to be.

My temporary solution was to define ZM_SQL_XLG_BUFSIZ as 16384 and to use that buffer size instead. However is this the best way to accomplish this? It seems to take care of the issue anyway.

Thoughts greatly appreciated! Thanks,

-James

On a sub-note, I should mention the log error is always followed by an exit of zmdc with: 'zma -m 1' exited abnormally, exit status 40 - in case this helps googlers later find this issue.

[ratatine]

Lending out a bump... is this just the best way to fix this? I would think a better way would be to split the SQL statement or allocate the memory dynamically but I can always leave it as is on my copy and just run with it... ?

Thanks!
-James

[McFuzz]

Bumping this from the dead because I hit the same exact problem today on my Debian install with MariaDB.

Interestingly - this install is a brand new since my previous one, which was identical (but I did a boo-boo), never had any such issue when I set pre/post buffers to 200 frames just as OP...

[ratatine]

I can confirm that I never found another solution for this and today I'm still using the same change. Hasn't broken anything however.