Slow down of Hyperion.ng


#82

Is anything happening with this? I was getting all excited that a solution was on the horizon …

Cheers
Z.


#83

@TheCoolest, Thanks for your efforts on working with the fix. Nevertheless, could you please share the status of the fix? I guess not only me who is very interested.


#84

Sorry, I don’t have any news on this. I don’t think what we tried helped at all.
Sadly it’s still an open issue.


#85

It’s a pity to hear it, especially taking into account problems with the external grabbers :frowning:


#86

Was this issue the “iocompat fixup” mentioned here? https://discourse.osmc.tv/t/osmc-and-hyperion/23293/299


#87

I don’t use Hyperion, I think it’s best if @danielfmo answers that.


#88

Yes it is.

I don’t have some free personal time to address this for a while now.

LE/CE build system makes kernel debugging very time consuming and at the moment time is something that I don’t have .

I can help someone taking this matter in hands.


#89

@danielfmo I would like to help but don’t have the competence :frowning: BTW, Isn’t this “iocompat fixup” a known fix to be simply merged?


#90

We merged it, but it didn’t fix the problem, as far as I’m aware at least.


#100

Hyperion Service has not been build for 8.95.2, so you run the old Plugin Version. Now some of the Python libs we’re updated and Hyperion binary cant start anymore because that Python lib is now missing. I fixed it locally by copying the new lib to the name of the old lib.


#101

Maybe it’s possible to fix at least external grabbers work, please? I provided logs in this topic a month and a half ago, but no comments followed :disappointed_relieved:


#102

Can someone please explain what is known about the actual root cause of the problem and what steps would be needed to fix this?
I feel we are so close. The feature is working fine but only has stability problems. I guess, beside me there are people who would be ready to donate the work if it moved forward the fix.


#103

I’ve installed hyperion,ng from the CE repository, but I want to test-run it for slow-down issue before I invest into LEDs,
web-interface at :8090 says that Hyperion is ON. Is it enough? I’ve also changed the grabber to amgrabber.
BTW, I experience no slow downs, at least for now


#104

holo, I have a ki pro with the 905D gossip and coreelec, I would like to put this invention to the tv but today I still have problems or it works well without stoppages and sorry for my english greetings


#105

See this post in OSMC forum. The “echo 3 | tee /sys/module/amvdec_h265/parameters/double_write_mode” command looks like a very promising workaround.
My system have never worked for more than 15-20 minutes before. After applying this command it is up and running for almost two hours now.


#106

Been discussed many times. This solution is for “4K green light” (look at the parameter path - “am dec_h265”), it doesn’t do anything with slowdown issue, unfortunately.


#107

Damn. I did not see this before in this topic.
Anyway, looks strange that it improved the behavior with non-4K content on my box. Finally the slow down appeared but took far longer time than before.
I hope the guys in OSMC will find the solution.


#108

Slowdown due to Hyperion high cpu usage on Amlogic is a well known bug in Hyperion, nothing to do with Kodi or CoreElec.

Try to lower your grabber frequency to 10Hz on your config file, it will improve performance.


#109

Are you sure? When I tested with lower grabber frequency it only delayed the fault occurrence (half frequency-> doubled time before fault) For me, it much more looks like a memory leak type fault.


#110

The slowdown is still there. My config was always 10Hz and I always had the slowdowns.