rf_hackrf fifo read issue?

[BennettRand]

I believe related to this line:

hacktv/src/rf_fl2k.c

Line 77 in 3e28d97

if(rf->reader[rf->phase].prefill == NULL) fprintf(stderr, "U");

Frequently, when I'm trying to read a video stream from a network source, I get my console filled with the character "U" and each one seems to correspond to a signal dropout where the video and audio are interrupted, leading to a unpleasant viewing experience.

What is the underlying cause of this stderr printout? ("U" is quite inscrutable) Are there steps I can take to avoid or mitigate it?

Example

$ sudo hacktv -m m -f 67250000 -g 47 -s 13500000 -a rtmp://10.1.106.19/live
Video: 715x480 29.97 fps (full frame 858x525)
Sample rate: 13500000
libhackrf version: 2022.09.1 (0.7)
hackrf: Hardware Revision: r9
hackrf: Firmware Version: 2023.01.1
Opening 'rtmp://10.1.106.19/live'...
Input #0, flv, from 'rtmp://10.1.106.19/live':
  Metadata:
    |RtmpSampleAccess: true
    Server          : NGINX RTMP (github.com/arut/nginx-rtmp-module)
    displayWidth    : 1024
    displayHeight   : 768
    fps             : 30
    profile         :
    level           :
  Duration: 00:00:00.00, start: 2612.975000, bitrate: N/A
  Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 163 kb/s
  Stream #0:1: Video: h264 (High), yuv420p(progressive), 1024x768, 5120 kb/s, 30 fps, 30 tbr, 1k tbn
Using video stream 1.
Using audio stream 0.
UUUUUUUUUUUUUUUU

System Info

$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1
$ hacktv --version
hacktv 20250224-9319014
$ hackrf_info
hackrf_info version: git-71bc3940
libhackrf version: 2022.09.1 (0.7)
Found HackRF
Index: 0
Serial number: SERIALNUMBER
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x00614f5e
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
    HackRF One

[fsphil]

"U" indicates an underflow, when hacktv can't generate the video signal quickly enough to feed the device in real time. It's likely caused by the ffmpeg library taking longer to open and probe each file over the network.

You can try increasing this value to see if it helps:

hacktv/src/rf_fl2k.c

Line 29 in 3e28d97

#define BUFFERS 4

[BennettRand]

Updated to the latest commit, increased buffer to 16.
The latest version (Since a commit around March 21st 137d335) it can no longer seemingly handle the test screen without underflow:

$ hacktv --version
hacktv 20250517-3e28d97-dirty
$ sudo hacktv -m m -f 67250000 -g 47 -s 13500000 -a test
Video: 715x480 29.97 fps (full frame 858x525)
Sample rate: 13500000
libhackrf version: 2022.09.1 (0.7)
hackrf: Hardware Revision: r9
hackrf: Firmware Version: 2023.01.1
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU^CCaught signal 2

[BennettRand]

Reverting to 3fdbb5c has resolved the test pattern underflow, but it's unclear if increasing the buffer size improves anything.

$ sudo hacktv -m m -f 67250000 -g 47 -s 13500000 -a test
Video: 715x480 29.97 fps (full frame 858x525)
Sample rate: 13500000
libhackrf version: 2022.09.1 (0.7)
hackrf: Hardware Revision: r9
hackrf: Firmware Version: 2023.01.1
^CCaught signal 2

$ hacktv --version
hacktv 20250320-3fdbb5c-dirty

[fsphil]

Ah you're using a hackrf, not the FL2K. This is the line you need to change to increase the buffering:

hacktv/src/rf_hackrf.c

Line 540 in 3e28d97

r = rf->sample_rate * 2 * 4 / 10 / TRANSFER_BUFFER_SIZE;

Try increasing the 4.