1.30.0 debian/ubuntu bulk frames problem

[ilcalmo]

Edit to adopt template and stop bot closing
Describe Your Environment
Hi,
Installed 1.30.0 from debian testing repositories and also in Ubuntu (iconnor ppa). Tried also making debian package from master branch.

Describe the bug
I use mocord method.
Opening events and clicking on related events "Frames" you can see the frame list.
If you click on frame 100 (or any bulk frame such as 200 or 300) you see the image related to frame 100, if you click Prev or Next to see the 99th or 101st, you do not see image! In the syslog file I get the message:

web_php[656]: ERR [No image path]

while in the apache2 error log file I get the messages:
[:error] [pid 656] [client 192.168.19.106:61082] PHP Notice: Undefined property: Event::$StorageId in /usr/share/zoneminder/www/includes/Event.php on line 31, referer: http://192.168.19.110/zm/?view=frame&eid=6&fid=100
[:error] [pid 656] [client 192.168.19.106:61082] PHP Notice: Undefined property: Frame::$Id in /usr/share/zoneminder/www/includes/Frame.php on line 73, referer: http://192.168.19.110/zm/?view=frame&eid=6&fid=100
[:error] [pid 656] [client 192.168.19.106:61082] ERR [No image path], referer: http://192.168.19.110/zm/?view=frame&eid=6&fid=99&scale=100

So, only images related to frame numbers multiple of 100 are displayed, but not 99 or 101 and so on. Same for 200, 300.

If you play the full event, the event is displayed correctly, so the images are all in the right place.

Expected behavior
In 1.29.0 everything worked fine.

Additional info: If BULK_FRAME_INTERVAL is set to 0, all images are shown, but there are no more bulk frames, and to see the single images you have to wait the end of the event.

[marcmerlin]

Oh my, this problem has been going on for 1.5 years? (I just recently updated to 1.30 and now very much regret it I guess)
Now, the missing frames are just a small-ish bug, since in real life they were never recorded to start with because bulk made them go away.
I filed a bigger bug here: #2084

[mccrobie2000]

I also use mocord and get the same thing for viewing with bulk frames. The older versions passed a path to view.php. The newer versions seems to pass an event-id and frame-id. Unfortunately, bulk frames are not individually stored in the Frames table. A marker for the first frame in the bulk "set" is stored. This is why the first frame in the bulk set can be viewed, but not the subsequent frames. (You can "SELECT * FROM Frames WHERE EventId=blah" to see how the frames are stored.)

I suspect this never worked but was masked when using the path to the individual bulk frame in the older versions.

I've tried to mask the error also by passing EventId and FrameId in the query string formed in Frame.php, but the new image.php asks Frame.php to "find_one". This "find_one" function just assumes the frame is in the Frames table by EventId and FrameId - which returns no rows.

Fortunately, it appears this check in image.php is a sanity check only and can be commented out. Doing all three changes gets me my bulk image - finally.

Somewhere along the line, one of these functions in the chain (frame.php Frame.php view.php) need to understand how bulk frames are stored in the database (not as individual frames, but rather as a marker for the set of bulk frames.)

I'll include my changes in another comment once I clean-up my debug statements.

[mccrobie2000]

These changes only mask the issue and don't fix it.

zoneminder-bulk.txt

[ilcalmo]

@mccrobie2000:
Congratulation... Just tested your workaround and it works great. Now I can browse ALL the frames before and after bulk frames.
Debian buster and ZM 1.30.4

Thank you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[marcmerlin]

This fixed the problem for me too, thank you for the patch.
Is there a chance it can be included?

[asantaga]

@mccrobie2000 is the a git issue for this for the dev's to pull?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[marcmerlin]

Dear devs, is anyone looking at this? Can you add @mccrobie2000 's workaround if a better fix can't be added or now?
More generally can this bug stay open until it's fixed instead of requiring us to write updates just to prevent it from auto closing?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[marcmerlin]

can this bug stay open until it's fixed instead of requiring us to write updates just to prevent it from auto closing?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[marcmerlin]

still not stale

[SteveGilvarry]

Lol stupid bot

[marcmerlin]

I first upgraded to ZM 1.32 which broke half my cameras in various ways, and no one on the forums could tell why
A later update to ZM 1.34.8 didn't fix anything either.
After many months of having a non working install, I migrated off and moved to shinobi