Satnogs-monitor no longer running on any PC, are there network problems?
I can confirm that it is seemingly not working any more, from a station where I have been using it recently.
Recently due to performance issues, there was a change on the observations API pagination. Instead of using the pages pagination it uses cursor pagination.
The next page link, to move to the next page of results is available in the standard response header Link, so a program that uses the API, should use this way to navigate through the pages.
In this part of the code we can see that satnogs-monitor doesn’t use the Link header but iterates infinitely the page parameter, in other words to move on the next page it adds in the url this parameter ?page=x where x is replaced each time with a page number. Unfortunately this way doesn’t work any more.
The way it is implemented uses two ways to break the infinite loop, the one is by getting a page with less than 25 results, which would mean that this is the last page. The other is by getting a 404 error, that the page doesn’t exist. With the current status, the ?page=x parameter is ignored with any value for x and returns always the first page. This means that it will never hit 404 error and if the station has more than 25 past observations, it will never hit the less than 25 results break. So it looks like it remains in the infinite loop and this is why you don’t see any results.
Unfortunately I’m not very fluent in Rust language so I can not propose a solution and from the comment in the code:
// We cannot use the response headers to know if there is next page with more
// results. So we iterate over every page and stop if we receive an HttpError 404.
I’m not sure how easy would be a code change to use the response headers and especially the Link header that will allow navigation through the pages.
@wose maybe can take a look on it.
PS above is my guess of what looks like to be the issue, maybe there is another issue that I haven’t spotted
Thank you for the quick reply, it’s strange because on the same PC I have 2 simultaneous sessions as you can see from the following link SatNOGS Network - User: ik1jns , and the second session on ID=3523 works, it seems only the first on ID=446 I have this problem and with netstat I have this result while with the second session it works normally.
1 Like
hm… maybe then it filters the observations API endpoint to show only the future observations. In this case the station with ID 3523, that has less than 25 future observations, it will hit the break and will get out of the infinite loop, while station 446 with 25 future observations will stay forever in it.
Unfortunately I can not check the above right now as I’m on mobile but I’ll try to take a look later today. By the way if only the future observations are necessary, I suggest it should hit the jobs API endpoint which returns only the future observations and without pagination.
However maybe the project uses some fields from observation entry that are not exposed in jobs entries, in this case and if the access to the response header is not possible, I suggest it should get the observations from the jobs API and then using the observation IDs, hit the observations API endpoint with filtering with 25 IDs each time (to limit it to only one page) to get the extra info. For the filtering it needs the parameter ?observation_id= and as value the observations IDs separated by commas, for example ?observation_id=9319687,9319686.
Thanks for the help, I solved it, I was wrong when entering endpoint api, now by entering the correct command it works. I was deceived by having 2 IDs and on one it worked and the other didn’t, as you rightly noticed, the first is 5 years old and therefore many more registrations, the second is new and has few registrations. The other reason is that until a few days ago it always worked. Sorry for wasting your time, but I think this topic could be helpful to others too. Thank you
right command
It looks like im getting the same issue. Just stated a new setup and Im getting the same issue:
/home/pi/satnogs-monitor/target/release/satnogs-monitor -l 1370
How did you solve it @ ik1jns ?
I tried the following as well:
/home/pi/satnogs-monitor/target/release/satnogs-monitor -l 1370 -a SatNOGS Network API
No difference and this is related to this observation here: SatNOGS Network - Observation 9750742
Actually it doesn’t work for me anymore, I’ve tried several times, but I’m not receiving the satellites, only the CPU values are OK.
I ended up forking a fork of the satnogs monitor which fixed the API call and then I had fix some deprecated dependences which prevented it from being built. Now it works great for me.
I haven’t updated or made any debian images but the docker works fine at the very least.
2 Likes
Thanks for the work you do for everyone, I have a docker installation and I tried to install the new version but towards the end I get the following compilation error. Do you have any idea how to solve it? Or do I have to reinstall the full satnogs-client image?
Still no update in the pagination ? This is (has been) the main issue since the api changed, so if you have more than 20 observations scheduled it will simply fail. Although I don’t remember the exact mechanic.
The build has been a hassle for me since the start, my methods stopped working from time to time. I am no good at Rust thou.
Regarding the Dockerfile, I think the cloning of the -monitor repo is a poor solution since it needs to change on everybody’s forks. Changing that line to COPY . . would simply use the local repo on the host to build with.
@ik1jns
You should only have to clone my fork of the repo and run the docker build command and it should work fine (ignoring some warnings).
@SA2KNG
Ah gotcha. I am no rust expert and more or less was just trying to get the satnog-monitor to work at all.
I’ll see about at least fixing the docker image build so it doesn’t clone the repo at least but switching to pagination will have to wait tell later or someone else more capable will have to fix that still.
I will say so far the fork I forked seems to have fixed the issue with more than 20 passes scheduled. Would be nice to have it merged back with the main repo though.
Great job, everything works for me, I have an installation with 2 separate docker sessions VHF and UHF and now the monitor works perfectly.
Thanks 