Recent Posts

Pages: 1 [2] 3 4 ... 10
11
BeagleBone Black Controllers / Re: New "beta" 9.2 based image
« Last post by JonB256 on Today at 05:45:11 AM »
On the FPP Settings / Advanced page, there are three options at the bottom.

One is to Grow the partition out to full size

One is to move the OS to eMMC

One is to move the OS to eMMC but use BTRFS formatting (definitely labeled as experimental)

The first option (grow), I'm assuming is for people who will leave eMMC untouched and want to run FPP strictly from the uSD card. By expanding the partition, doesn't it make the uSD card unusable for installation on another BBB / BBG ?  (I mention this because someone complained to me that he could not reuse his image) If this option does make the install uSD unusable for a second or third install, consider adding a note to that effect.

The second option hasn't changed in awhile. It does a pretty standard install to eMMC then shuts down, remove the installation uSD and insert either a new uSD card or flash drive for storage.

The last option is interesting and I'm trying it on a new BBG. Will let you know.

12
Falcon Player (FPP) / Re: Networking Questions.........
« Last post by mangoat on Today at 02:23:01 AM »
thanks, works a treat :)
13
gotcha.
It isn't doing a lot with the FPP code, but it is playing video all the time, so maybe that's taxing it? 
Ya know, i don't remember which pi hardware version i actually have in there.  it may actually be a B+.  How can i query which one it is?

...

Revision   : 0010

Looks like it's a B+ based on the hardware revision.  That should also show up in the UI, the Raspberry Pi Logo should indicate which model it is if you are running v1.9 or v1.10.

So that is odd.  Video shouldn't tax the system enough to cause fppd to die unless it is the video itself that is causing the issue.  Can you look at the /var/log/syslog and /var/log/messages files in the FPP Logs tab the next time this happens.  I doubt it, but maybe fppd is being killed by the OOM (Out Of Memory) killer process.

14
Falcon Player (FPP) / Re: MQTT Topics
« Last post by CaptainMurdoch on December 14, 2017, 11:47:18 PM »
I think that ideas sounds better and better.  At first, we were hesitant to add something like that, but I think that having the watcher process has more benefits now and it isn't going to stop us from looking into issues that might cause fppd to die.

Adding this one to my notes.
15
Falcon Player (FPP) / Re: Scheduler showing (-39764 seconds away)
« Last post by CaptainMurdoch on December 14, 2017, 11:42:46 PM »
If you like, I'd be happy to test out any fixes next week and provide logs/feedback/etc.

The patch is in the master-v1.x branch for now.  I've switched over my systems here to running it and if it looks good, I can get it into v1.10 the next time I build binaries.  I may hold off on that for a few days to see if there are any other bug fixes related to fppd crashing.
16
Falcon Player (FPP) / Re: MQTT Topics
« Last post by jchuchla on December 14, 2017, 11:36:36 PM »
i don't think it really matters if it's all done within one process or split across two, so long as it's transparent on the communications side..  The fppdmonitor process sounds like it would be a multipurpose project solving both this need as well as the auto restart problem from the other thread.
17
Falcon Player (FPP) / Re: FPPD Stopping - Are there any logs to help troubleshoot
« Last post by jchuchla on December 14, 2017, 11:31:37 PM »
gotcha.
It isn't doing a lot with the FPP code, but it is playing video all the time, so maybe that's taxing it? 
Ya know, i don't remember which pi hardware version i actually have in there.  it may actually be a B+.  How can i query which one it is?

Here's the CPU Info
processor   : 0
model name   : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS   : 2.00
Features   : half thumb fastmult vfp edsp java tls
CPU implementer   : 0x41
CPU architecture: 7
CPU variant   : 0x0
CPU part   : 0xb76
CPU revision   : 7
Hardware   : BCM2708
Revision   : 0010
Serial      : 0000000025e9de0e
18
Your use case on this sign is fairly limited, bridge mode to events/scripts.
Oh, i don't know.  Have you ever looked at the prices of the pro "media servers" that will start a video from a dmx/sacn trigger?  I'd totally be using these in live events if i can prove out it's reliability in my yard first.

Sorry, bad choice of words on my part.  By "limited", I meant that you aren't exercising a lot of the FPP code, just simply receiving an E1.31 universe and acting on the control channels.  So there isn't a lot of places that things could go wrong and cause fppd to stop or lock up.  Those are also some of the oldest parts of code though, which haven't been touched in a long time, so I'm assuming this is probably some kind of multi-threaded issue that manifests itself more on the multi-core Pi's.
19
Falcon Player (FPP) / Re: MQTT Topics
« Last post by CaptainMurdoch on December 14, 2017, 11:16:23 PM »
I think we're in a chicken and egg scenario.  It probably wouldn't make sense to proxy everything through another server just to have start/stop ability.  It also would't make sense to use MQTT outbound but HTTP inbound.  We can easily have a /falcon/player/${HOSTNAME}/daemon/stop topic that triggers fppd to shutdown, so getting it started again is the real issue.  We could also have a corresponding shutdown topic to tell fppd to shutdown the Pi/BBB.   In theory, most people wanting to shutdown for a long time are going to shutdown the Pi itself and would need to power cycle to get it back up.  For those that just want to stop fppd, then I think that calling the following existing HTTP call (or new API call to replace this) to get fppd restarted would be OK:

http://fpp.local/fppxml.php?command=startFPPD

All that being said, I have tossed around the idea of having a very simple "fppd watcher" process.  The purpose of this process would be to make sure that fppd was running and responding.  This process could also easily listen to MQTT messages and stop/start/restart fppd.  If we tell the watcher to stop fppd, then it would suspend watching and not start it up again unless told.  This process could even spawn the main fppd process so it could be immediately restarted if it died.  That doesn't mean don't fix bugs, but it is there as a safeguard and relatively easy to implement.
20
Falcon Player (FPP) / Re: FPPD Stopping - Are there any logs to help troubleshoot
« Last post by jchuchla on December 14, 2017, 11:15:55 PM »
Your use case on this sign is fairly limited, bridge mode to events/scripts.
Oh, i don't know.  Have you ever looked at the prices of the pro "media servers" that will start a video from a dmx/sacn trigger?  I'd totally be using these in live events if i can prove out it's reliability in my yard first.
Pages: 1 [2] 3 4 ... 10
Back to top