ZoneMinder Forums

On previous versions of ZM, if I remember correctly, I could chose the number of events per page. The Web Options page still has 'Web Events per page in paged mode' but I can only use a drop down which gives me 10, 25, 50, 100, 200 or All.

When I have a large number of events it was much easier to chose a large number and select all and delete. Now I can only delete 200 at a time.

But, the issue with the page refreshing whilst the events are being deleted means that the list of 200 may also include some which were in the previous list, which increases the time needed to clear the events as you either select the 200 or go back to console and select events again to get the correct list.

Just wondering:

Why do you want to delete whatever it is?

Sorry but don't understand the question. I review my events periodically and then want to delete them. What I am questioning is why the option is for small number up to 200 and the next option is All. What was wrong with the previous mechanism which allowed you to specify the number per page.

Depends what version you had before, I find for mass deletes its easier to go delete the files on disk and run zm_audit.pl so it can clear the DB records of the events out.

Unless I am mistaken, versions 1.34 and before had the number of rows to display in the options and this dropdown option has only appeared recently. Your mechanism is something I hadn't considered so that is something useful to know.

px03afk wrote: ↑Sun Oct 03, 2021 1:25 pm Unless I am mistaken, versions 1.34 and before had the number of rows to display in the options and this dropdown option has only appeared recently.

You aren't mistaken, although it was still a text box in versions later than 1.34.x - I'm using 1.36.5 and that has one.

In 1.37.x there is still WEB_EVENTS_PER_PAGE in Web config.

I think I figured out why you want to delete them - it's a way to tell yourself they have already been reviewed, yeah?

Yes, there is still the option of WEB_EVENTS_PER_PAGE but it doesn't appear to do anything. Events per page seems be controlled by the drop down at the bottom of the events page.

Not sure what the comment about deleting them as a way of showing they have been reviewed. Whether or not they have been reviewed at some point they will need to be deleted, whether they have been reviewed or not.

Of course.
That's what the PurgeWhenFull filter is for.
And why I wondered why you wanted to delete them manually.

But doesn't Purge when full remove them without reviewing them?

Well, yes, it could. But if it doesn't, you're missing new stuff.
If you have a reasonable storage system, you'll likely have at least a week's worth of stuff.
Check your storage % and see how far back your recordings go to get an idea of how old the oldest records would be if you let PurgeWhenFull do its thing.

I can see that PurgeWhenFull can have its uses but I'm not sure it is answering the issue I've raised, which is that the only option for the number of events I can view is 10, 25, 50, 100, 200 or ALL. If I have, say 5,000 events 200 at a time is too small and ALL is too large. WEB_EVENTS_PER_PAGE is still there in the options but it doesn't seem to be used. My question is why have we changed from the original option to a drop down option which doesn't provide the same level of granularity.

OK, you're right that WEB_EVENTS_PER_PAGE doesn't appear to any longer do anything. Might be a bug. There have been many changes since I checked that.

I'm sure if you made a cash contribution you'd get whatever you want within reason.
But what do you want? Your use case seems to be an outlier.

WEB_EVENTS_PER_PAGE no longer affects the web ui. It is still used in API, however, which is why it hasn't been removed.

The bootstrap-table library accepts an array of values for the pagination values, which gets set as a static list during table init. Here is where it is set for the events table:
https://github.com/ZoneMinder/zoneminde ... ts.php#L76

The values you see currently are arbitrary. They worked well for me during initial implementation, but my development environment does not have a lot of events.

It is unfortunate that the table library itself does not have a built-in widget to change this on the fly.

One way to resolve this would be to create a new web config variable that lets you set the array values yourself.