Why is rows per page up to 200 and then all
Why is rows per page up to 200 and then all
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.
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.
-
- Posts: 1336
- Joined: Sat Aug 31, 2019 7:35 am
- Location: San Diego
Re: Why is rows per page up to 200 and then all
Just wondering:
Why do you want to delete whatever it is?
Why do you want to delete whatever it is?
Re: Why is rows per page up to 200 and then all
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.
Re: Why is rows per page up to 200 and then all
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.
Re: Why is rows per page up to 200 and then all
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.
Re: Why is rows per page up to 200 and then all
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.
-
- Posts: 1336
- Joined: Sat Aug 31, 2019 7:35 am
- Location: San Diego
Re: Why is rows per page up to 200 and then all
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?
I think I figured out why you want to delete them - it's a way to tell yourself they have already been reviewed, yeah?
Re: Why is rows per page up to 200 and then all
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.
Re: Why is rows per page up to 200 and then all
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.
-
- Posts: 1336
- Joined: Sat Aug 31, 2019 7:35 am
- Location: San Diego
Re: Why is rows per page up to 200 and then all
Of course.
That's what the PurgeWhenFull filter is for.
And why I wondered why you wanted to delete them manually.
That's what the PurgeWhenFull filter is for.
And why I wondered why you wanted to delete them manually.
Re: Why is rows per page up to 200 and then all
But doesn't Purge when full remove them without reviewing them?
-
- Posts: 1336
- Joined: Sat Aug 31, 2019 7:35 am
- Location: San Diego
Re: Why is rows per page up to 200 and then all
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.
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.
Re: Why is rows per page up to 200 and then all
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.
-
- Posts: 1336
- Joined: Sat Aug 31, 2019 7:35 am
- Location: San Diego
Re: Why is rows per page up to 200 and then all
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.
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.
- knight-of-ni
- Posts: 2406
- Joined: Thu Oct 18, 2007 1:55 pm
- Location: Shiloh, IL
Re: Why is rows per page up to 200 and then all
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.
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.
Visit my blog for ZoneMinder related projects using the Raspberry Pi, Orange Pi, Odroid, and the ESP8266
All of these can be found at https://zoneminder.blogspot.com/
All of these can be found at https://zoneminder.blogspot.com/