Roger D

Five years later and I'm having the same issue (on Armbian). The ping trick seems to be the best fix.

Thanks, haven't yet (I'm using the Armbian default with kernel 4.14) but I will. I've been trying power management hacks (`rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1`) but they don't work. What's the difference...

Testing now, working good so far and seems faster. BTW dmesg gives `RTW: rtl8188eu v5.2.2.4_25483.20171222` -- is that correct for the latest version?

@mpromonet much of this code looks like it could be added as-is. What do you think?

Thanks, tried that and got this: ```bash #./h264grabber -m yi_home -r HIGH -d -f --buf_size 3110752 --table_record_num 500 --stream_offset 96160 --table_offset 16 Debug on Using fifo as output Resolution high...

That works, thanks! Things are in black and white, but I suspect there's an IR-cut filter issue. FYI tested low with: ``` ./h264grabber -m yi_home -r HIGH -d -f --buf_size...

Makes sense, thanks. > The record starts with "[01 01 00 00]”… That part I didn’t realize. I was looking for “[00 00 01]”. I assume there’s audio data in...

I checked the v5 rtsp server and I don't see any audio support? Also I noticed that when using the new parameters you found with the high stream, after a...

Do you think one of the offsets needs adjusting? I’m wondering if the grabber needs to restart searching for the latest record when it gets repeatedly stuck on a frame.

Seems like it circulates correctly multiple times before it eventually gets stuck. Recording a logfile now, will send when it fails. [Here's an example](https://github.com/roger-/yi-hack-v5/commit/8a3864beeb220dc91a7a30cee6eb75fe4db8b302) of what I mean about changing...