Ada

Specifically, it occurs when the cows eat high volumes of clover or other nitrogen fixing plants (most legumes fall in to this category). Ruminants produce a lot of gas in their digestive process, because their stomachs are designed to ferment their food, allowing them to better access highly fibrous food sources like grass. Normally, they belch or fart the gas away, but in the case of nitrogen fixing clovers, they produce too much gas to be able to burp and fart away, and they end up with fatal bloating!

I remember learning this in school in rural Australia. The most amazing thing is that I still remember it :P

Someone spilt the tea…

I don’t care if I like them. I very much care if I’m making money for people who are actively trying to take away my rights

He left Mozilla (chased out because he’s a homophobe) and went on to found Brave, where he still remains

The fact that the dev behind brave is a homophobe isn’t opt in though…

ADHD doesn’t work like that, and this whole discussion is full of the sort of responses ADHD folk get every day :\

Is there any way of forcing it to rebuild places and trips? Somewhere along the line, most of mine disappeared. It’s still building new ones just fine as GPS logger adds real time data, but most of my historical stuff is gone.

The actual data is there, and it shows up fine on the maps for each day, but the places/trips/stats etc are mostly empty.

I can’t see anything in the logs that might explain it

I’ve got a question about how reitti calculates significant places/visits.

I was thinking of adjust gps logger so that it doesn’t log points if they’re within 10m of the last point it logged. That will clear up the data when I’m at home or work, so that there is less of a random squiggle of location data. It will record me arriving at home, and leaving home, but not much in between.

Will that impact how reitti calculates locations though? Is it looking at the number of points, or is it simply a matter of duration within a particular vicinity?

Having all of this data stored in a location I can control has been really good.

But yesterday, it was pointed out to me that the API reitti provides means I have access to over a decades worth of location history that I can use to geotag my photo collection! That is a game changer. I’ve been trying to find a way to pull that information from google location history for a long time, and it turns out, you’ve created it!

This is really valuable to me, so I want you to know just how much I appreciate the effort you’ve put in to making it. Thank you

I’m on android. I’ll raise a bug report.

Well, the last update seems to have cleared the queue, and all of my history from that 10 year import now shows, with trips and places identified!

But now, it’s having issues with importing the new google format import. I’ve got a 34MB file there that goes back to 2017, and this data says that it has imported, but then never appears in my history.

If it’s relevant, there is overlap in the data, as my 10 year takeout import went up to 2023, and my “new format” import starts in 2017 and went a couple of days ago. I changed my google account in 2017, but logged in to both on my phone simultaneously, so I was accruing location data on both accounts at the same time for a while before I turned it off on my old account.

Who?

That’s really interesting. Australian here, and I’ve remarked several times how the userbase of the fediverse isn’t dominated by American voices like most other social media platforms I’ve used.

Since I last commented, the queue has jumped from about 9000 outstanding items, to 15,000 outstanding items, and it appears that I have timelines for a large amount of my history now.

However, the estimated time is still slowly creeping up (though only by a minute or two, despite adding 6000 more items to the queue).

I haven’t uploaded anything manually that might have triggered the change in queue size.

Is there any external calls made during processing this queue that might be adding latency?

tl;dr - something is definitely happening

Ok, so it may not be frozen. The numbers in the queue seem to imply it is, however, timelines and places are slowly filling out in my history. A couple of dates I had looked at previously were showing me tracklogs for the day, but not timeline information, and now, they’re showing timelines for the day

I was also trying to set up GPSLogger whilst it was crunching through the backlog, and I manually transferred a file from that app before I had autologging configured. Not sure if that could have done it?

The times don’t overlap, as the takeout file is only up until 2023

i7-8700 with 64GB of RAM

It’s a 1gig json file that has about 10 years of data. I get multiple repeats of the rabbit timeout in the logs. The Job Status section tells me that it’s got just under 9 hours of processing remaining for just over 16,000 in the stay-detection-queue. The numbers change slightly, so something is happening, but it’s been going for over 12 hours now, and the time remaining is slowly going up, not down.

reitti-1  | 2025-07-04T03:06:17.848Z  WARN 1 --- [ntContainer#2-1] o.s.a.r.l.SimpleMessageListenerContainer : Consumer raised exception, processing can restart if the connection factory supports it
reitti-1  |
reitti-1  | com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - delivery acknowledgement on channel 9 timed out. Timeout value used: 1800000 ms. This timeout value can be configured, see consumers doc guide to learn more, class-id=0, method-id=0)
reitti-1  |     at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.checkShutdown(BlockingQueueConsumer.java:493) ~[spring-rabbit-3.2.5.jar!/:3.2.5]
reitti-1  |     at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.nextMessage(BlockingQueueConsumer.java:554) ~[spring-rabbit-3.2.5.jar!/:3.2.5]
reitti-1  |     at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.doReceiveAndExecute(SimpleMessageListenerContainer.java:1046) ~[spring-rabbit-3.2.5.jar!/:3.2.5]
reitti-1  |     at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.receiveAndExecute(SimpleMessageListenerContainer.java:1021) ~[spring-rabbit-3.2.5.jar!/:3.2.5]
reitti-1  |     at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.mainLoop(SimpleMessageListenerContainer.java:1423) ~[spring-rabbit-3.2.5.jar!/:3.2.5]
reitti-1  |     at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1324) ~[spring-rabbit-3.2.5.jar!/:3.2.5]
reitti-1  |     at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]
reitti-1  | Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - delivery acknowledgement on channel 9 timed out. Timeout value used: 1800000 ms. This timeout value can be configured, see consumers doc guide to learn more, class-id=0, method-id=0)
reitti-1  |     at com.rabbitmq.client.impl.ChannelN.asyncShutdown(ChannelN.java:528) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     at com.rabbitmq.client.impl.ChannelN.processAsync(ChannelN.java:349) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     at com.rabbitmq.client.impl.AMQChannel.handleCompleteInboundCommand(AMQChannel.java:193) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     at com.rabbitmq.client.impl.AMQChannel.handleFrame(AMQChannel.java:125) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     at com.rabbitmq.client.impl.AMQConnection.readFrame(AMQConnection.java:761) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     at com.rabbitmq.client.impl.AMQConnection.access$400(AMQConnection.java:48) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:688) ~[amqp-client-5.25.0.jar!/:5.25.0]
reitti-1  |     ... 1 common frames omitted

I managed to break our instance. I imported several years worth of google takeout location data, and now the “stay-detection-queue” is stalled.

If this actually stands a chance of taking off, I’ll honestly take what I can get to normalise HDR images