Himawaricast decoder - compression error message Bzip2 about satdump HOT 7 CLOSED

Is this the same issue as #541?

Also, I cannot download the baseband for troubleshooting - it says I do not have permission. While this is likely more an issue to be handled by Aang23, if you share it with my Google address as well (from my GitHub profile), I can certainly take a look to see if there's something I can do to help!

from satdump.

Hi Jamie,

I changed the link setting to general access. You can try below:
https://drive.google.com/file/d/1-Pbtb54LQq7KQRDufss6s1moI0Iug7rU/view?usp=sharing

There are 2 separate issues, one is demodulation and the other is decoding.

from satdump.

Thanks! I did a bit of investigating - in this example, the file that is failing is IMG_DK01IR3_202401171411_007.bz2, so not the VIS channel this time. It's failing because the CRC check is coming up invalid within the bzip file. TSReader also complains about a continuity error in the ts. It looks to be bad data to me, but perhaps you're thinking otherwise?

Extracted bz2 segment: IMG_DK01IR3_202401171411_007.bz2.zip

from satdump.

I think I know what's happened.
The Himawari data set includes the visible LRIT (2200x2200) and HRIT (11000x11000). The problem is both come under the same file name and the HRIT is being overwritten by the smaller file LRIT as you can see in the explorer.

Below is the TS stream:
https://drive.google.com/file/d/1UxsC_dHN4ht4GE-1ILauU2gMazwL4VXl/view?usp=sharing

It's a quick fix.

from satdump.

Ah yes, good catch! Although, it looks like the two different resolution images do have different names - they are off by one minute. SatDump was just saving some of them under the wrong name, resulting in an overwrite in some situations.

I now get both vis channels:

Interestingly, it looks like this had an effect on some of the IR channels too, but on that side, the HRIT and LRIT images with the same channel name look quite different:

Try the latest nightly and let me know what you think. I still see the bz2 error, but those appear to be data stream errors.

from satdump.

I just tested it and it works fine. As for the other error, it could be a break in the transport stream when I stopped the recording.
I kind of wish satdump could have TS input socket to perform a live decode from an external source as I don't think satdump's DVB-S2 demodulator does so well with weaker signals.

from satdump.

Glad to hear your primary issue is fixed - as for TS input, I know this is likely planned. If you use Linux, this might be possible through a bit of a hack, and CLI-only. SatDump can unofficially accept input from stdin on Linux (not Windows), so you could try to do something like this:

some-program-that-accepts-TS-and-prints-it-out-to-stdout | satdump himawaricast bbframe /dev/stdin output_dir --ts_input

Netcat might be your friend here to get the data to SatDump's stdin; I'm not very familiar with how TS packets are sent.

Closing this since your issue here is resolved. We'll update #262 when we have some more info, and can follow up there.

from satdump.