#Some notification aren't triggering

1 messages · Page 1 of 1 (latest)

ruby cave
#

I'm on supervised-v1.4.0-beta.2. I've enabled the discord webhook URL.
For Notification routing I have the following enabled for Discord: Rule Violations, New Device, Server Offline and Server Online.

These are the rules I have enabled:

  • Concurrent streams: Max streams: 2
  • Device velocity: Max 2 IPs in 24 hours
  • Geo Restrictions: Allowed: Norway, Sweden
  • Impossible Travel: Max speed: 500 km/h
  • Simultaneous Locations: Min distance: 100 km

I've been testing all the rules and notifications, but they aren't all triggering as expected.
Are there any hidden logic for each of the rules? Like I couldn't get the concurrent streams to trigger If I ran 3 streams simultaneously from the same device, but if I did it from 3 devices on the same network it triggered. Are there similar logic to the other rules I need to be aware of?

Here are the notifications I'm able to trigger by testing with VPN and different devices:

  • Server offline
  • Server online
  • Rule Violations:
    • Concurrent streams
    • Device velocity
    • Geo Restrictions

Here are the notifications I'm unable to trigger:

  • New device
  • Impossible travel
  • Simultaneous Locations

My brother got a new google tv for christmas. Tautulli gave me a new device notification when he started using it, but I'm not getting anything from Tracearr. I have a spare phone as well that I tried with. Enabled VPN on it and logged into plex and started playing a movie, but no notification.

So far I haven't been able to trigger impossible travel either. I enabled VPN and started a movie from "USA" and "Russia", that triggered the Geo Restriction for both countries but not the Impossible travel. Are there any caveats here that makes it not trigger?

I was hoping that enabling different types of logging for the container would give me an insight into this, but neither debug, warn or error seems to show anything more then what info does 🤔

rustic crystal
# ruby cave I'm on supervised-v1.4.0-beta.2. I've enabled the discord webhook URL. For Noti...

Concurrent Streams:

  • Trigger: Count of active playing streams > maxStreams
  • Exclusion: Same deviceId is excluded from count

Impossible Travel

  • Exclusion: Same deviceId is excluded
  • VPN will not always get location either.

** Simultaneous Locations**

  • Trigger: Different devices + BOTH actively playing

** New Device**

  • Not implemented currently

Logs:
docker exec -it tracearr tail -f /var/log/supervisor/<FILENAME>

tracearr-error.log
postgres.log
postgres-error.log
redis.log
redis-error.log
supervisord.log

Marking as resolved

ruby cave
#

Thanks for the response! That makes sense then 👍 Ill take a look at the log locations

rustic crystal
#

Also - @ruby cave The backend is there TO make same device logic toggleable. But IMO other than test cases I don't see much reason for those rules not to have that option just forced-on.

Even impossible travel, thats mainly applied TO account for VPN use. As there really isn't a reliable way to say is this device on a vpn?.

These rules started out as fairly unrestricted, and have gotten tighter and tighter. This is to refine the logic as much as possible, and give control where needed until we get to the point where I / the community is confident in them and their accuracy.

At that point, I will roll out automated actions. But not until that point.

I think anyone with a little effort could "sidestep" the rules. But ultimately with the data we are able to collect from each streaming service I do not see a path to ever being perfectly air tight. So I'd rather fall to the more conservative approach

ruby cave
#

Yup, totally agree. Other then for testing having that logic seems perfectly fine! Would it perhaps be possible to add a descriptor for each rule, stating what logic is behind it. Like a little notice box on the popup modals? Or would that just add unnecessary noise for the end user 🤔

rustic crystal
#

And maybe I will enable the same device toggle at some point, but I need to rethink the rule UI anyways - especially with automated actions coming.

I just refuse to clutter the UI with options, and "advanced" toggles etc that the other *arr apps have. I hate the idea of having extremely opinionated logic.. But also a lot of these thigns have been reactively implemented because of false triggers in normal use cases.

And yeah - I will 100% make the rules interface better

#

I just have to sit down and come up with an intuitive way for the user to interact with it.

Rules is one of the early UI elements I created and is now pretty immature compared to the rest of the application in comparison

ruby cave
#

Awesome! You've made an amazing project here. Love that you are so active 🍻

rustic crystal
#

But im also trying to give some more attention to the mobile apps, so I can get those released.

rustic crystal
#

But i spent today white-boarding a "Tracearr light". Same thing but without multi-server support, and some other features removed.

ruby cave
#

I haven't seen much of a hog so far. Its been using a pretty mild amount of resources. But I have a lot to take from as well, so I might just not notice it faxLUL

rustic crystal
#

Based on Sqlite. I just also know that after you hit a certain point it will fall over. The data is time series data, and using something like sqlite or really any database/store that isn't meant for time series will be met with the same fate

rustic crystal
ruby cave
#

Im just glad to be able to get rid of Tautulli. I'm experiencing the query slowdown bug that is still listed as open on their github

rustic crystal
#

Which is bang on lol. But for me this is personal tool that went public.. And I just wanted consistent performance, forever. I work for a company that does HW/SW monitoring at scale and for us it's not a big issue when you can throw more hardware at a problem and resolve it.. Its when you can't throw hardware at a problem that things get hairy