Hi,
It seems the algorithm which should delete observations without records does not clean up when there is data or audio present. I have 11 recordings with only data and only auto which I can not vet and the cleanup algorithm does not delete them as it did with empty recordings. They pile up now in my unvetted list. Can someone please help me?
Greetings
Ansi
Hi,
pretty please?
I don’t know how to solve this problem and I need someone with more rights to solve this problem or a fix in software.
Thank you.
Ansgar
You pretty much cant delete them.
This is a result of the current change towards vetting artefacts (waterfall files, audio, packets) instead of the observation as a whole. The idea would be that the packets would pass through a decoder (if one exists for that sat), and if they cant be decoded then they are marked as bad.
However in your case (no waterfall, no audio, but data packets? seems sus!), I agree that there should be some ability for the station operator to consider the observation in its entirety as failed.
In your case it seems to be particularly an issue with CW observations, which are going to be almost impossible to vet automatically anyway…
I also see a bunch of observations (looking here btw: https://network.satnogs.org/observations/?future=0&good=0&bad=0&failed=0&norad=&observer=&station=1492&start=&end= ) where there is only audio and nothing else.
An example is this one: https://network.satnogs.org/observations/3043018/
There’s clearly a full pass worth of audio there, though without the waterfall it’s difficult to know if the lack of signal in that observation is due to a station issue, or just no transmission from the sat (it is Fox-1A, so the latter is likely). Personally, I would want to mark that observation as ‘Bad’, but there is currently no way to do so without the waterfall being present!
Hi,
thank you for your repl. I really appreciate it.
The “root cause” is a full SD card. The data is
pushed doing the recording (so no problem with
full HD after 5 hours of continuous recording).
The same with only audio. The SD was nearly full so
so upload works but converting the waterfall diagram
does not.
I am going to add a USB stick for /tmp/.satnogs but
still need to “delete” the old recordings.
Greetings Ansgar
Some quick and generic comments:
As we are in a transition phase of rating/vetting process, we expect to have some issues. About the unvetted list and the badge that is shown at the top bar, I’ve just landed some fixes so it will show and count only those observations that users are able to rate/vet.
Unfortunately due to limited resources and other more prioritized tasks, changes on rating/vetting have been put on hold. However I think that soon we will be able to work on them.
Done observations are not deleted, this is a decision made some years ago in order to be able to study the behavior of the stations and of the Network as a whole.
@Acinonyx works on client side to debug the main reason of client crashes which end up on observations without artifacts (waterfall/audio). However as currently there isn’t a way to reproduce this bug, he can only check it when it occurs, which is random and not very often. If anyone wants to help, please come in contact with him in #santogs-dev channel in matrix/irc.
One last generic comment, please make sure you run the latest version of client.
That is strange behavior, /tmp/.satnogs is stored in the memory (not sd-card) and files are removed (when client is on default settings) after uploading the artifacts to Network. Having full /tmp/.satnogs it means that something is going wrong with the uploading process. We will need more details to find out what happens, could you copy paste the results of “Advanced → Support” option in stanogs-setup, maybe we can find what’s going wrong from the configuration.
Hi Fredy,
thank you for your update. Here is the support information. For now, I replaced the tmp in /etc/fstab with a USB stick to have more space for the recordings.
Thank you for your help
Greetings
Ansgar
------------[ copy here ]------------
{
“versions”: {
“satnogs-client”: “1.4”,
“satnogs-client-ansible”: “202010161917”,
“satnogs-flowgraphs”: “1.2.2-1”,
“gr-satnogs”: “2.1.2.1-1”,
“gr-soapy”: “2.1.3-1”,
“gnuradio”: “3.8.2.0-2”,
“satnogs-config”: “0.11”
},
“state”: {
“is-applied”: true,
“pending-tags”: null
},
“system”: {
“date”: “2020-11-02T18:30:26.633154+00:00”,
“distribution”: {
“DESCRIPTION”: “Raspbian GNU/Linux 10 (buster)”,
“RELEASE”: “10”,
“CODENAME”: “buster”,
“ID”: “Raspbian”
},
“pending-updates”: true,
“platform”: {
“system”: “Linux”,
“node”: “satnogs-receiver”,
“release”: “5.4.72-v7+”,
“version”: “#1356 SMP Thu Oct 22 13:56:54 BST 2020”,
“machine”: “armv7l”,
“processor”: “”
},
“memory”: {
“total”: 1021706240,
“available”: 901206016,
“percent”: 11.8,
“used”: 60387328,
“free”: 707813376,
“active”: 100696064,
“inactive”: 169721856,
“buffers”: 23302144,
“cached”: 230203392,
“shared”: 6799360,
“slab”: 26198016
},
“disk”: {
“total”: 7594229760,
“used”: 4167557120,
“free”: 3070668800,
“percent”: 57.6
}
},
“configuration”: {
“satnogs_antenna”: “RX”,
“satnogs_api_token”: “[redacted]”,
“satnogs_gain_mode”: “Settings Field”,
“satnogs_other_settings”: “IFGR=20,RFGR=1”,
“satnogs_rx_bandwidth”: “600000”,
“satnogs_rx_samp_rate”: “2000000”,
“satnogs_soapy_rx_device”: “driver=sdrplay”,
“satnogs_station_elev”: “23”,
“satnogs_station_id”: “1492”,
“satnogs_station_lat”: “52.4937782”,
“satnogs_station_lon”: “13.4483546”
}
}
------------[ copy end ]-------------
pi@satnogs-receiver:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 7416240 4069880 2998700 58% /
devtmpfs 465600 0 465600 0% /dev
tmpfs 498880 0 498880 0% /dev/shm
tmpfs 498880 6636 492244 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 498880 0 498880 0% /sys/fs/cgroup
/dev/sda1 3825940 7736 3604140 1% /tmp/.satnogs
/dev/mmcblk0p1 258095 55169 202926 22% /boot
tmpfs 99776 0 99776 0% /run/user/1000