Slow down of Hyperion.ng

I did the same things. Replaced sketch, upgraded to a micro, using the same hyperion.ng config as Daniel except for the led amount and unfortunately still have slow downs.
Strange…

@danielfmo, please tell us a little bit more about your media storage. Maybe this has something to do with it.

I am running the emby for kodi plugin and have my media stored on an unRAID server that runs emby server and shares the media files through samba to my odroid-c2. All connected through gigabit ethernet. I am playing my media with the direct paths option. So no transcoding happening.

What is strange as well is that I was streaming the world cup games through the “orf” addon in kodi. It’s my countries TV station and they have a livestream feature. I had no slowdowns while streaming the world cup games.

Will next try watch something that is stored locally on the emmc storage of my odroid-c2.

I have w2812b LEDs connected, Daniel has 4wire LEDs connected, could this be a factor?

I don’t think it has anything to do with storage type. I get the slowdowns both when I’m playing files from my Synology NAS via smb and Live TV via TVHeadend.

Also LED type shouldn’t be a factor here. I got 205 APA102 which are also 4wire LEDs with clock and data lines.

Maybe it’s because of frequency rates or some kind of buffer that’s filling after some time causing slow downs

There is a new version 8.90.5. In this version, the nougat kernel by @kszaq was returned. Has anyone already updated to this version? Slowdown on this core, too, are observed?

I will upgrade tonight and hopefully find time to test the new release.

Unfortunately still getting slow downs on 8.90.5.
Frustrating, is there anything we can do to help fixing this? Logs?!

Hi,

I’m sorry if I got you wrong or the other way around but I never wanted to say that I don’t get slowdowns due to the arduino sketch that I’m using.

I posted the sketch because I was asked to, and my setup (Arduino Micro + sketch) is recommended in order to avoid flickering. Not slowdowns.

The cause of the slowdowns is in the Kernel, and that was mentioned multiple times on this thread and many other places. No one knows for sure what causes the slowdowns, other than is it in the amlogic screen grabber.

To avoid this issue RedPanther from Hyperion.ng team and CrashOverride did implement another grabbing method, an GE2D API, in the Hardkernel’s Odroid C2 kernel but I was not able to successfully port it to the OSMC kernel.

Indeed for a long time I didn’t had slowdowns on my Odroid C2 with CE 8.90.4 but they come back recently, that makes me believable that the slowdowns are related to the kind of content being displayed. (codec, bit rate, etc)

Now that we returned to kszaq’s kernel there is a chance that the GE2D API may work, but at the moment I have no time to try to port it.

If any of you is motivated enough to try it please let me know.

1 Like

Hi, than I misunderstood you. I don’t regret changing sketches and buying the micro at all, don’t get me wrong.

I was always under the impression that you didn’t have ANY slowdowns at all.

At least we are sitting all in the same boat :smile:

I am sorry, I can’t help you coding, but I gladly test everything you or anybody throws at us!

Please provide a link and I will look into it.

@cirkator you’re correct, since release of CE 8.90.4 until a few days ago I didn’t had any slowdown! And I use my ODROID C2 everyday. and that is why I say that the slowdowns are cause by something in the hardware decoding that does not go well when doing screen capture at the same time in some specific cases.

@anon88919003
I found the following commits in a kszaq’s fork of linux-amlogic-le, I belieave that it is enough to merge the following commits if not already done but I never testes it:



The original kernel commits are the following, I’ve theste them on Odroid C2 kernel in Ubuntu and it works:



And finally this:

Thanks

Will this fix the slowdowns? Just ordered a box with s912 chipset and I ambilight is one the most important thing for me, and now i’m afraid. :\

I can hardly wait for the availability of this workaround. Is the merge ongoing?
Sorry for being impatient. :slight_smile:

I got a message from adamg (thanks!) that the changes have been added to the repository.
Today I managed to install devel_04.08.2018 (S905.arm) on my Meecol M8S pro. Unfortunately the fault is still present. After 20 minutes the picture slows down then stops. :disappointed_relieved:

Well patches in the kernel/core is one thing, the other one is that you’d have to make Hyperion.ng grabber work with GE2D. Only after making grabber work with the new patches we would be able to know if the issue is resolved or is somewhat better.

Does that mean we now have to wait for the hyperion team to fix their grabber? Sorry, don’t really understand the problem, thought It would be maybe fixed with the kernel patches.

Hyperion.ng already has the code - you can see it in this commit: https://github.com/hyperion-project/hyperion.ng/commit/cb7b5fa58865be165015e0bd65e8a09032b72c83

I’m not on the dev version of CE so I can’t test if it’s working/making any difference. We have to wait until the next version is released and then see if anythings changed.

The GE2D kernel patches have indeed been added but I’m not able to test the changes as I don’t use Hyperion.ng nor do I have the hardware for it, @danielfmo is helping us with it but any changes are added blindly.

I use legacy hyperion addon. Where can I download the .ng version?

I can test whatever you want, but please guide me.

I have arduino hardware and can test whatever but please instruct me what to test.

Just letting you guys know that I updated already to 8.95.0 and switched my grabber device in Hyperion.ng config from framebuffer (/dev/fb0) to /dev/ge2d and Hyperion.ng still works, so that’s a good start.

UPDATE - the slowdowns are still there :frowning: unless there’s something more that we have to change besides just what I mentioned above :frowning: