Monitor trying to use deleted Default storage although configured to use NewStorage

[adrianmay]

Describe Your Environment
Nixos 22.11
services.zoneminder = {
enable = true;
port = 2023;
database = {
createLocally = true;
username = "zoneminder";
};
};

Browser irrelevant

Describe the bug
I want the videos to collect on my 16TB share drive which is already mounted at /mnt/share by samba on the host running zm. I set the share drive up as NewStorage and configured Monitor-1 to use it. All was fine until around midnight when nobody was playing with the system. Looking at the history of events, I see that before this time the events are on NewStorage and can be replayed, but after this, they are all on Default which I've since deleted from the list of storages. But then again, I guess it hasn't really been deleted cos when I try to replay those videos it says "Event was not found at /var/lib/zoneminder/events/1/2023-09-24/421" so how come it knows the old /var/lib/zoneminder/events path?

I guess some network blip deprived it of /mnt/share for that moment around midnight but it's mounted right now and I still can't persuade zm to use it. Monitor-1 still says it should but all the events say they're at Default. I've tried creating another storage pointing to the same path, but no matter what I try, the events are all listed as being on Default and none are found. No drives are anywhere near full.

To Reproduce
Steps to reproduce the behavior:

1. Create a new storage
2. Configure the monitor to use it
3. Delete the Default storage
4. Wait for some mystery trigger
5. See that events before the trigger are on the new storage and those after it are listed as being on Default and cannot be found when trying to play them back. Looking directly in both storage locations on the host, see that the events really aren't there.

Expected behavior
Don't care what the trigger is, it should never try to use a deleted storage or any storage other than the configured one

Debug Logs
The logs don't load. I waited about ten minutes but it just says Loading, please wait ...

[welcome]

Thanks for opening your first issue here! Just a reminder, this forum is for Bug Reports only. Be sure to follow the issue template!

[connortechnology]

If for some reason ZM can't write to it's configured storage, it will try to write somewhere else. If there are no other configured storage areas, then it falls back to the code from 1.29 before storage areas were implemented. In other words, whatever path that was compiled in a a default. Of course this causes a problem if you've deleted it, but we take the stance that it is better to have the video than not have it. The logs not loading is likely due to a too-small memory limit configured in php (default is 128Mb which is really not nearly enough.).

[adrianmay]

But why does it permanently blight a storage because of a brief problem?

…

On Mon, 25 Sept 2023, 14:36 Isaac Connor, ***@***.***> wrote: If for some reason ZM can't write to it's configured storage, it will try to write somewhere else. If there are no other configured storage areas, then it falls back to the code from 1.29 before storage areas were implemented. In other words, whatever path that was compiled in a a default. Of course this causes a problem if you've deleted it, but we take the stance that it is better to have the video than not have it. The logs not loading is likely due to a too-small memory limit configured in php (default is 128Mb which is really not nearly enough.). — Reply to this email directly, view it on GitHub <#3771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARMR4ODKBFFIWJGHRVHILX4GCGZANCNFSM6AAAAAA5F2RB5M> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[adrianmay]

Anyway, it isn't storing anything under /var/lib/... although it could. On Mon, 25 Sept 2023, 14:40 Adrian May, ***@***.***> wrote:

…

But why does it permanently blight a storage because of a brief problem? On Mon, 25 Sept 2023, 14:36 Isaac Connor, ***@***.***> wrote: > If for some reason ZM can't write to it's configured storage, it will try > to write somewhere else. If there are no other configured storage areas, > then it falls back to the code from 1.29 before storage areas were > implemented. In other words, whatever path that was compiled in a a > default. Of course this causes a problem if you've deleted it, but we take > the stance that it is better to have the video than not have it. The logs > not loading is likely due to a too-small memory limit configured in php > (default is 128Mb which is really not nearly enough.). > > — > Reply to this email directly, view it on GitHub > <#3771 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAARMR4ODKBFFIWJGHRVHILX4GCGZANCNFSM6AAAAAA5F2RB5M> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[nathan-stewart]

I think this may be related - I'm also a new user. I created a new storage area and it seemed to be using the old one. I deleted the old Default and it was still writing to it. I now have one, id=2 that can't be deleted or even selected in the checkbox for edit/delete but it wasn't the original Default. I even tried to set the new remaining storage area back to where the old one was writing and that didn't work either. I'm sure I did something wrong, but I did it from the web and I'm about to blow my database away to get rid of that one.

I think there seems to be some kind of bug where the id gets mismatched. I have the debian repo version 1.36.33+dfsg1-1

[gpuma]

I'm also having the same issue. After deleting the default storage I can't view any event; the files are not being written. The size of events is stuck at 0 bytes in the console.

if zoneminder breaks when deleting this storage then it shouldn't let you to.

I'm running Linux Mint 21.3, zoneminder 1.36