danielgraf

@danielgraf@discuss.tchncs.de

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

  Glad I could help :)

• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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⁩ ⁨⁨1⁩ ⁨day⁩ 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 :)

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

  Good question, afaik you can not enter multiple countries to Photon. I was hoping it would be possible but everything i saw was it is either on country or the whole world. But maybe you can have a look here: github.com/komoot/photon That is the service we are using.

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

  I was thinking about that, but the main problem is that we do not store all the data which comes in.

  If we ingest data from an app, I am pretty sure that the quality of the data is actually usable. But for example if we import an Records.json from Google Takeout. The quality of the earlier years is somewhat sketchy. For this we filter out some points like travelling with over 2000 km/h, sudden direction changes etc and they are lost forever. At least for Reitti they are unknown.

  The feature would need a lot of explanation why the data we export is not the same we import.That is the reason I did not implemented it even if it would come in handy for testing stuff. Handling GPX files is a pita …

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

  Maybe the wording is confusing in the Readme. Reitti will try to fetch the data from a configured photon instance first, if this does not return anything and you have Geocoding services configured, it will try them. There is actually no switch for hybrid mode or only local. It depends on what is configured.

  Photon Only: you have only photon configured and under Settings > Gecoding you deleted or disable every available service. Hybrid Mode: Photon is configured and under Settings > Geocoding there are Services available. That es is the one I use. Having Photon with the data for Germany and all the rest is handled by Geoapify.com. External Only: You dropped Photon from the docker-compose file and only rely on services under Settings > Geocoding

  If you do not configure anything, then Reitti will skip Geocoding and only display Unknown Place.

  I will update the Readme to make that clear.

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

  Thanks :)

  No, did not occur to me. What would the integration look like? Connecting it to the message bus to receive location updates? Honestly it is a couple years ago I played with HA.

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

  Not really, I stopped using IOS a year ago because of exactly this reason. Had a lot of problems syncing files because of the power saving. I understand why IOS is doing it and for a normal user I think it is the way to go. But anything beyond that, it only hinders the experience you get out of apps. Maybe someone here as any experience with an app which works reliably.

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

  Thanks :) As a German I really like the name Dawarich. First it sound really nice for me but also that “Da war ich” means “There have i been” in german makes, at least for me, an awesome project name.

  Take this with a grain of salt because I have no idea what the plans are for Dawarich or have ever been and this is solely based on my external view. For me the main differences are:

  • visits and trips are our main data, everything else is just the way to calculate them. For Dawarich it looks to me, that it is the other way around. It displays all the location data in good way with the heatmap and so on but visits or places seems so tacked on. This should not be an offense against it. I actually still have an instance running and it was the main pushing point to finally start working on Reitti.
  • the sleek UI but this depends on your taste

  In the end, they are not that far off. Maybe a matter of taste.

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

  Thank you.

  At the moment i do not have any plans of providing a way of running it without docker. Mainly because of time to support that.

  Since it is a Spring-Boot-Application it would be possible to create a jar file which you can execute or deploy as a service with systemd. But then you have to make sure all prerequisites are also running. That is the one thing I like about docker and especially docker compose.

  But short answer: Yes, it is possible but you are on your own at the moment. I would help and maybe we can add a section to the readme how to do it.

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

  I do not think it is that complicated. The front-end sends a request to the back-end with the current selected day. This triggers a search in Immich returning all photos taken on that specific day. This is returned to the front-end and this than does the heavy lifting like filtering them to the current map bounds, displaying them on the map at a specific location. We proxy all request from the front-end through our server because of CORS issues and I did tried to avoid having to configure Immich besides creating a token for the API.

  One would need to either create a specific IntegrationService like ImmichIntegrationService and then figure out a way how the user can configure that. The easiest would be that we just then call all available ones even if I do not see the use case of having multiple Photo-Servers. But it would make the code in Reitti cleaner and would not hurt if we do not configure 20 simultaneous servers :D

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

  If you use Photon and only have your main country available, it will fallback to the configured external Geo-coding-services since Photon will not return a result then. So the order of execution is:

  • first try Photon
  • if it does not return anything, try to call one or all of the available Geo coding services.
• ⁨Comment⁩ on ⁨Introducing reitti: a selfhosted alternative to Google Timeline⁩ ⁨⁨2⁩ ⁨days⁩ ago⁩:

  no, that would not be a problem as soon as the other image library has an api reitti could query. It just happens that I am settled with immich and had no other needs at the moment.

  If you need a specific one, drop a feature request and I will have a look.

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

  Thank you :)

  I understand your concerns, this is something every additional app would have to deal with.

  For me it is ok to have GPSLogger running all the time, I think for what it is doing it is quite easy on the battery but I do not use my phone actively that much and I am happy if it survives a day which it does.

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

  Never heard of PhotoStructure but if they provide an API where i can search assets for a day and it also returns the exif data especially latitutde and longitude it should be pretty straight forward to implement. Feel free to add a feature request when you got time and I will have a look at it :)

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

  Let me know how it works out for you. If you have the gpx files, you can simply import them inside the settings menu.