Notes from upgrading 1.30=>1.32=>1.34=>1.36

[rwg]

Just thought I would post my experiences with a significant upgrade to my ZM installation which had become rather out-of-date.

The upgrades using the various PPA repositories (running on Ubuntu 18.04 - yes, something else I need to upgrade) went remarkably smoothly. I think the most I had to do after an upgrade to get things running was to restart apache2 to make sure it picked up new settings. One other thing that was needed was to clear cookies in the browser - otherwise they stored some skin information from the old version which caused trouble in the new one.

Somewhere along the way, old events (created with 1.30) stopped showing thumbnails and stopped being playable as videos. I was initially worried that something like zmaudit had decided they could be cleaned up, but the frames were still visible. A bit of digging revealed that the problem was with one of the database upgrades - the SaveJPEGs field (presumably new field) on the Events table was set to NULL for those old events, where the current code expects it to be set to 3 (or anything odd to be honest) for events that save jpegs. A quick SQL statement (

Code: Select all

update Events set SaveJPEGs=3 where SaveJPGEGs is NULL;

) fixed the old events.

Something also went weird with storage settings - I had previously set storage to /export/zm/events. Somehow it still knew about this path and was using it for new events, but the 'Default' storage was showing as /var/cache/zoneminder/events with no other storages. Oddly, when I clicked on 'new storage' it defaulted to my real storage directory in the pop up. Anyway, this was something else I had to fix in the database as there seems no way to edit an existing storage in the UI.

High speed playback - I don't know if this is just due to some odd setup that I have, but high speed playback of JPEG based events seems completely broken in 1.36. A bit of digging revealed that the problem seemed to be this chunk of code in EventStream::runStream()

Code: Select all

      if ( last_frame_offset ) {
        // We assume that we are going forward and the next frame is in the future.
        delta_us = frame_data->offset * 1000000 - (now_usec-start_usec);
       // - (now_usec - start_usec);
        Debug(2, "New delta_us now %" PRIu64 " - start %" PRIu64 " = %" PRIu64 " offset %f - elapsed = %dusec",
              now_usec, start_usec, static_cast<uint64>(now_usec - start_usec), frame_data->offset * 1000000, delta_us);
      } else {
        Debug(2, "No last frame_offset, no sleep");
        delta_us = 0;
      }

This completely overwrites the delta_us variable which is the wait before sending the frame. Further up the function, delta_us has been carefully set to account for the playback speed change, but this code clobbers it and tries to make the video play in real time whatever playback speed is selected. I just commented this block out and recompiled zms - it works for my use case and I can see that the code is very different in the master branch, so maybe this code is being replaced anyway.

I've also made a few tweaks of the web UI - these are just for personal preferences, but maybe they will be useful to others...

* I didn't like the thumbnail in the monitor list - since I have quite big thumbnails set, it pushed the row height up a lot and stopped me seeing everything in one page. The switch for thumbnails on/off affects both event lists (where I want them) and the console where I don't, so I just commented out the thumbnail bit in console.php - this, to be exact

Code: Select all

    $imgHTML = '<div class="colThumbnail"><a';
    $imgHTML .= $stream_available ? ' href="?view=watch&amp;mid='.$monitor['Id'].'">' : '>';
    $imgHTML .= '<img id="thumbnail' .$Monitor->Id(). '" src="' .$stillSrc. '" style="'
      .$thmbWidth.$thmbHeight. '" stream_src="' .$streamSrc. '" still_src="' .$stillSrc. '"'.
      ($options['width'] ? ' width="'.$options['width'].'"' : '' ).
      ($options['height'] ? ' height="'.$options['height'].'"' : '' ).
      ' loading="lazy" /></a></div>';

* Did 1.30 have event pagination at top and bottom? I think it did, and it's too late to try to check now. Anyway, I found I wanted pagination at the top as well as the bottom, and fortunately that's easy - add this to this to the table definition in events.php

Code: Select all

data-pagination-V-Align="both"

* How it looks on a mobile phone... Some things layout badly on a narrow screen, particularly in the event view where the event info is pushed off screen to the left by the video and the buttons at the top end up in a vertical stack. Adding the 'flex-wrap' class to the divs that are 'flex-row' in Event.php helps here as it allows the content to wrap to multiple lines if necessary. More tinkering to do in this direction. Unfortunately the zmNinja app doesn't approve of the way I have added authorization via my NGINX reverse proxy/https termination, so I use the web pages on my phone.

I still have a few things that I need to work out - if anyone has any ideas I'd be grateful for suggestions

* Large video events start playing instantly on Firefox, but have a long delay (whole video downloading?) on Chrome

* Something seems to remember things like which page I was on in the events list for a camera. I want it to stop! When I click the events list, I want it to start from page 1, not page 4 of the events, which is probably not the same events as I was looking at on page 4 last time anyway. The same thing happens for playback speed - I want that to stop remembering what I used the last time...

Anyway, overall I've been quite pleased with the upgrade and the way things like the passthrough video saving has helped reduce CPU load on my server. I don't mind a little tinkering, and when I did hit a bit of an issue it was usually possible to find some good suggestions for how to fix it via a quick search (most of the good stuff here on the forums). Thanks everyone for putting in all the hard work to keep Zoneminder evolving

cheers,

Robin

[iconnor]

That is a huge upgrade! Well done!

Yeah the behaviour of the events list is problematic. Am looking at it.
Also, the layout on phone has suffered. I plan to address that sooner rather than later (because I actually use it).

It is late and my eyes aren't focusing so much so I will review again tomorrow.

[rwg]

Hi,

thanks for reading

I worked out a bit more about the events list after posting - looks like the 'remembering' is coming from cookies saved by the bootstrap table pagination. I tried turning this off, but it broke the common use case of being on page 2, viewing an event and then pressing back to go back to the events list... You end up back on page 1, since the page number is not in the URL.

What I'm going to try when I get a moment is this, which might work...

* Make the bootstrap table cookie prefix a random string generated by the PHP
* Set the cookie lifetime short (1 day?)

That way, every time you go to the events list it will be a new set of cookies, so it will not remember the page you were on before when you previously used the events. However, if you go back in the browser, it should not hit the server, so the random cookie will be the same as before you went to the event and it will (hopefully) remember the page you were on.

cheers,

Robin

[iconnor]

COOKIE lifetime should definitely be 1 day or less.

Could maybe also be dependent on the filter...

I also don't really like stuffing the cookies full of values, it starts to add a lot of bloat to each request.

Need to dig in and read up on the current state of bootstrap table.

[rwg]

Just tried it and the idea doesn't work anyway - the request gets re-run when you press 'back' because the Cache-Control header on the events page prevents caching...

How about including the monitor ID in the cookie name? Also set the cookie lifetime and the cookie storage to session storage. Something like

Code: Select all

data-cookie-storage="session-storage"
data-cookie-expire="6h"
data-cookie-id-table="<?php ... something to get the monitor id which I can't work out yet...?>"

cheers,

Robin

[rwg]

Ok, plan B failed too, ended up hacking it with a random table_data_id= parameter added to the links in the console, then use that as the data-cookie-id-table value in the events list - that way as you go back to the events list it recovers the position from a unique cookie since the value is in the URL parameters. Give the cookie a 1d lifetime (but don't use session-storage - that seems to fail).

Ugly, but works :-/

cheers,

Robin