Problem with one of my Remotes - syslog always starts with "soliciting.."

[Jayl]

Hi -

I apologize for the long and detailed post - I am trying to supply as much "debug" info as possible..

I recently successfully upgraded to the following master version - which solved(Yay!) the problem of being able to upload large video files (>2GB).

FPP Version:	7.x-master-42-g5be13914
Platform:	Raspberry Pi (Pi 3 Model A+)
FPP OS Build:	v2022-11

I now have a problem that is unique to one of my 8 remotes - all other running with no issue.

I find that after several hours, one just stops responding, stuck at some random time within the video.

I did some crude debugging via the syslog log file, and noticed that as soon as I start the playlist, this failing FPP writes Soliciting pool server 2606:4700:f1::1,
Later on - if I let the system run, it will continuously solicit the NTP servers, and later will get stuck.

It appears as if it has trouble accessing the NTP Server? This log behavior is unique to this one system.

In fact, even in idle state, after a reboot, it continues to output:
Mar 29 07:25:01 FPP09 CRON[6570]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 29 07:25:47 FPP09 ntpd[1021]: Soliciting pool server 2606:4700:f1::123
Mar 29 07:26:52 FPP09 ntpd[1021]: Soliciting pool server 2606:4700:f1::1
Mar 29 07:27:56 FPP09 ntpd[1021]: Soliciting pool server 2606:4700:f1::1

I did a power-on reboot to this FPP, the log starts with the default date of Sept 13 and then the first lines after the date/time changes to the current date show an error:
Mar 29 07:42:06 FPP09 ntpd[1056]: receive: Unexpected origin timestamp 0xe6ca626a.a5110872 does not match aorg 0000000000.00000000 from server@162.159.200.123 xmt 0xe7ce401e.12ff7c59
Mar 29 07:42:06 FPP09 systemd[1]: Starting Clean php session files...
Mar 29 07:42:06 FPP09 systemd[1]: Starting exim4-base housekeeping...

Any ideas?

Thanks,
Jay

p.s.
I performed another test - I switched the Flash between two RP's - and now the NTP problem appears in both. I am now thinking that the program does not deal well with switching flashes - I am thinking that the code is tightly coupled to the specific H/W once it is initialized for the first time.

p.p.s
I performed a complete power-on reset to all systems, and found that my master was not set to the correct time zone (was that an issue?). I fixed that, and did a another power on reset to all systems, and now ALL systems do an NTP instruction every minute.. So, I may be barking up the wrong tree??

Mar 29 09:37:43 FPP01 ntpd[1031]: Soliciting pool server 2606:4700:f1::1
Mar 29 09:38:47 FPP01 ntpd[1031]: Soliciting pool server 2606:4700:f1::123

[Jayl]

OK - for what it's worth, I think I found a solution (or the correct approach) to the random failing of one or two of my remotes after several hours - so far never less than 10 hours until first failure.

Once I set up my system after a fresh power restart to all RP's, all failures were of the same type: 
Apr 1 04:36:31 FPP08 fppd[1638]: mmal: mmal_port_event_get: vc.ril.video_decode(1:0) port 0x659e13e0, no event buffer left for ERRO

Basically, appearing to be a memory allocation of some sort, after a very long (but random) time, so all my previous bug hunting was probably useless.

I decided to finally use the scheduler mechanism, which is probably the "default" way to use the system. I set up a schedule to repeat my 16 min playlist once every 20 minutes, and So far the system is acting well, and also starting a fresh log at midnight, rather than continuously growing it for ever (as was the case when I looped the playlist without the scheduler).