Raspberry Pi 4 with Libreelec v19 / Kodi Matrix, no grabber is working

[DaPeace]

I am using the latest Testbuild from Milhouse from here https://forum.kodi.tv/showthread.php?tid=343068 I cant get the framebuffer-grabber nor anything else to work. I installed the alpha7 where the webif is not working and then i moved backwards in the releases till the webif was working. I ended up with alpha4. When i start hyperion_dispmanx i get the following error:

[hyperion-dispmanx DISPMANXGRABBER] <INFO> Display opened with resolution: 4x1053483292 [hyperion-dispmanx FLATBUFCONNECTION] <INFO> Connecting to Hyperion: 127.0.0.1:19400 [hyperion-dispmanx DISPMANXGRABBER] <ERROR> Snapshot failed: -1

I found some conversations here how to solve that but that did not help. I tried the fb-grabber too but there i get the right resolution but only a black picture on fb0.

Is there any solution on RPI4 to get the grabber running? I need hyperion to bypass the led-data via udp to a wled-esp8266.

Regards, DaPeace

[Paulchen-Panther]

Is there any solution on RPI4 to get the grabber running? I need hyperion to bypass the led-data via udp to a wled-esp8266.

No. Not yet. We must implement V4l2/GBM to grab the screen on Kodi 19. Alternative you can downgrade to a not milhouse build. Or use another OS for Kodi.

[tefracky]

Hey, is there anything new on it? I tested it and it is still not working.

[accessone67]

Wold also like to use this in kodi 19 with libreelec. any updates? :/

[MPowed]

Any word on this?

[KrX3D]

im also interested if there is some progress made on this

[tefracky]

Will #1119 fix this?

[sansillusion]

I would also like to be able to get my hyperion to work again. It's the only thing not working at all tight now and it bugs me. My LEDs turn off when I play something and I dont want to disable hyperion has it serves as a reminder to check back on it once in a while in hope that someone had a breakthrough.

[rudihorn]

I've been spending a little time experimenting with the DRM apis to perform screen grabbing at https://github.com/rudihorn/drm-vc4-grabber with some progress. I have been able to show that it is definitely possible to write a grabber this way, but at the same time my knowledge of the Linux rendering system is limited and I am not entirely sure how to correctly take the image in its in-memory format and convert it into the true image (let alone how to ensure that the performance is sufficient, though the in memory reading bit should be reasonable given the shared memory architecture). I assume V4L2 may be helpful in doing the rest.

Unfortunately I won't have a huge amount of time to work on this, so would be happy if anyone wants to help out on this.

Also this seems to be related to #954.

(Also apologies if the project is a bit hacky, given I'm currently still just trying to figure things out. If there are any questions just ask)

[Paulchen-Panther]

Hi @rudihorn I will gladly have a look at your project. I have also worked a little with the DRM/GBM API but failed to convert the memory image. Maybe I am missing a crucial snippet that you have integrated in your project. I will let you know. Thanks for your time and work.

[rudihorn]

No worries. I suspect the last thing missing from my code was some de-interlacing for each 32x32 pixel square. The framebuffer uses a modifier with value 504403158265495553 (hex 0x700 0000 0000 0001) which seems to be driver specific. I have not quite yet found a reference to this.

[rudihorn]

So my grabber now at least copies a correct image. I still need to see if the performance is efficient enough though, and there is certainly some room for optimization. It might also be worth adding some domain specific code for downsizing the image. It should be possible to write some pretty efficient code for reducing the resolution by a factor of 4.

Edit: Rewrote it so it should be a little bit more efficient. Still not sure this is fast enough though.

[rudihorn]

I've done a little more work and the screen grabber can now connect to hyperion and upload the image. This seems to work, but revealed that video image buffers are uploaded into a different framebuffer. The current setup is that there is the CRTC with a framebuffer which is used for video, and then an extra plane containing the XBMC ui.

This is actually quite nice though, because when video is playing UI elements are not captured. Unfortunately this also means that the video buffer is in a different (and potentially many) different pixel formats. As it is not rendered though, it does not use the tiling format by the VC4. I've implemented YUV420, but I'm not sure how many other must implement formats there are. It probably suits most of my purposes though. For YUV420 it is possible to implement an efficient half resolution grabber which is nice.

@Paulchen-Panther I'm not entirely sure I understand the current concept of how registration is supposed to work, but it seems I need to repeatedly resend the registration message.

[chcore]

Thanks for your efforts rudihorn. You mentioned it not capturing UI elements while video is playing, which is indeed nice. But does this mean that things will not work when running other applications which don't play video? e.g Retroarch

[rudihorn]

@chcore best to just try it out. When it doesn't detect a video it does fall back to the ui framebuffer, so when displaying images for example it still works. If retroarch renders in some odd way more work may be necessary

[Chaphasilor]

@rudihorn talking about trying it out, which steps would be needed for that? From your readme I got that I have to compile your rust code to the platform-specific binary, and then it seems like I have to run that in the background and it "connects to hyperion"? Does that mean hyperion will auto-detect the new grabber or do I have to change some additional settings in hyperion?

[rudihorn]

Yeah just compile and run it. Hyperion starts a TCP socket that the image grabbers connect to, so no further configuration is necessary.

[chcore]

@chcore best to just try it out. When it doesn't detect a video it does fall back to the ui framebuffer, so when displaying images for example it still works. If retroarch renders in some odd way more work may be necessary

That's good to hear. Will test it tonight.

What are the chances of this working on x86 as well?

[emc02]

Is there any progress in libreelec 10 for internal frame grabber working? Will it ever work? Are the devs just waiting for final libreelec version?

[Johnny1982fd]

Alpha 10 is coming, but Kodi 19 / LE 10 will not work. PR#1119 wont fix this.

So, just hope for the next release.

[zyrill]

I just updated LibreELEC to 10 thinking PR 1119 would get things rolling again with my rpi4 so thanks for the infos, everybody... Now I at least know I shouldn't have. @rudihorn do I understand your post correctly that there's a workaround you built with that grabber of yours? I'm a bit lost as I don't understand the peculiars of the graphics system so I would appreciate some more guidance, if anybody had some time... Thanks!

[tefracky]

I just updated LibreELEC to 10 thinking PR 1119 would get things rolling again with my rpi4 so thanks for the infos, everybody... Now I at least know I shouldn't have. @rudihorn do I understand your post correctly that there's a workaround you built with that grabber of yours? I'm a bit lost as I don't understand the peculiars of the graphics system so I would appreciate some more guidance, if anybody had some time... Thanks!

Did I understand correctly, that the latest Libreelec nightly and Hyperion now working together? Did you used the Alpha-10 or did you compile by your own? Maybe you can share your compiled fine to make things easier for other people (me :D).

[zyrill]

I used the latest available releases. I don't see any commits after the alpha-10 that would change anything materially, so I don't think compiling a "nightly" from master helps. I also don't think that using a libreELEC nightly would help, as LE isn't broken. It's simply that hyperion-ng is lacking support for the current LE version.

If somebody knows better please chime in. Thanks!

[Paulchen-Panther]

@zyrill @tefracky We are still in the process of implementing the DRM grabber. Since the number of active devs (only 2) is limited, our time is also limited. You are all welcome to help. 😄

[rudihorn]

@zyrill the project can already be used for DRM capture on a raspi 2b+ and maybe a raspberry pi 3. I haven't been able to make it work on a raspberry pi 4 because I don't have access to one. Feel free to use that project as a starting point for getting it to work on a raspberry pi 4 though

[zyrill]

I'm well aware of how this usually works, which is why I formulated my posts a bit defensively. ;) I can't help developing presently, sadly. What I can do is sponsor an rpi4 for active devs, would that help, @rudihorn?

[tefracky]

For your information: Libreelec 10 and Alpha-9 is working, no update to Alpha-10 is necessary.

[Johnny1982fd]

How should this work with internal grabber ?

[tefracky]

You are right, I used the USB platform as grabber, which of course worked.

I also tried the Alpha-10 now, but it seems it doesn't work with the Framegrabber. @zyrill. Which version are you using and what is your configuration? Maybe you can share it to help us.

[zyrill]

you are mistaken @tefracky . I do NOT have a working setup - it's simply not supported yet and I don't have the time to do it myself. I'm waiting until somebody has (or I have, but that might be a few years).

[rudihorn]

Sorry for the late response @zyrill. I think at the moment it looks like I will be quite busy for the next few months, as I'm busy writing up my PhD thesis, so I doubt I will have time. This is also a bit of a risky venture, as what I have gathered so far the Pi 4 hardware graphics chip does some things slightly differently. Because of this gaining memory access to the buffer may be more difficult. I will have access to a Pi 4 at the end of this month though, and can see if I can at least diagnose the issue.

[zyrill]

Fully understand your position, @rudihorn and good luck with your defense!

[music-fan]

Is there any solution on RPI4 to get the grabber running? I need hyperion to bypass the led-data via udp to a wled-esp8266.

No. Not yet. We must implement V4l2/GBM to grab the screen on Kodi 19. Alternative you can downgrade to a not milhouse build. Or use another OS for Kodi.

Which OS you would recommend for RPi4 and Kodi (19)?

[top4ek]

Same issue on raspberry pi 3 with Kodi 19 on OSMC. I found something like workaround switching to vc4-fkms-v3d but HDMI CEC and audio isn't work in this case which is vital.

[rjousse18]

I just insalled Hyperion NG alpha 10 on my libreelec 10 (Rpi4). I tried to configure hyperion but i can't get colors on my yeelight bulb. I configured my bulbs but hyperion seems not work. I also set screen capture to "framebuffer". I have a 4k60 TV. What can I do ? (I'm a noob, I just discovered hyperion ng)

[emc02]

so there is no solution yet? that's very sad, because I think Pi4 and libreelec is a nice and often used combination... What's the workaround? External Grabber? Can someone recommend a good one?

[nmb1970]

Is there any solution on RPI4 to get the grabber running? I need hyperion to bypass the led-data via udp to a wled-esp8266.

No. Not yet. We must implement V4l2/GBM to grab the screen on Kodi 19. Alternative you can downgrade to a not milhouse build. Or use another OS for Kodi.

Which OS you would recommend for RPi4 and Kodi (19)?

Also looking for this. Only need kodi with pi4 so if librelec is broken, what to use? thanks.

[Johnny1982fd]

Nothing! External grabber isnt good enough (imho). I only use Librelec with internal grabber.

I hope so much, that something is coming and made a donation meanwhile for this great project.

Currently im using LE 9 with Hyperion Classic.

[MPowed]

I would love to help with this. it seems to me that hardware acceleration isn't exactly available for pi4 making it revert to ffmpeg. it does not use v4l2 like other pi's.

[emc02]

looks like nothing new here... sadly...

[tpmodding]

it is also sad, that no new user will/can help supporting the devs...so just be patient, sadly....

[Johnny1982fd]

I can only help with donations - which i had done in the past and will go on in future.

[louisnichols]

Hi all!

It seems like this issue is a handful and it requires an investment of time that the devs might not have. Unfortunately, it requires some quite specific knowledge that most of the users don't have, even if some would be willing to help..

So I've been thinking... would it be an idea to offer a bounty for solving this? We could try to look for a way to crowd fund it.

I don't know, this might be an idea, either crazy or stupid, or both. I can certainly already imagine a lot of challenges to putting it into practice. Like, I'm not even sure it is possible at all. In any case, I am willing to chip in for this and can volunteer some time to organize it.

I just thought I would submit it for debate. What do you think?

[sansillusion]

Given I don't have the skills necessary to fix it I would gladly make a donation towards a bounty.

[AlexanderStein]

Does anybody actually know what has to be done, e.g. what are the missing bits? I'm reading about V4L2 in some posts, but the demo code from https://github.com/hyperion-project/hyperion.ng/issues/983#issuecomment-855959829 accesses using DRM. I'm involved in V4L2 (and DRM to some extend) on i.MX platforms, so I got curious and was wondering what needs to be done actually.

[chcore]

Does anybody actually know what has to be done, e.g. what are the missing bits? I'm reading about V4L2 in some posts, but the demo code from #983 (comment) accesses using DRM. I'm involved in V4L2 (and DRM to some extend) on i.MX platforms, so I got curious and was wondering what needs to be done actually.

There was a progress update a few months ago here (in German though, so use Google Translate): https://hyperion-project.org/forum/index.php?thread/10463-install-hyperion-ng-on-libreelec-x86-64-rpi-inoffiziell-unofficially/&postID=43192#post43192

[MPowed]

V4l2, as far as I know, is not supported on pi4.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: chcore @.> Sent: Saturday, January 29, 2022 10:30:16 AM To: hyperion-project/hyperion.ng @.> Cc: Mitchel @.>; Comment @.> Subject: Re: [hyperion-project/hyperion.ng] Raspberry Pi 4 with Libreelec v19 / Kodi Matrix, no grabber is working (#983)

Does anybody actually know what has to be done, e.g. what are the missing bits? I'm reading about V4L2 in some posts, but the demo code from #983 (comment)https://github.com/hyperion-project/hyperion.ng/issues/983#issuecomment-855959829 accesses using DRM. I'm involved in V4L2 (and DRM to some extend) on i.MX platforms, so I got curious and was wondering what needs to be done actually.

There was a progress update a few months ago here (in German though, so use Google Translate): https://hyperion-project.org/forum/index.php?thread/10463-install-hyperion-ng-on-libreelec-x86-64-rpi-inoffiziell-unofficially/&postID=43192#post43192

— Reply to this email directly, view it on GitHubhttps://github.com/hyperion-project/hyperion.ng/issues/983#issuecomment-1024932362, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH7KBFAJM4MNEOTQH2EIZ63UYQBYRANCNFSM4QPCWLUQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>

[AlexanderStein]

Does anybody actually know what has to be done, e.g. what are the missing bits? I'm reading about V4L2 in some posts, but the demo code from #983 (comment) accesses using DRM. I'm involved in V4L2 (and DRM to some extend) on i.MX platforms, so I got curious and was wondering what needs to be done actually.

There was a progress update a few months ago here (in German though, so use Google Translate): https://hyperion-project.org/forum/index.php?thread/10463-install-hyperion-ng-on-libreelec-x86-64-rpi-inoffiziell-unofficially/&postID=43192#post43192

German is fine for me. Unfortunately the download link results in 404.

@Paulchen-Panther Do you still have the archive for your work in progress somewhere?

[Paulchen-Panther]

@AlexanderStein Work in Progress Pull Request is coming up in about half an hour. After that, everyone can make up their own mind.

[emc02]

thanks for your work! is it possible to compile it on libreelec? Or has someone a compiled version to test it on libreelec?

[markop159]

@Paulchen-Panther thank you for your work, this has finally enabled me to use homemade ambient lightning on libreelec and RPI 4, like it was working before on my old RPI 2 on OSMC.