Posts by Doc.Ex

  • Fushcai Converter detected, can take screenshots, but not found by Hyperion

    Hi,
    yesterday I got my new Fushicai grabber, since my stk1160 produces flickering when used with the latest hyperion and Openelec.
    Thats why I still use the old version of .bismarck, which still runs fine. But I want to use the new features of Hyperion so I got a new grabber.
    I plugged it in and Openelec recognised it. I can take screenshots, launch effects etc but there is no output from the grabber to the LEDs when I start hyperion. I also tried launching it manually. The process is running but there is no output to the leds from the grabber.


    Edit: Further testing showed: The fault is the latest Beta. It works using the stable version, however I also have a blue flicker from time to time. This does not happen with the old hyperion version that works with .bismarcks switcher script.


    Edit2: Might be a hardware problem afterall. The flickering started with the old hyperion as well.
    Since there is no flickering when using the internal framegrabber i am guessing the power supply is working properly.
    I flickers with both the stk1160 and the usbtv007, so usb grabber seems not to be the problem. I tested another generic hdmi2av converter that I replaced a while ago because of some flickering issues but the problem remains. I guess the only two options are: the second hdmi2av converter is broken (only lasted about half a year?) or my hdmi splitter is broken, although the output to the tv is perfectly fine. Another option could be cables, but I dont see what could be wrong with them. All decent amazon basic cables and I never had a problem with them. Did anyone of you have a similar problem?


    Btw @admins: since this kinda shifted off topic and into a hardware problem, maybe this belongs into the hardware support section. Feel free to push it over or tell me and I open a new thread





    If you need more, tell me. I would love to be able to get this running. The new colour calibration options are way better then trying to get it right with only gamma :p

  • V4L2: Add shutdown detection

    Shutting down the grabber definitely saves energy, although not much. But how does it recognise when new input comes in? I for example have my pi always on since it draws only insignificant power. Only the bluescreen prevents me from having hyperion run all the time. A remote control could solve this problem. but that requires user interaction. My perfectionism tells me such things should happen automatically :P

  • V4L2: Add shutdown detection

    That seems to be a nice way of resolving the issue. The "do something" could then be a constant stream of black to the leds. That way the leds stay off, even when theres interference with other devices. (for example, the first 5 leds light up when i turn off my amp)
    And since hyperion keeps processing incoming data it recognises when the there is new input and "reactivates"

  • Hyperion-lirc

    Quote from Brindosch

    I like the idea, but i am not sure if this may better placed in a Kodi addon (This is no solution for non kodi users i know) which sends the execution you like via json.
    If i have a look at the overall download statistics, not sure if the usecase is really (often)given inside hyperiond.


    OT: It is time to restructure Hyperion to split it up between extensions and core. To get as much extension as possible without to bloat up the core more and more :)


    Well, for everyone that uses hyperion with multiple hdmi sources and runs kodi for example on a htpc, this could be useful. Also this way you can launch effects without running kodi, for ambient lighting purposes. That is the main reason I still run kodi on my pi, since it handles the keypresses and launches hyperion or effects etc.

  • HyperCon - Select config to start with

    Alright, I am curious about how this will come together. I love how the development of hyperion started to boost up again. If we continue this way, it will be the best opensource all in one ambilight software there is. If it isnt already :P
    I will try to give constructional feedback and suggestions on certain topics. Can't really do much more than that, since I am no programmer and my capabilities are limited to simple bash scripts :D But I am a suitable tester and Lead-User I guess :P


    Cheers for all your efforts!

  • Unable to Configure Multiple Devices

    That I don't know. But since the capture seems pretty smooth and only has a fixed delay because of so many processing devices in the signal chain, I guess v4l2 grabs in the same interval as the input signal comes in. The frame decimation parameter however can reduce that frequency, which is why I always set it to 1. Keep in mind that all Info I gathered is from trial and error and I don't have a clue how the code looks like behind it, since I am no programmer.


    Btw, the input lag for philips hue is because the hue hub cant handle many requests at once. So the update frequency for the hue lights need to be reduced. From my testing a frequency of 5Hz works pretty well. However It must be divided by the number of used bulbs. so for 2 Bulbs it is 2,5hz each. To compensate the lag, a high transition time works best, so it becomes a smooth ambient lighting, rather than a hectic delayed distraction.

  • HyperCon - Select config to start with

    My procedure so far is to configure them separately and once I am satisfied with the outcome I write a little bash script that starts hyperion with the configs. This script is then executed by Kodi when I press a button on my remote. That enables me to integrate it into activities on my Harmony remote hub.


    But in order to test and launch these separate configs, I set them up and copy them over using HyperCon, but then need to ssh into the Pi using the terminal and launch them manually. HyperCon enables me to start and stop hyperion, but it always starts with the default config. My wish would be to be able to tell HyperCon which config it should use to start Hyperion with. That way I wouldn't need to use the terminal.


    Also maybe a Wiki post with example bash commands for Hyperion would be useful.
    E.g. How to make a: Screenshot with v4l2, start hyperiond with x config, launch effect, set color, etc. I think there was something like that in the old wiki on github. I have not found something like that in the new wiki. Might be good for people that aren't that familiar with bash commands

  • Unable to Configure Multiple Devices

    Quote from Brindosch


    @redPanther
    OT: now i have a question. Capture interval of v4l2 is?
    This hue article talks about framegrabber. Might be ineteresting


    I don't know the possibilities of v4l2, but the generic USB grabbers grab with 30hz NTSC or 25hz PAL. So a higher capture rate than that would be useless. However with smoothing enabled, a higher output rate can be beneficial.

  • HyperCon - Select config to start with

    Hi everybody,


    last night I set up a new OpenElec image with hyperion and I am impressed with the new features HyperCon has to offer. One thing kinda bothered me though.
    I am using philips hue and a lpd8806 strip. So in order to differentiate I name my configs: "hyperion.config_lpd8806.json" and "hyperion.config_philipshue.json".
    I like the feature to remotely start and stop hyperion through HyperCon without using the terminal. However, HyperCon only starts the autostart.sh script, which starts hyperion with the standard hyperion.config.json


    I would be nice if HyperCon scans the available configs in the config directory of OpenElec and asks which config should be used to start hyperion with.


    For that matter, maybe a dedicated syntax for naming multiple configs should be introduced.
    Suggestions: "hyperion.config.device.json" or like I use to do it "hyperion.config_device.json"


    Cheers,
    Doc.Ex

  • Sk6812 rgbw support

    I am also interested with the potential difference.
    I currently use the lpd8806 and I am not quite satisfied with the performance and colour accuracy in dark scenes. Tried everything with calibration, but it seems the thresholds of the leds or the possible brightness steps aren't good enough. Maybe the APA102 would perform better because of the 8bit pwm resolution instead of 7-bit of the lpd8806.


    However, maybe the colour accuracy is better with rbgw anyway. This video is very promising:

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

  • Windows Grabber

    Well technically it doesn't have to be a slave. Right now the pi gets the grabbed videostream via a USB connection from the usb-grabber. If it would be possible to have a screengrabber that grabs the display output directly in windows and pushing it out via USB all the splitter/converter/grabber peripherals would become obsolete and you would have a digitally grabbed signal which should be more accurate in colour and resolution compared to analog. However I don't know if this is possible at all. I guess the Windows grabber program would need to register as a grabbing device via that specific usb connection on a specific usb port of the windows pc in order to get recognised by OS of the Pi. But again, this is all hypothetically as I am not a developer and only have rudimentary knowledge of software programming.


    To have a windows port of hyperion would be very nice. Preferably with the support to use an arduino to control the leds. This way everything, given that the windows grabber works, can be grabbed digitally, processed directly on the machine and then pushed out to the LED devices, e.g. light strip, philips hue, etc.
    That would mean very low latency, except for an arduino to control the leds no additional hardware and more accurate colours.


    Disadvantage is that this would only work for the PC as a source. At least for me this wouldn't matter since it is the only source I use, now that I have Gaming/HTPC.

  • Windows Grabber

    Sounds interesting, will try it within the next days.
    However I already see a problem. This grabber sends the captured information via network to hyperion, this means, depending on your network configuration, the ambilight will have a very noticeable lag.
    At the moment I am using the AVR -> splitter+converter+usb-grabber -> RPi method and also have a lag, although very little and thus tolerable. But nothing compared to when the content is grabbed directly on the Raspberry Pi.


    So my question is, would it be possible to develop a grabber that sends the information via a usb interface instead of via network? I reckon that would be a lot faster. Please bear in mind that I am by no means a developer and can not estimate realisability or required effort.


    Another solution would be to run hyperion directly on windows and send the information for the lights to the Pi via usb which only converts them to the SPI interface.
    I know something like this is possible with an arduino, however i then would not have philips hue support and would need additional hardware. That is why I like Hyperion.


    Anyway, what do you think, does this use-case make sense and does it have potential to be looked into?


    Cheers for all the work you and everyone who participated in the hyperion project has done and are doing. I am really happy to see it become more professional and am excited to see where this goes.