gopro / labs

GoPro Labs
Apache License 2.0
474 stars 39 forks source link

Change to soft restart possible? ("!timeOR" Action command causes WiFi credential issues) #495

Open VProdAustria opened 1 year ago

VProdAustria commented 1 year ago

Model: Hero 11 Black (latest v2.12.70 Labs-FW) Issue: "!timeOR" action command leads to "hard" shutdown + restart of the camera (causes WiFi credentials to get lost)

Details: The "!timeOR" action command does not make a soft shudown + restart - It just cuts off power (seems like so). Causes: Recordings need to get "repaired" for example (if you do not stop it first in the code line). Therefor its not a normal shutdown + restart. Possible solution: Add an additional "soft" variant with normal shutdown + restart (or change the "!timeOR" action command to make a soft restart).

Main issue though: Tested it multiple times with about 60 seconds inbetween restarts -> After about 30 times restart with that solution (up to 35) the WiFi credentials get lost. But it can also happen after a few times using it if you try to reconnect the next day (with no battery in the camera over night) - Normaly the credentials are saved for at least a few days without battery.

Issue causes: Reset of name of camera, reset of the band selection (2.4 ghz gets reset to 5 ghz) and the initial QUIK app initialisation is gone which is needed to be able to stream over WiFi. The app symbol on the screen is then also crossed out again. Problem being - As there is no option to re-initialise the connection (and set the credentials over a code snipplet / the QR code), you have to do it manually at the camera again (over the smartphone app).

Command location: https://gopro.github.io/labs/control/actions/ "!timeOR - shutdown and restart the camera."

dnewman-gpsw commented 1 year ago

I'm not able to reproduce this issue.

!MBOOT="!Lbt"!SAVEbt=oW1!W!GMC!15E!1OR

The above is the command I ran. This livestreamed to Twitch for 15s then reboot continuously. I did this without battery, but it seems I need to let the coin cell drain about 24 hours to see this occurs tomorrow.

VProdAustria commented 1 year ago

Thx for the fast reply. My last version of the test-string / code: !MBOOT="!Lboot"!SAVEboot=oW1mVr1080!W!GLC!60N!E!4OR (That variant fails after about 30 to 35 restarts -> Externally powered / no internal battery.)

Thats my "workaround-try" to overcome the issue in: https://github.com/gopro/labs/issues/494 (As its resetting then the whole camera after each hour with 3600 instead of 60 seconds - including the WiFi module and restarts the streaming.) Sadly its failing then at the QUIK app sync / loosing the credentials as described above.

Btw. also set: WAKE=2, BYPS, BITR=5, 64BT=2500

dnewman-gpsw commented 1 year ago

Why no internal battery? I'm also testing that way to match your setup, but is that necessary for you? You can have both. Still no failure here.

VProdAustria commented 1 year ago

The point is: The setup ran over the last weeks test wise with an external battery bank hanging waterproof on fences (tennis court for live + REC purporses). Point being: If the internal battery is in use and fully charged, it can happen, that the charging stops, the camera stops pulling power (= battery bank switches off) and it is then running only on the internal battery until its dead. I have to test it again in that constellation with a new type of battery bank which hopefully reacts differently / switches off later / keeps power even at lower loads on the USB ports. But if the internal battery is full and the streaming is not starting, the power banks I use actually switch off.

Btw.: No internal battery means also less heat stress on the camera (and no heat stress for the internal battery as its gone). I am not 100% sure now as I tested that much different setups / implementations lately - But I think I also tested it already with an internal battery. I think it also happened with the internal battery in use + external USB Power AC/DC adapter (so not even using an external battery which could switch off unwanted).

Thx for your help. Have a nice day. LG

dnewman-gpsw commented 1 year ago

Yes, you need an always on external battery like this https://www.amazon.com/Voltaic-Systems-Always-External-Battery/dp/B084BPSFKH

dnewman-gpsw commented 1 year ago

The reason to use the battery, it helps distribute thermal load, and it will not be heat source under external power. The battery is better at keep the RTC coin cell charged. I'm not sure if it is also used to keep credentials stored.

I've approach 60 restarts LS without an issue.

VProdAustria commented 1 year ago

Thx for the hint and the link to the power bank. Will try a new one soon (with way longer 30 seconds time limit until it switches off). Btw.: Yes - The internal battery seems to save aka "keep up" the WiFi credentials too (regarding the QUIK app connection). Lost them too for example after having the 2nd testing camera lying on my table for a few days without battery - But never lost them before after a few hours / after a certain amount of restarts (30 up to 35 in my case). Would it be possible to re-initialise the QUIK app connection over a code snipplet (or to save and re-load them automatically from the SD card in any way)? Its also pretty annoying to re-initialise the GoPro each time after it just layed around a little bit.

Btw.: Did you test without an internal battery or with one? (The last mentioned 60 restarts)

dnewman-gpsw commented 1 year ago

I just completed 83 live-stream restarts without any issues, all without a battery. It had a battery in before this test started, so the coin cell was likely pretty charged. I'm closing this issue, as not related. We need to focus on the other. As for "save and re-load them automatically from the SD card in any way" this is outside of Labs, which doesn't touch any networking code directly.

VProdAustria commented 1 year ago

Battery does not help -> Tried to let the "oW1mVr1080!W!GLC!4N>r0!R16!1OR" code run - which you mentioned at https://github.com/gopro/labs/issues/494#issuecomment-1688948285 - That code also comes with the shutdown + restart at the end. Exactly same behaviour. Did not check this time the exact retry cycle / amount until its not working anymore - But it lost again all WiFi credentials after letting it loop for some time. Should not happen. You can also let it run a little longer if you want to confirm it - Tested now with three cams and its everywhere the same.

Again set: WAKE=2, BYPS, BITR=5, 64BT=2500 and the BOOT sequence to repeat the code after a restart.

Maybe its because of the "hard" shutdown? Its at least like a hard reset of the camera - As the camera is not beeping and showing that its shutting down at all. Thx again for your quick support / help. LG

dnewman-gpsw commented 1 year ago

I still can't get it to fail. Please send me two small LRVs, one that was captured before and one captured after the failure. I need to see the metadata, or you can extract metadata as send me that using https://gopro.github.io/labs/control/metadata/

VProdAustria commented 1 year ago

Sure no problem. I just have to restart the testing (as I only have a file AFTER the bug happens) -> Started the endless loop testing without any RECs before / with no active WiFi to test the looping. So I guess its not enough to evaluate it (if there is only a file after the issue happens). Will send you the files or metadata later - After the new test run with the 2.12.71 FW you sent me in 494.

dnewman-gpsw commented 1 year ago

I have been running continuously for three hours, with no issues, network discount or credentials, rebooting every minute. So it will only be your data I can use. Capture any file before, than once it happen, capture a file again. Any metadata differences will be what I'm looking for.

VProdAustria commented 1 year ago

So. Did a bunch of (time consuming) testing. Could not reproduce the behaviour again after I made a connections reset in the menu and re-syncing the QUIK app. I love such random issues / errors ^^. Btw.: I always tested with the battery inside and always let it run over 6 to 8 hours with the same code which caused the last issue: "oW1mVr1080!W!GLC!4N>r0!R16!1OR"

BUT: I have the extracted metadata from AFTER the last fail (older FMWR H22.01.02.12.70 with WAKE=0) and I made one extraction of the metadata BEFORE the next long restarting session which never failed (with the newer FMWR H22.01.02.12.71 with WAKE=2 as only difference in settings I changed due to testing purposes). RECs of both files triggered manually btw. (not part of streaming + REC function / routine).

AFTER the last fail:

DEVC DVID 1 DVNM Global Settings VERS 8, 2, 2 FMWR H22.01.02.12.70 LINF LSU2091901401040 CINF 167, 199, 60, 171, 207, 194, 36, 236, 89, 253, 99, 169, 85, 241, 21, 140 CASN C3471327037443 MINF HERO11 Black MUID 2872887207, 3961832143, 2841902425, 2350248277, 0, 0, 0, 0 CMOD 12 MTYP 0 OREN U DZOM Y DZST 0 SMTR N PRTN Y PTWB AUTO PTSH MED PTCL NATURAL EXPT AUTO PIMX 1600 PIMN 100 PTEV 0.0 RATE .empty. SROT 5.0000 EISE Y EISA HS EIS HCTL Off AUPT N APTO OFF AUDO AUTO BROD .empty. BRID 0 PVUL F PRJT GPRO SOFF 0 CLKS 2 CDAT 0x0000000064E62274 SCTM 0 PRNA 1 PRNU 0 SCAP N CDTM 0 DUST NO_LIMIT VRES 1920, 1080 VFPS 25000, 1000 HSGT OFF BITR HIGH MMOD STEREO RAMP .empty. TZON 120 CLKC 0 DZMX 2.0000 CTRL Pro PWPR PERFORMANCE ORDP Y CLDP Y PIMD MANUAL DEVC DVID FOVL DVNM Large FOV ABSC 0.0000 ZFOV 123.6023 VFOV W MXCF x1 MAPX 1.0000 MYCF y1 MAPY 1.0000 PYCF r0r1r2r3r4r5r6 POLY 0.0000, 1.8151, 0.1059, -0.6547, 0.3502, -0.0000, 0.0000 ZMPL 0.6314 ARUW 1.7778 ARWA 1.7778 DEVC DVID USRM DVNM User Metadata STRM EMPT 1 WAKE 0 BYPS 1 BITR 5 64BT 2500 BOOT !Lboot USRD DEVC DVID HLMT DVNM Highlights

BEFORE the next testing session: (Which sadly never failed again to have metadata out of the same session.)

DEVC DVID 1 DVNM Global Settings VERS 8, 2, 2 FMWR H22.01.02.12.71 LINF LSU2091901401040 CINF 167, 199, 60, 171, 207, 194, 36, 236, 89, 253, 99, 169, 85, 241, 21, 140 CASN C3471327037443 MINF HERO11 Black MUID 2872887207, 3961832143, 2841902425, 2350248277, 0, 0, 0, 0 CMOD 12 MTYP 0 OREN U DZOM Y DZST 0 SMTR N PRTN Y PTWB AUTO PTSH MED PTCL NATURAL EXPT AUTO PIMX 1600 PIMN 100 PTEV 0.0 RATE .empty. SROT 5.0000 EISE Y EISA HS EIS HCTL Off AUPT N APTO OFF AUDO AUTO BROD .empty. BRID 0 PVUL F PRJT GPRO SOFF 0 CLKS 2 CDAT 0x0000000064E6731B SCTM 0 PRNA 1 PRNU 0 SCAP N CDTM 0 DUST NO_LIMIT VRES 1920, 1080 VFPS 25000, 1000 HSGT OFF BITR HIGH MMOD STEREO RAMP .empty. TZON 120 CLKC 0 DZMX 2.0000 CTRL Pro PWPR PERFORMANCE ORDP Y CLDP Y PIMD MANUAL DEVC DVID FOVL DVNM Large FOV ABSC 0.0000 ZFOV 123.6023 VFOV W MXCF x1 MAPX 1.0000 MYCF y1 MAPY 1.0000 PYCF r0r1r2r3r4r5r6 POLY 0.0000, 1.8151, 0.1059, -0.6547, 0.3502, -0.0000, 0.0000 ZMPL 0.6314 ARUW 1.7778 ARWA 1.7778 DEVC DVID USRM DVNM User Metadata STRM EMPT 1 WAKE 2 BYPS 1 BITR 5 64BT 2500 BOOT !Lboot USRD DEVC DVID HLMT DVNM Highlights

dnewman-gpsw commented 1 year ago

This tells me that Labs metadata was not lost, so whatever was lost was elsewhere in the camera. Hopefully with build 71 you can avoid the scenario with very limited resets (only when needed.)

VProdAustria commented 1 year ago

Thx for the infos and fast reply! Well - To be honest: I hope for a more stable system / WiFi in the upcoming model 12 (should come out soon). As actually its not looking that good to be able to overcome or work around the WiFi freezing issue of the model 11 in any way -> Check out my last (todays) reply in #494.

Btw.: Any plans or infos on how long it will take after the release of the new model, until a labs firmware will be out? Do not want to push / stress anybody - Just to have it in mind (for a new testing session). Would love to get it running (as small remote streaming systems and for the tennis court operation). LG

dnewman-gpsw commented 1 year ago

Labs firmware is typically with a week of any update, hardware or firmware.

VProdAustria commented 1 year ago

That´s great to hear. Thx.