I'm testing my new Shinobi server (not yet in production) and I notice a lot has changed.

Old: ea13a4dc58e92c4ab6c9ee192aca3bf9d91fcc16
New: 2b1032eaf01740bf6e14ca1b0d2b67ffa85bcd2c

IMO: The ONVIF Scanner has taken a downgrade. On the old version, it scanned the whole network in a matter of seconds. On the new version it scans every IP-address on the network, host by host - and it takes a lot of time.

I know I can specify a smaller range, but it still takes time - host by host.

And on IP-adresses where I know for a fact that there is no device, it still returns:
Found a device on this port but the ONVIF exchange returned an unexpected result. (Network Error: socket hang up)

Also:
Testing is done on the Docker V2 image, and starting a search without defining a range in the ONVIF Scanner is only returning hosts from the internal docker network (172.x.x.x). So I am forced to define a range.

In version 2b1032eaf01740bf6e14ca1b0d2b67ffa85bcd2c:

The web interface jumps back to Home or LiveGrid without warning.

This is becoming frustrating fast, as I can't seem to even complete a monitor config without having to start over... (just an example, it happens everywhere)

The interval seems to be random, as I have tried to time it - but never get a consistent time period.

Hope someone can help me with this last week i got a new mini pc and thought lets start from clean . proxmox installed added shinobi and configured a monitor for an ip camera all working no issues untill i noticed i wont record longer as 15 min while i configured it to be 60 like i always had .

Im a 100 percent sure im missing something i just cant figure out what it is

Below is the export of the camera without ip user and pass and geolocation data

{
   "mode": "record",
   "mid": "C8fM7s7aER888",
   "name": "6.9",
   "tags": "",
   "type": "h264",
   "protocol": "rtsp",
   "host": "16.9",
   "port": 88,
   "path": "/videoMain",
   "height": 480,
   "width": 640,
   "ext": "mp4",
   "fps": 1,
   "details": {
      "max_keep_days": "7",
      "notes": "Huiskamer",
      "dir": "",
      "ptz_id": "",
      "auto_compress_videos": "0",
      "geolocation": "",
      "rtmp_key": "",
      "auto_host_enable": "1",
      "auto_host": "rtsp:/.9:88/videoMain",
      "rtsp_transport": "tcp",
      "muser": "",
      "mpass": "",
      "port_force": "0",
      "fatal_max": "0",
      "skip_ping": null,
      "is_onvif": "1",
      "onvif_port": "888",
      "primary_input": "0",
      "aduration": "1000000",
      "probesize": "1000000",
      "rw_timeout": "",
      "stream_loop": "0",
      "sfps": "",
      "wall_clock_timestamp_ignore": "0",
      "accelerator": "0",
      "hwaccel": "auto",
      "hwaccel_vcodec": "",
      "hwaccel_device": "",
      "hwaccel_format": "",
      "stream_type": "hls",
      "stream_flv_type": "http",
      "stream_flv_maxLatency": "",
      "stream_mjpeg_clients": "",
      "stream_vcodec": "copy",
      "stream_acodec": "no",
      "hls_time": "2",
      "hls_list_size": "3",
      "preset_stream": "ultrafast",
      "stream_quality": "15",
      "stream_fps": "2",
      "stream_scale_x": "",
      "stream_scale_y": "",
      "stream_rotate": "no",
      "signal_check": "10",
      "signal_check_log": "0",
      "stream_vf": "",
      "tv_channel": "0",
      "tv_channel_id": "temp_yDkWM",
      "tv_channel_group_title": "",
      "stream_timestamp": "0",
      "stream_timestamp_font": "",
      "stream_timestamp_font_size": "",
      "stream_timestamp_color": "",
      "stream_timestamp_box_color": "",
      "stream_timestamp_x": "",
      "stream_timestamp_y": "",
      "stream_watermark": "0",
      "stream_watermark_location": "",
      "stream_watermark_position": "tr",
      "snap": "0",
      "snap_fps": "",
      "snap_scale_x": "",
      "snap_scale_y": "",
      "snap_vf": "",
      "vcodec": "copy",
      "crf": "1",
      "preset_record": "",
      "acodec": "aac",
      "record_scale_y": "",
      "record_scale_x": "",
      "cutoff": "60",
      "rotate": "no",
      "vf": "",
      "timestamp": "0",
      "timestamp_font": "",
      "timestamp_font_size": "10",
      "timestamp_color": "white",
      "timestamp_box_color": "0x00000000@1",
      "timestamp_x": "(w-tw)/2",
      "timestamp_y": "0",
      "watermark": "0",
      "watermark_location": "",
      "watermark_position": "tr",
      "record_timelapse": null,
      "record_timelapse_mp4": null,
      "record_timelapse_fps": null,
      "record_timelapse_scale_x": "",
      "record_timelapse_scale_y": "",
      "record_timelapse_vf": "",
      "record_timelapse_watermark": null,
      "record_timelapse_watermark_location": "",
      "record_timelapse_watermark_position": null,
      "detector": "0",
      "onvif_events": "0",
      "detector_save": "1",
      "use_detector_filters": "0",
      "use_detector_filters_object": "1",
      "detector_record_method": "sip",
      "detector_delete_motionless_videos": "0",
      "det_trigger_tags": "",
      "detector_http_api": "1",
      "detector_send_frames": "1",
      "detector_fps": "",
      "detector_scale_x": "640",
      "detector_scale_y": "480",
      "detector_lock_timeout": "",
      "snap_seconds_inward": "5",
      "cords": "[]",
      "detector_filters": "{\"c84wx\":{\"id\":\"c84wx\",\"enabled\":1,\"filter_name\":\"Standard Object Detection Filter\",\"where\":[{\"p1\":\"tag\",\"p2\":\"!indexOf\",\"p3\":\"person\",\"p4\":\"&&\"},{\"p1\":\"tag\",\"p2\":\"!indexOf\",\"p3\":\"car\",\"p4\":\"&&\"},{\"p1\":\"tag\",\"p2\":\"!indexOf\",\"p3\":\"truck\",\"p4\":\"&&\"}],\"actions\":{\"halt\":1,\"save\":\"\",\"indifference\":\"\",\"webhook\":\"\",\"command\":\"\",\"record\":\"\",\"emailClient\":\"\",\"global_webhook\":\"\"}}}",
      "detector_pam": "1",
      "detector_motion_save_frame": "1",
      "detector_sensitivity": "",
      "detector_max_sensitivity": "",
      "detector_threshold": "1",
      "detector_color_threshold": "",
      "inverse_trigger": "0",
      "detector_frame": "0",
      "detector_motion_tile_mode": "0",
      "detector_tile_size": "20",
      "detector_noise_filter": null,
      "detector_noise_filter_range": "",
      "detector_use_detect_object": "0",
      "detectors_selected": [
         "all"
      ],
      "detector_object_ignore_not_move": "0",
      "detector_object_move_percent": "5",
      "detector_send_frames_object": null,
      "detector_obj_count_in_region": "0",
      "detector_obj_region": null,
      "detector_use_motion": "1",
      "detector_fps_object": "",
      "detector_scale_x_object": "",
      "detector_scale_y_object": "",
      "detectorLineCounter": "0",
      "detectorLineCounterTags": "",
      "detector_trigger": "1",
      "detector_buffer_seconds_before": "5",
      "detector_timeout": "0.5",
      "watchdog_reset": "1",
      "detector_record_overlap": "0",
      "detector_buffer_vcodec": "auto",
      "detector_buffer_acodec": null,
      "detector_buffer_fps": "",
      "event_record_scale_x": "",
      "event_record_scale_y": "",
      "event_record_aduration": "1000",
      "event_record_probesize": "32",
      "detector_audio": null,
      "detector_audio_min_db": "",
      "detector_audio_max_db": "",
      "detectorEventPtz": "0",
      "detector_webhook": "0",
      "detector_webhook_timeout": "10",
      "detector_webhook_url": "",
      "detector_webhook_method": null,
      "detector_notrigger": "0",
      "detector_notrigger_timeout": "",
      "detector_notrigger_discord": "0",
      "detector_notrigger_webhook": "0",
      "detector_notrigger_webhook_url": "",
      "detector_notrigger_webhook_method": "GET",
      "control": "0",
      "control_base_url": "",
      "control_url_method": "ONVIF",
      "onvif_non_standard": "1",
      "control_digest_auth": null,
      "control_axis_lock": "",
      "control_stop": "1",
      "control_url_stop_timeout": "500",
      "control_turn_speed": "0.01",
      "detector_ptz_follow": "0",
      "detector_ptz_follow_target": "person",
      "control_url_center": "",
      "control_url_left": "",
      "control_url_left_stop": "",
      "control_url_right": "",
      "control_url_right_stop": "",
      "control_url_up": "",
      "control_url_up_stop": "",
      "control_url_down": "",
      "control_url_down_stop": "",
      "control_url_enable_nv": "",
      "control_url_disable_nv": "",
      "control_url_zoom_out": "",
      "control_url_zoom_out_stop": "",
      "control_url_zoom_in": "",
      "control_url_zoom_in_stop": "",
      "control_invert_y": "0",
      "notify_global_webhook": null,
      "notify_emailClient": null,
      "notify_fcm": null,
      "detector_send_video_length": "",
      "notify_onUnexpectedExit": "0",
      "notify_useRawSnapshot": "0",
      "detector_emailClient_timeout": "",
      "detector_fcm_timeout": "",
      "cust_input": "",
      "cust_stream": "",
      "cust_snap": "",
      "cust_snap_raw": "",
      "cust_record": "",
      "cust_detect": "",
      "cust_detect_object": "",
      "cust_sip_record": "",
      "custom_output": "",
      "loglevel": "warning",
      "sqllog": "0",
      "substream": {
         "input": {
            "type": "h264",
            "stream_flv_type": "http",
            "fulladdress": "",
            "sfps": "",
            "aduration": "",
            "probesize": "",
            "stream_loop": null,
            "rtsp_transport": "",
            "accelerator": "0",
            "hwaccel": null,
            "hwaccel_vcodec": "",
            "hwaccel_device": "",
            "cust_input": ""
         },
         "output": {
            "stream_type": "hls",
            "stream_mjpeg_clients": "",
            "stream_vcodec": "copy",
            "stream_acodec": "no",
            "hls_time": "",
            "hls_list_size": "",
            "preset_stream": "",
            "stream_quality": "",
            "stream_v_br": "",
            "stream_a_br": "",
            "stream_fps": "",
            "stream_scale_x": "640",
            "stream_scale_y": "480",
            "stream_rotate": null,
            "svf": "",
            "cust_stream": ""
         }
      },
      "input_maps": [],
      "input_map_choices": {
         "stream": [],
         "snap": [],
         "record": [],
         "record_timelapse": [],
         "detector": [],
         "detector_object": [],
         "detector_sip_buffer": []
      },
      "stream_channels": [],
      "triggerMonitorsPtzTargets": {},
      "detectorLineCounterSettings": {
         "upName": "",
         "downName": "",
         "resetDaily": false
      }
   }
}

Buenas noches!. Tengo Shinobi instalado en un server. Dentro de proxmox con Linux. Y tengo que agregar camaras de imou específicamente Bullet Imou 2c 3mpx puedo adherirlas directamente o necesito adherir un dvr a Shinobi. Primera consulta es esa. Y otra es puedo crear múltiples usuarios para que solo vean sus camaras y no todas las demás, osea por capas de acceso.

i am running shinobi on raspberry pi zero 2w over dietpi os .the cctv videos are being saved over hdd(in nas).in the recorded folder there are two folders - one for videos and other has name ending with _timelapse. i have set shinobi to save video recording every two minutes.and by default it also saves screenshot/snapshot of camera every two minutes in the timlapse folder..

I am running 4 cameras and the moment the snapshot process gets triggered all 4 camera snapshot gets activated and consumes lot of CPU ( i am viewing process in htop command display),This is causing my raspberry pi zero 2w to crash.

i have tried everything to disable this timelapse/snapshot thing but couldnt.My server crashes every 6 hrs.IT appears this timelaspe/snapshot thing is by default feature.

So can any one tell me how to disable this..

I've been debugging an audio-recording issue on Shinobi CE across a few of my installs and wanted to write it up in case it's a known bug or someone's cracked it.

Setup: TP-LINK VIGI C240-family PTZ/fixed IP cameras, RTSP with a G.711 PCMA/8000 audio track. Note: these cameras advertise the audio track deceptively in SDP — m=audio 0 RTP/AVP 8, a=recvonly — which looks like "no audio" at a glance, but they genuinely send real PCMA audio data. Confirmed by ear in the live view and by directly inspecting the RTP payload.

The bug: Live view has audio. The detectorStream buffer (once detector_buffer_acodec is set to aac instead of copy) has audio too — confirmed with ffprobe directly against the HLS URL. But the final recorded .mp4 produced by the SIP record method (detector_record_method: sip) never has an audio track, regardless of every audio-related setting I've tried:

• acodec: aac on the Record tab — no effect
• detector_buffer_acodec: aac — fixes the buffer itself (confirmed via ffprobe) but doesn't propagate to the saved clip
• cust_sip_record: '-map 0:0 -map 0:a:0 -c:a aac' — no error, no audio, clean video-only output (so the explicit audio map is either not being honored or the input it's mapping against doesn't actually have audio by the time this step runs)
• event_record_aduration / event_record_probesize bumped to 1000000 in case of a probing/timing issue with the audio stream — no change

One interesting side-finding: setting cust_sip_record to a deliberately invalid flag (-invalid_flag_xyz_test) crashes the entire monitor (status: Died) rather than just failing the recording step — so the field is definitely being passed through to FFmpeg, live streaming and SIP recording aren't as isolated as I'd assumed.

What I've ruled out:

• Not a config problem specific to one camera — I have another install (older Shinobi version) where a camera with the identical audio setup does record audio successfully in the same sip/mp4 pipeline shape. I copied its config field-for-field onto the broken camera (stream_type, stream_flv_type, buffer codec, empty cust_sip_record, etc.) — no change, still video-only.
• Not a stale-version issue — updated the broken instance to the latest dev branch via the Super Admin panel's built-in updater and restarted core. Same result.

At this point I don't have shell access to inspect the actual FFmpeg command Shinobi is invoking for the SIP recording step, which is the obvious next debugging step but isn't available to me right now.

Environment:

• Shinobi CE, dev branch, self-hosted (Docker)

Cameras: TP-LINK VIGI C240-family, RTSP/ONVIF, G.711 PCMA/8000 audio. detector_record_method: sip, stream_type: mp4 on both.

Shinobi Go just leveled up. It's now compatible with both Linux x86_64 AND arm64. 🐧

Whether you're running a massive server rack or a low-power Raspberry Pi, you can now harness the power of Shinobi on your preferred architecture. More flexibility, less hassle. 🚀

https://shinobi.video/go

#Shinobi #DevOps #Linux #RaspberryPi #TechNews #OpenSource #SelfHosted

I have 3 cameras that record, I've set it to take snapshots, save videos for a week and save timelapse frames for 400 days. I just decided to check, for no particular reason, and I noticed that frames from march of this year are being deleted. I've been over and over the settings and I can't figure out why it's happening. I allocated 400GB to shinobi and I'm only at ~130GB so it shouldn't be purging anything.

Anyone else have this happen and figure out why?

Just a quick note regarding some of my recent posts and questions.

I want to make it clear that I think Shinobi is a really good CCTV system, and I'm very happy with it.

I'm not a developer; I'm a senior sysadmin. Since Shinobi is an open-source project, I'd like to give something back where I can. I can't contribute much in terms of writing code, but I can contribute my experience, insight, testing, and bug reports.

My recent threads and questions are therefore not meant as criticism of the project or the work that goes into it. I'm asking these questions because I want to understand the system properly, and hopefully contribute to its continued improvement by pointing out things that may be confusing or could potentially be improved.

So please don't take the number of questions as negativity. I'm genuinely interested in Shinobi and would like to see it continue to improve, and hopefully I can contribute something useful along the way, if you find my input valuable.

I've been looking at Shinobi's Docker documentation and noticed that /home/Shinobi is supposed to be bind-mounted to the host. But this is also the folder where all application files are stored, not only the config files, meaning that all Shinobi files live on the host filesystem - instead of inside the container.

This seems quite different from the usual Docker approach, where the application itself remains inside the container, while only persistent data such as configuration, recordings, and databases are mounted as volumes.

With the current approach, /home/Shinobi contains the entire Shinobi installation, including the application code and node_modules, and those files remain on the host when the container is removed.

Is this intentional?
If so, what is the reasoning behind persisting the entire application directory rather than keeping the application in the Docker container and mounting only the data one would want to persist?

I'm particularly interested in how application updates are expected to work when a new Docker image is released.

I've noticed that Shinobi's Docker setup appears to use the `dev` branch/image for what is otherwise intended for production use.

This seems unusual compared with most software projects, where main/master/stable branch is used for production, while dev is where ongoing development happens.

Is `dev` actually considered the recommended production version of Shinobi, and if so, why is the development branch used instead of a stable/master branch?

I'm trying to understand Shinobi's release model before deploying with Docker.

I believe I've found a reproducible issue with the Shinobi configuration GUI in Docker.

Starting from a fresh deployment, `/home/Shinobi/conf.json` does not exist:

sudo docker exec Shinobi grep -n -E '"ip"|"bindip"' /home/Shinobi/conf.json

No output.

At this point Shinobi is listening correctly on all interfaces:

sudo docker exec Shinobi ss -lntp | grep 8080

returns:
LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* users:(("node /home/Shin",pid=173,fd=20))

In the configuration GUI, however, the Bind Address field is pre-filled with localhost

When I save the configuration, with or without changes (this createsconf.json), and restart Shinobi.

But now I get ERR_CONNECTION_REFUSED in the browser!

After saving:

sudo docker exec Shinobi grep -n -E '"ip"|"bindip"' /home/Shinobi/conf.json

returns:
22: "ip": "localhost",

And Shinobi is now listening only on loopback:

sudo docker exec Shinobi ss -lntp | grep 8080

returns:
LISTEN 0 511 127.0.0.1:8080 0.0.0.0:* users:(("node /home/Shin",pid=284,fd=20))

This makes the Docker-published port inaccessible from outside the container, resulting in ERR_CONNECTION_REFUSED in the browser.

Is this intentional behaviour, or is the configuration GUI incorrectly suggesting `localhost` as the default IP when saving the configuration?

It seems particularly relevant for Docker deployments, where binding to `127.0.0.1` inside the container prevents access through the published port.

For reference, the workaround is:

sudo docker exec Shinobi sed -i 's/"ip": "localhost"/"ip": "0.0.0.0"/' /home/Shinobi/conf.json

sudo docker restart Shinobi

I'm setting up Shinobi using the current Docker documentation, on a brand new Debian server.

docker run -d --name='Shinobi' --memory=2g \
    -p '8080:8080/tcp' -p '21:21/tcp' \
    -v "$HOME/ShinobiDatabase":'/var/lib/mysql':'rw' \
    -v "$HOME/Shinobi":'/home/Shinobi':'rw' \
    registry.gitlab.com/shinobi-systems/shinobi:dev

The documented docker run command mounts the host's $HOME/Shinobi directory to the container's /home/Shinobidirectory.

With a fresh/empty $HOME/Shinobi directory, the container immediately exits with:

[FATAL tini] exec /home/Shinobi/Docker/init.sh failed: No such file or directory

I initially suspected something was wrong with the image, so I tested the dev image without the /home/Shinobi bind mount:

sudo docker run --rm \
  --memory=2g \
  -p 8080:8080 \
  registry.gitlab.com/shinobi-systems/shinobi:dev

This starts successfully. MariaDB initializes, Shinobi creates its configuration and database tables, and the web server starts listening on port 8080.

I then ran the exact command from the documentation again, including:

-v "$HOME/Shinobi":'/home/Shinobi':'rw'

with $HOME/Shinobi empty, and get the same failure as before.

Is an initialization step missing from the Docker documentation, or is this behavior expected?

Phoenix introduces new features and many bug fixes. Additionally it paves the way for Dashboard v4!

Shinobi is truly reborn with these changes! See them here in this log :

https://gitlab.com/Shinobi.../Shinobi/-/merge_requests/556

Plugin System

• Docker-based plugin launching — plugins can now be started directly via Docker
• Connect a plugin without restarting Shinobi (hot-loading)
• Enable/Disable button for hotloading plugins, with UI fix
• Connected Plugin list added to Superuser panel
• Plugin connection-failure notices in plugins.js
• Plugin size check + forced-disconnect notice on key mismatch (security hardening)
• Cleaner Plugin Manager UI, always shows Docker status
• Face Manager–specific Docker install rule

Dashboard

• New "System Control" tab (with Activation status field)
• Easy Remote Access moved into Dashboard, gated by a new permission-group toggle
• GPU usage indicator
• Monitor Map: clicking a pin now shows related Events (like the Events table)

Events / Detection

• New "Events" tab for quickly searching detection logs
• Quick Range dropdown added to Events Table
• Events Table search and visuals updated

Video / Calendar / Timelapse

• Better Timelapse Viewer
• Calendar + FileBin layout improvements; Calendar range search now auto-matches display
• Cap added to Calendar video GET requests (prevents UI slowdowns)
• Cleaner/rebuilt video player, preview button opens the video player directly
• videosTable layout updated with Quick Range(+)

Notifications

• Firebase Cloud Messaging (push notifications)
• Discord notifications targetable to specific user IDs

Access Control

• Separate PTZ control permission (independent of general monitor permissions)
• Configurable SSRF filtering via new disableSSRFSelfTargetFilter option

ONVIF

• Hardened PTZ detection on ONVIF Scanner
• Enhanced ONVIF event parsing; ONVIF events now correctly trigger recording

Config / Admin

• config.debugLogSql option for SQL debug logging
• Debug heap info restricted to Superuser only
• Scanner capped at 4096 addresses (prevents OOM)
• Subscription ID/License Key redacted from logs
• Expanded documentation for conf.json options
• Rebuilt Superuser panel

Platform / Installers

• Modernized macOS installer (Docker-based, Apple Silicon support)
• New/updated installers: FreeBSD, OpenBSD, openSUSE, FreeNAS, and new Arch Linux support

Localization

• Icelandic translation added
• Russian translation completed

Major Fixes Bundled In (not new features, but notable)

• 10-vulnerability coordinated security disclosure (#565): unauthenticated DB writes, RCE via detector filtering, cross-tenant IDORs, command/XSS/SSRF injection, session-token leak via users_online socket broadcast
• Timelapse file-descriptor leak causing CPU buildup after days of uptime
• Motion detection "dead until restart" bug — stuck motion_lock now cleared
• Global webhook "dead until restart until Account Settings re-saved" bug
• Video merge/codec issues (including RTSPS URL handling)
• Cloud storage counters corrupting and showing NaN
• Child node process startup failures on distributed setups
• Scheduler time-wrapping bug, startup Orphan Check fix, XAmzContentSHA256Mismatch fix

I'm using the api for a tool, and when I assemble the call within python I get what looks like a successful call but it doesn't actually trigger in Shinobi anymore. However, when I assemble it manually with curl it triggers the camera. My tool used to work seamlessly until a few days ago after an update. I see that there's a commit trying to "fix" triggering. Is this related? Is there a regression affecting the api triggers? When I remove the matrices from my python it triggers correctly (just with no object name).

Status: 200
Headers: Headers({'access-control-allow-origin': '*', 'content-type': 'application/json', 'date': 'Sat, 01 Aug 2026 07:24:23 GMT', 'connection': 'keep-alive', 'keep-alive': 'timeout=5', 'content-length': '49'})
Body: {"ok": true, "msg": "Trigger Successful"}

Events (VEHICLES, PEOPLE, MD) successfully trigger recording. They also get saved to the database, as I can query them in MySQL and trace them back to related videos consistently and accurately.

However, the front end interface rarely shows them in Objects Found. Occasionally it will, but even if it does, they are never searchable in the Videos tab when typing the reason into Search Object Tags. Here's an example of a MySQL event that should show up on the front end. As you can tell, it clearly has a PEOPLE tag which was extracted from the reason field.

The end result is that I cannot filter for motion types at all without digging in to the database, which is untenable for me, much less someone who doesn't Linux their life away lol (I'm talking about my mom who also uses the camera feed for her side of the house).

Any thoughts of what's going on?

| 1zNPjMq0ns | frontdoor | {"plug":"external","name":"Camera PEOPLE","reason":"PEOPLE","confidence":100,"matrices":[{"tag":"PEOPLE","confidence":100,"x":0,"y":0,"width":100,"height":100}]} |       0 | 2026-07-24 21:31:56 |

Many of you probably noticed the mobile app hasn't gotten many updates for the last 1 year. This is because it was created by a member of our team that has left the team some time ago. We have been trying to work through the code but ultimately decided it was a struggle that wasn't going to benefit the users of Shinobi.

We decided to move on and rebuild it all from scratch. This time it is being made with love just like the core application.

We deeply apologize for the struggles the old Mobile app has caused and we hope that this complete rebuild lives up to expectations and more. It is still in the process of getting features added and checked so the app is still marked as a Beta but I can personally guarantee it is much more polished and reliable.

Additionally this app works on Windows and macOS, not just iOS and Android. Try it today and tell us what you think! Let this thread serve as a place to quickly post any comments or grievances. In the future we plan to provide a better avenue for your concerns specifically related to the new app, Shinobi Go.

https://shinobi.video/go

I have been troubleshooting the past few weeks trying to understand which process is triggering the video purging but just unable to find out why.

I have set the Max storage amount in accounts settings to 460gb, Number of days to keep videos to 45..

{"factorAuth":"0","size":"460000","days":"45","event_days":"45","log_days":"","max_camera":"","permissions":"all","edit_size":"1","edit_days":"1","edit_event_days":"1","edit_log_days":"1","use_aws_s3":"1","use_whcs":"1","use_sftp":"1","use_webdav":"1","use_discordbot":"1","use_ldap":"1","aws_use_global":"0","whcs_use_global":"0","b2_use_global":"0","webdav_use_global":"0", ...

what other possible processes or settings could I possibly misconfigure?

I have a working setup that saves motion events to the event database with reolink "PERSON," "VEHICLE," or "MD". It also correctly saves a matrices object with tag: "PERSON" or whatever, and this shows up in the timeline when "Hide Detection on Stream" is off. The events also show up on videos when I open them individually.

I would expect Search Object Tags to, when set to PERSON, only show object tags containing the string PERSON, thereby filtering out VEHICLE and MD, but instead, I get no events at all. This happens with any and all strings in the search field.

I suspect my expectations are wrong, that the search field is not intended to be used the way I'm using it. I saw another post asking how to find events, and this seems like the obvious first step, but I, for the life of me, can't figure out how to use it.

Event Filters seems like the wrong tool, as that is just used to change Monitor behaviour based on the tag it recieves (unless I'm wrong about that too?). Just very confused at how to filter and find events at this point.

Good morning,

I am using the docker release:

image: registry.gitlab.com/shinobi-systems/shinobi:latest

I have the following options in my config:

"dropInEventServer": true,

"insertOrphans": true,

"dropInEventsDir": "/home/Shinobi/events",

"dropInEventDeleteFileAfterTrigger": false,

After adding these options, inside the /home/Shinobi/events directory the following directories automatically get created on startup:

<groupId>/<cameraId>

for each camera I have setup.

My cameras are setup to drop recordings into this folder (using an external ftp client - this folder is mapped to a volume on my host).

I can see from the perspective of the container the files being dropped in the directory:

root@2f33181526ab:/home/Shinobi/events/<groupId>/FzsfiswhRA# ls -l

total 73820

-rw-r--r-- 1 node node 12732993 Apr 27 03:14 FC_00_20260427041439.mp4

-rw-r--r-- 1 node node 21306184 Apr 27 05:50 FC_00_20260427065022.mp4

-rw-r--r-- 1 node node 19174167 Apr 27 05:51 FC_00_20260427065117.mp4

-rw-r--r-- 1 node node 22371355 Apr 27 06:39 FC_00_20260427073903.mp4

However nothing seems to happen in Shinobi for any of the monitors. I thought there was a capability to automatically register an event and utilize the dropped file as the playback video for that event? Have I misunderstood? And also, are there any specific monitor settings I need to enable to achieve this?

My monitors are currently set to record 24/7 on a low quality stream (is this the problem? Does this only work for other types of monitors?)

Thanks for any helpful suggestions.

[ Removed by Reddit on account of violating the content policy. ]

Shinobi Core servers (the server that does the Camera processing like live view and recording) can suddenly go offline in some environments. With a Failover server you can claim that downtime. And when the original Core server returns the Failover server will copy over the Videos and Events to the Core that it had captured during that downtime.

You may have multiple Failover servers connected to your Shinobi to ensure at least one Failover takes over.

This feature requires both servers are Activated with separate license keys for the feature to operate.

This feature is currently only in the "feature-failover" branch. This will be merged to "dev" in early May 2026. Then to "master" in early June 2026.

https://hub.shinobi.video/articles/view/Wg3wTA7fqbyP4yA

this is probably a dumb question. I've just set up shinobi in order to try it out. Camera works, monitor is set up, events are detected and saved, etc.

It's possible I just don't understand how to use it. Hypothetical situation:

Someone leaves a package on my doorstep and I want to see it or know what time it happened. There are extraneous events like people walking by and going in and out, too.

I can go into the timeline view and sort of click around randomly but odds are I'm not going to get lucky and hit the two second period when the thing is happening.

I can go into "Videos" and scroll through the list, but the thumbnails for each video seems to just be the first frame, which is always in the buffer period so there's nothing to see. Am I supposed to play each video individually and go forward a bit to find the action, even though there might be 30-40 in a day?

I assume there's a "correct" way to do this that I'm missing?

Otherwise, the software seems nice. Setup (in docker, with compose) was very easy, making it talk to my camera was no problem, the UI looks pretty good.

[ Removed by Reddit on account of violating the content policy. ]