danielgraf

@danielgraf@discuss.tchncs.de

• ⁨Comment⁩ on ⁨Reitti (v1.1.0) Update: Family mode, faster processing, colors!⁩ ⁨⁨4⁩ ⁨days⁩ ago⁩:

  To change the password and the user of the db you have to change it in the postgis service but also need to let reitti know that it is not the standard anymore. You need to set the environment for reitti according to the Readme

  If you want to start from scratch you probably need to delete the volumes from docker. See here

  Normally the volumes are called reitti_postgis and so on.

  Let me know if you need further assitance, i am currently on mobile but can provide more info later

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  Someone would need to get that data out of the app. Either as GPX or some other format. I do not think these devices are able to send the position to some configurable endpoint. A quick search for nut tracker and home assistant does not yield any reasonable results.

  I think we are out of luck at that point. But maybe someone knows about a more open tracker device which could be configured.

• ⁨Comment⁩ on ⁨Reitti (v1.1.0) Update: Family mode, faster processing, colors!⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  Reitti displays data coming either from an import. You could upload GPX, GeoJson files or export the data from google maps and import that. If you want more up to date data, you could install an app on your phone which pushes your latest locations into Reitti. GPSLogger or Owntracks are at the moment supported for that

• ⁨Comment⁩ on ⁨Reitti (v1.1.0) Update: Family mode, faster processing, colors!⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  No, not really. It just makes it easier to spin up all the needed services and it is at the moment the “documented” way.

  On the release there is also jar of Reitti.

  If you need any help in starting that, let me know.

• ⁨Comment⁩ on ⁨Reitti (v1.1.0) Update: Family mode, faster processing, colors!⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  You are right, I missed that they are still open for the other services. I have mine running behind traeffik and did removed all port definitions.

  I will change the compose file to only expose Reitti.

  Thanks for the feedback🙏

• Reitti (v1.1.0) Update: Family mode, faster processing, colors!github.com ↗
  Submitted ⁨⁨1⁩ ⁨week⁩ ago⁩ to ⁨selfhosted@lemmy.world⁩ | ⁨31⁩ ⁨comments⁩
• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  If you are running Reitti with Docker, you can set the environment variable DANGEROUS_LIFE to true. This will enable a new section in the Settings. There, you can use the button ‘Clear and Reprocess’. This will delete all visits and trips and set all raw data points to unprocessed. During the next run, everything will be recalculated. In that settings section, you could also press the ‘Start Processing’ button if you don’t want to wait. Make sure to wait until the success message appears. It can take a while until all data is deleted and switched to unprocessed.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  Greetings, @Pandoras_Can_Opener@mander.xyz, that sounds like a truly wonderful idea, and as a fellow cat owner, it brings me great joy to hear about it. 😻

  In fact, I have recently changed the analysis of data, which is now performed in near real-time as soon as new data becomes available. I am currently working on the functionality to display multiple users (or, in your case, Pandora) on the map, which should be beneficial to your idea.

  Now, the primary question is, how can we integrate the data from the tracker into Reitti. Thats something I have no idea at the moment. Do you have any Infos about that?

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  Hi ada,

  yes, this will impact the visit calculation. Visits are calculated in building clusters of at least 5 points in a range of 100m over a duration of at least 5 minutes. If there is only one point logged for example at work or home, Reitti is not able to detect when you left it because every point is just an instant in time and does not carry any duration information with it.

  The more points we have to calculate Visits the more accurate it will be. I personally have set up GPSLogger to log every 30 seconds no matter how far I travelled but with at least 40m of accuracy.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  Hi LazyToad,

  it depends. Reitti on its own does not import any pictures. It only shows fetches them from Immich. For that to work it needs the geolocation where the image was taken in the exif data. You need to check if your expected image has this data in Immich. If it is available it shoud be displayed on the map if you select the day the picture was taken.

  Does it show the location in Immich? You can verify this if you open the image in Immich and let it display the Info.

  Image

  If it is showing, then it still could be that it is a bug in Reitti. Feel free to open an issue then :)

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  Thank you very much for these kind words. Means a lot to me if my little tool brings value to you :)

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  Cool, thanks for the feedback.

  For: 1: There should be something about downloading in the Photon logs. You can check with docker compose logs photon. I do not remember how long it took to download the index for Germany, but it was noticeable. It depends a lot on how you are connected to the internet and then how long it takes to extract the index.

  2: You should also see that in the log of Photon. If the default does not work reliably, you can create an account on Geoapify; it is free, and you get 3000 reverse geocode requests per day. I personally have Photon for DE and then the default service and additional Geoapify.

  3: Yeah, I was also thinking about that. In the end, a per-user setting and then the overlay should be disabled, but it could take a while until I can get to it.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  I am glad it worked out for you in importing the first file. I am still puzzled why it took that long.

  For the new format, did you have Android or iOS? With the timeline export from Google Maps on iOS, we can not do anything at the moment because there is actually no raw data in it. Only information like you stayed in this timeframe at that point and you traveled between these points. It’s actually a little bit funny that it aggregates to the same data Reitti uses in the end.

  If you are on Android, it could also be a bug when importing that file. I only had a small one from one of my accounts to test. If you mind creating a bug report, I will have a look. If you do not want to attach the export file there, feel free to send it to daniel@dedicatedcode.com. I will have a look at it then privately. No problem.

  For the overlap in exports, it depends. If the points are the same, meaning they have the same timestamp, then Reitti will discard them. If not, they will be handled like every other new data and will end in recalculating visits and trips around that particular time.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Glad I could help :)

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  This process is not triggered by any external events.

  Every ten minutes, an internal background job activates. Its function is to scan the database for any RawLocationPoints that haven’t been processed yet. These unprocessed points are then batched into groups of 100, and each batch is sent as a message to be consumed by the stay-detection-queue. This process naturally adds to the workload of that queue.

  However, if no new location data is being ingested, once all RawLocationPoints have been processed and their respective flags set, the stay-detection-queue should eventually clear, and the system should return to a idle state. I’m still puzzled as to why this initial queue (stay-detection-queue) is exhibiting such slow performance for you, as it’s typically one of the faster steps.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Thank you for testing Reitti. 🙏

  It depends on two key requirements for Reitti:

  1. First, it finds all photos from Immich taken on the day you selected.
  2. Then, it filters these photos based on the selected map bounds, using the embedded EXIF geolocation data (where the photo was shot).

  If the EXIF data does not contain geolocation information, we currently cannot display those photos because their placement on the map cannot be determined.

  Could you please verify in Immich if the expected photo has its location in the metadata? If it is available there, then the issue might lie in how Reitti is parsing that specific data.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  That’s good, but I still question why it is so slow. If you receive these timeout exceptions more often, at some point the data will cease to be analyzed.

  I just re-tested it with multiple concurrent imports into a clean DB, and the stay-detection-queue completed in 10 minutes. It’s not normal for it to take that long for you. The component that should take the most time is actually the merge-visit-queue because this creates a lot of stress for the DB. This test was conducted on my laptop, equipped with an AMD Ryzen™ 7 PRO 8840U and 32GB of RAM.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Thanks again for the follow-up. It is something I can investigate. I doubt that it is somehow related, but who knows. 🤷

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  It is actually awesome if you have some old photos with the geodata attached and scim through Reitti and suddenly one of them shows up :)

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Hmm, I had hoped you say something like a Raspberry PI :D

  But this should be enough to have it processed in a reasonable time. What I do not understand in the moment is that the filesize should not affect it in any way. When importing it 100 Geopoints are bundled, send to RabbitMQ. From there we retrieve them, do some filtering and save them in the database. Then actually nothing happens anymore until the next processing run is triggered.

  But this than works with the PostGis DB and not with the file anymore. So the culprit should be there somewhere. I will try to insert some fake data into mine and see how long it takes if i double my location points.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Thanks for the information. I will try to recreate it locally. In my testing I used a 600MB file and this took maybe 2 hours to process on my server. It is one of these ryzen 7 5825U. Since Reitti tries to do these analysis on multiple cores we start it with 4 to 16 Threads when processing. But the stay detection breaks when doing it that way, so it is locking per user to handle that. If now one of them takes a long time the others will break eventually. They will get resheduled 3 times until rabbitmq gives up.

  On what type of system do you run it?

  I will add some switches so it is configurable how many threads are opened and add some log statements to print out the duration it took for a single step.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  It was not intentional but after bothering not about it because i had other things on my mind i got used to it and now like it the way it is.

  But for everyone who is bothered by that. If Reitti reaches 1k stars on Github I will add a switch to use a centered one 😊

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Congratulations 😆

  To help with that I would need some information:

  • does it show anything in the logs?
  • what do you mean by several years or how big was the Records.json?

  Thank you for testing 🙂

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  Oh, i had the idea in mind what i want to create and than it was a matter of a couple of Google queries but in the end one of the LLM suggested a list of different names in foreign languages and reitti somehow sticked 😊

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  I had a similar setup with Home Assistant in the past so I understand your usecase. For Reitti to detect visits somewhat reliable it needs at least one datapoint of location data a minute. We build location clusters with minimum 5 points in 5 minutes. If HA tracks that often it should work. HA probably tracks more than that.

  I could add an integration that it fetches the data from Home Assistant. Do you mind in creating a feature request?

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  I have no experience with traccar but it seems that it supports live tracking. This is something Reitti does not support. Depends on your usecase, but i think traccar is better suited.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  I looked at the docker image i am using in the docker-compose file and this only supports having a single country code. The actual reason can be found here: github.com/rtuszik/…/start-photon.sh#L341C5-L342C…

  It is probably possible if you deploy photon on its own and then import the data somehow. But that is to much hassle for me, i think and hope that most of the use case is handled by the current solution. At least for most of the potential users. But I get the point if someone is traveling a lot between countries.

  If there is enough demand I could maybe try to create a PR for the Docker image to handle multiple country codes.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  I think this is not exposed when running the Docker container. But let me check later when i have time what happens if i put another country in that variable

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  I would not say compete. They are different in how things are done from my point of view. I want to focus more on the visits we have done in the past to relive some lost memories whereas Dwarich looks more “technical” for me. I have no better words for it, I hope you get my point in what i am trying to achieve with Reitti. So there should be enough room for both 🙂

  I also do not have any intentions to offer a hosted version in the foreseeable future or even anytime.

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨3⁩ ⁨weeks⁩ ago⁩:

  I used that once on a past gig and it wasn’t very pleasant to use. Especially in combination with spring boot. But that is a couple of years ago. Maybe things have changed. I personally would prefer the executable jar from spring boot. With that you do not have to make that many steps to make it work. But thanks for the suggestion :)