Air Traffic Monitoring > Listener Forum

Archived clips with length much shorter than 30 minutes - any idea why?

(1/2) > >>

rnzoli:
Hi, did anyone come across a problem, that then ormally 30-minute archived MP3 files are truncated to a much shorter length, e.g, 18 or 17 minutes?
I initially thought this was a way to save disk space by trimming silence at the beginning and end of that period, but I was obviously wrong.

The feed is LHBP Tower, and I checked 2 archived clips
LHBP-Twr-Sep-06-2016-1000Z.mp3  --> Only 18 minutes 16 seconds
LHBP-Twr-Sep-06-2016-1030Z.mp3 --> Only 17 minutes 52 seconds

Maybe this is a problem with the feed itself, e.g, frequent resets or drop-outs?
Or some wrong time mismatch between the PI Raspberry and the central archive server?

dave:
This can happen when the internet connection at the receiver site has issues....or the encoder used to send the stream has issues.

rnzoli:
I randomly checked a few archived files from today, I found 15:52, 17:52, 28:00, 20:48, 31:36.
This doesn't look good, very unreliable.
What can we check on the feeder side? Are there any internet error counters that could help eliminating whether it's the connection or something in the Raspberry PI or in the encoder? (I assume the scanner's are not to be blamed).

dave:
It's the internet connection...unreliable and not much we can do about that, unfortunately.

rnzoli:
I resurrect this topic, because we are still experiencing the problem and we discovered something unknown before.

Up to now, I was under the impression, that the audio archive is trunkated because of the internet connection cutting out during the 30 minute archive period.
So I was asssuming that the only problem is that the file is shorter, nothing else.

However recently I realized that the short archive file has a corrupted sequence of audio as welll
In the file LHBP-Twr-Mar-22-2018-1130Z.mp3, the archive file is only about 12 minutes long.
But it's not the only problem.
It  starts with conversations taking place around 11:45 and the first 3 minutes in the archive are actually happening AFTER what is stored from 11:05 Z.
So the archive file is messed up from audio sequence point of view, a later portion overwrites earlier portions!

If you are interested in pursuing a solution to this, I will connect an audio time stamp input to the feed for 30 minutes, so we can verify exatly how what gets recorded in 30 minutes, and exactly what is overwriting what part in the archive file.

I realized this problem when listening to a go-around from NAX 1550. Surprisingly, NAX signs into the ATC saying "hello again", and only then it goes around. This got me suspicious, and found that all conversations in the beginning of the file actually took place AFTER what was recorded at the end of the file. 

Navigation

[0] Message Index

[#] Next page