could you post both hyperion logs with this config? one with the old hyperiond and one with my hyperiond? I really want to know what is going on now.
This is no problem, We still had no real feedback to the wetek devices or any other amlogic device, so no idea what is working here or not.
Hyperion, Arduino and Wetek Core
- Remus
- Erledigt
-
-
The new boblightd
[MEDIA=pastebin]xcdY5qak[/MEDIA]The old(original) boblightd
[MEDIA=pastebin]0RF7ZAna[/MEDIA] -
thank you!
This is strange, the log says nothing about the amlogic grabber that is working for you now. hm
You are 100% sure that the duplicated entry changed it? -
thank you!
This is strange, the log says nothing about the amlogic grabber that is working for you now. hm
You are 100% sure that the duplicated entry changed it?
I will double check! I will remove those lines and get back to you. -
Nope. It doesn't work without those added lines.
-
Yeah, great that it solves this for you, on the other hand sad that you need that strange workaround and the log indicates nothing here.
Thank you for your help, we will note it. -
One question, did you tried again with LibreELEC? I am really interested, if they just pushed a RPi build.
Thank you -
I recommend to delete the framegrabber section in config when using aml grabber, because then you have 2 active screen grabbers on the same host -> can lead to unwanted effects
the "framegrabber" stands for one of this grabbers
- "dispmanx" (raspi/broadcom videocore)
- osx
- framebuffer (linux without x11)which one depends on how you compile hyperion.
some "nice" config facts:
instead of "framegrabber" you can also write "osxgrabber" when you use it on osx.
on linux you can replace the section name "framegrabber" with "framebuffergrabber" when you intend to use the framebuffer grabber.BTW adding the amlgrabber section for amlogic devices is no workaround.
-
I am not happy about the current "non-linear" grabber solutions. which are working or not, or you need to call it external (x11)
I would prefer a clean way, but we need working grabbers for each section.@redPanther
of course 2 grabbers are bad, but it was the solution?
Hyperion don´t shown anything at the log, that 2 grabbers are started. -
hyperion show this:
ssh in: ERRROR: The dispmanx framegrabber can not be instantiated, because it has been left out from the build
ssh in: AMLOGICGRABBER INFO: [AmlogicGrabber::AmlogicGrabber(unsigned int, unsigned int)] constructed(160x160)
ssh in: BLACKBORDER INFO: threshold set to 0 (0)
ssh in: BLACKBORDER INFO: mode:default
ssh in: INFO: AMLOGIC grabber created and startedhyperion tries to start the dispmanx grabber (because of framegrabber section) and then amlogic grabber is clearly to see in the log
-
huh? then i missed something.
edit: no if you use framebuffer not? -
BTW clean way ... you can start every grabber as standalone version, no need for integrated one - this was one big thing in my "prio cleanup PR"
-
clean indeed, but comfortable?
Users (I) want to start hyperion and it should select what it needs
anything other is a support request here -
thats why we need a hyperion-launcher. that thing should take multiple configs and start multiple hyperions and the needed grabbers.
ok one thing we can do is to kick out all other grabber sections (including v4l2) and add a "type" in the framegrabber section. This will select the framegrabber. This is the way the device section work
-
multiple hyperions and the needed grabbers
a hyperion launcher,
all options available for all grabbers? Yeah!sounds very good
why are we waiting? -
For my taste a python app will be the best. From there I can read json files and control the apps. communication with hyperiond's can be stablished through jsonserver. Because it's python no compilation is needed and this can be platform independend.
If this works, we can delete lots of c++ code in hyperion
-
sounds like a good plan thanks guys..
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!