Posts by Doc.Ex

1) Keine Ahnung
2) Ja geht mit der Hyperion Remote App
3) Denon AVR 1713: geht definitiv nicht

Das klingt höchst merkwürdig. Eventuell, hilft es wenn du nochmal genau deinen Aufbau schilderst.
Edit: So große Strahlungen, dass Fehler im laufenden Betrieb auftreten, wären sehr ungewöhnlich.

Damit ist gemeint in wie viele Randflächen das Bild in horizontaler und vertikaler Richtung eingeteilt wird. Innerhalb dieser Flächen wird dann die Durchschnittsfarbe bestimmt. So habe ich es zumindest verstanden, ohne den Code zu kennen. Wie der Algorithmus mit anderen als den Defaultwerten zurecht kommt habe ich nie getestet.

Bei 64x64 kannst du bereits 256 LEDs individuell mit einer Farbe versorgen. Präzisere Farben durch eine höhere Auflösung sind fallen eher marginal aus. Daher lohnt sich eine höhere Auflösung nur bei mehr als 256 LEDs, um zu vermeiden dass 2 oder mehr LEDs die selbe Farbinformation erhalten.

2 things might cause this problem:

1. when you select NTSC, check if the HDMI2AV converter is also on NTSC, on some converters the labelling is false and is switched.
2. Take a screenshot with the grabber and check the output. If it looks alright (ignore green stripes across the picture), but has a black border, adjust the crop settings until the black bars around the picture are gone.

Bevor du irgendwelche Abschirmmaßnahmen ergreifst würde ich es erst einmal an einem smog-technisch weniger belastenden Ort testen. Bei mir herrschen auch eine Menge elektro-magnetischer Felder durch AVR etc und die machen sich nur durch gelegentliches angehen der LEDs bemerkbar, wenn der Pi bzw. Hyperion aus ist. Im laufenden Betrieb sollte das eigentlich kaum bemerkbar sein, da die LEDs so häufig aktualisiert werden, das Störstrahlung einfach untergeht.

Haben Pi und LEDs die gleiche Masse? Wenn das nicht der Fall ist GND vom Pi und LED verbinden.

I used to have 40 ms smoothing (without delay), that worked fine for me. But I never tried how low you can go. 0ms doesn't really work, that I tried.

Anyway, 40ms is 25Hz so for PAL input this shouldn't make a huge difference, except that it also smoothes out colour misinterpretations, which is the main reason why I had it enabled.

// V4L2 GRABBER CONFIG
    "grabber-v4l2" :
    {
        "device" : "/dev/video0",
        "input" : 0,
        "standard" : "NTSC",
        "width" : 240,
        "height" : 160,
        "frameDecimation" : 2,
        "sizeDecimation" : 1,
        "priority" : 900,
        "mode" : "2D",
        "cropLeft" : 0,
        "cropRight" : 0,
        "cropTop" : 0,
        "cropBottom" : 0,
        "redSignalThreshold" : 0.0,
        "greenSignalThreshold" : 0.0,
        "blueSignalThreshold" : 0.0
    },

Try these settings. OpenELEC supports framescaling for the stk1160, so you can directly determine the grabbed resolution. That reduces load on the usb bus and should get rid of the frame too small errors.

Smoothing offers a delay option, you could try that. If you don't like the smoothing effect, just pick a low smoothing time and you won't really notice it.

It doesn't matter what brand or quality your receiver is. As redPanther said, the only way to solve that is to use shielded data cables or increase the distance of the data cables from the avr and other unshielded cables.

After using the windows grabber a lot the past weeks I must say I really like how accurate the colours are.
But some things bother me:

• It causes a lot of CPU load. About 12% on an i5 6600K.
• It doesn't work on some games and just produces white (Rocket League DX9)
• On Ark - Survival Evolved (DX11 I think) it works but causes stuttering. The game is still rendered with 30+ fps but the display output is maybe half of that.
• It doesn't support scaling in Windows 10

Following features would really benefit the experience and usability:

• lower cpu usage/more efficient display capturing
• Scaling support
• automatic disabling when screen can't be captured (this way a physical usb grabber can be used as fallback)
• Hot-Key to enable/disable, maybe the possibility to exclude programs from being captured

Otherwise I really like it. Its faster than the bulky adapter-usbgrabber-chain and has really great colour reproduction. Its just not perfect yet.

My guess is that this behaviour is caused by electro magnetic interference. My first 2 LEDs also light up when Hyperion is off. Mostly when I switch off my AVR. In the moment of switching it off the relais release the voltage on the condensors, so there is an electro magnetic field around the avr for a short time. Since the LEDs are near the avr, the field might cause a false signal in controller chip of the LEDs and thus the LEDs light up. Because there is no new signal from hyperion the LEDs hold the last signal which is why the LEDs keep lit. A greater distance between the LEDs and for example avrs and shielded cables to the LEDs could help. This at least is my theory, didn't test it.

Try to lower the smoothing time. I personally use 80 ms.

I think @RanzQ was working on a functionality like that. See here: https://github.com/RanzQ/hyperion-audio-effects
But I never tried it, because I use Windows 10. But maybe a Audio-Stream functionality could be incorporated with the windows grabber in the future. This way the the audio-effects could collaborate with the win grabber. @Rick164 : Do you think this is a viable point on the roadmap for the win grabber? I personally don't really need it, because with windows you can use the visualisations and that works pretty nice with the ambilight.

I did also use bismarcks script. My solution was, that I just wrote simple bash scripts that I mapped onto remote buttons. The scripts stop hyperion or start different configs. Was the best solution for me because I could incorporate the buttons with my logitech harmony activities which makes it just as convenient as the script of bismarck. Maybe that could also be a Solution for you

Libre- und OpenELEC brauchen kein sudo, da der User dort automatisch root ist. Am einfachsten beendet man alle Hyperion Prozesse mit:

killall hyperiond

Zu deinem Problem: Der grabber scheint, aus welchem Grund auch immer, von irgendwas angesprochen zu werden. Hyperion kann deswegen nicht starten, da immer nur ein Prozess auf den grabber zugreifen kann. Kenne mich auch nicht direkt mit LibreELEC aus, aber benutze OpenELEC und ich gehe mal davon aus, dass die Unterschiede bis jetzt relativ gering sind. Daher wäre meine Vermutung, dass sich dein grabber aufgehangen hat. Ich hatte ein ähnliches Problem, bei dem selbst ein Neustart des Pi nichts brachte. Letztendlich lag es daran, dass sich der grabber aufgehangen hatte und da er an einem USB Hub mit Stromversorgung hängt, komplett unabhängig vom Pi war. Einmal ausstecken, warten bis sich die Kondensatoren leeren (Led geht aus) und wieder einstecken und alles war wie es sollte.

Scaling must cause the issue. It works on my TV when I set the scaling to 100%. Was 125% percent before. I don't know how the scaling works in windows 10 but is it possible to support scaling while grabbing? Because now I can't read anything
But at least it works, so I have got that going for me which is nice

Also, a Hotkey to toggle the grabber on/off would be nice.

I do use scaling when on tv, so maybe that causes the problem. Will turn that off and test tomorrow

Maybe it has something to do with the tv. I only get the error for my tv as well. The tv is connected to an avr which is connected to the pc.
But my tv outputs 60hz.
Couldnt try the new version but will when i am home tomorrow evening. Can provide a debug log then, too.