A few questions regarding LE issues and if they're fixed here

#1

Hi all,

I recently picked up an ODroid C2 and am seriously considering migrating to CoreELEC from LibreELEC 9.0.0 after a friend told me about this fork. I started with OpenELEC on a RPi 3 more than a year ago, migrated it to LE and then recently picked up the C2 to be ready for 4K, plus I wanted to play with some new hardware.

There are a couple of things I’ve noticed as compared to the Pi3, which is flawlessly running LE 8.2.5, and googling around I haven’t been able to confirm if these things are fixed yet:

The first thing I noticed with the LE betas was that there was some sort of weird resolution or refresh-rate issue which would cause our Toshiba TV to randomly blank out and come back on, like you were changing refresh-rates or resolutions (this is an older model, one of the first 1080p flat-screens). Changing from 1920x1080p to 1920x1080i or to 1280x720p fixes the problem. While in 1080p resolution, changing the refresh from 30 to 29.94 helped a lot at first, but didn’t seem to completely solve the problem. Frankly it’s hard to tell if it really helped because it would go for long periods of time without screwing up, then it would start blanking out like crazy to the point where it was hard to see the screen long enough to switch resolutions to stop the mayhem. I have not tested to see if this problem is fixed since updating to LE 9.0.0 but I haven’t seen anything in the change log that would indicate it has been fixed… Amlogic seems to be sort of an afterthought for them right now, they can’t.fit in into the timeline with all the fixes to the kernel, etc., that apparently need to be done to make things “perfect” on these devices. My apologies if I’ve misstated any facts here.

The other issue is pretty minor, but sort of perplexing considering that the C2 is considerably more powerful than the Pi3. If I’m playing a video from an Internet source (I’ve no local sources to check at the moment), such as Amazon Prime, BBC iPlayer, etc., and I pull up the UI while the video is playing (i.e. by hitting Esc., Backspace, or Tab with a keyboard connected), the video and the UI briefly freezes or stutters, all motion on the screen stops for a moment and then everything goes back to normal. The Pi does not do this, there is no perceptible slow down or frame drop on the video when you pull up the UI, the GPU does its work and does not seem to be bothered by any user-interface activity. The C2 is doing hardware decoding btw, confirmed by hitting ‘o’ with a keyboard connected.

I’m running a 64GB Sandisk Ultra SDXC-UHS-I card and while an SD card works fine on the Pi, I’ve heard where folks are saying that eMMC works better on the C2, so to try and eliminate anything related to that, I changed buffermode to 1 in order to buffer all filesystems, including local ones, in case the C2 was inexplicably taking longer to load the icons and such from the SD card than the Pi, although that still wouldn’t explain the video stutter. The change had no noticeable effect.

So, has CoreELEC addressed any/all of these issues, or will these sorts of things be addressed by future kernel/Kodi updates, etc.? I have no problem with the latter, I’d just like to know that others have/are experiencing some of these issues as opposed to thinking that perhaps I picked up a defective ODroid board, which I seriously doubt.

My apologies for the “War and Peace” first post, just trying to cover all of the bases. Thanks for reading!

Cheers,

  • Phil
#2

I didn’t see anyone else with a C2 complaining about the problems you are describing, so assume it is going to work properly in CoreELEC.
As I don’t own a C2, I can’t test it.

Because everybody’s setup is different (your old TV could be a problem), the best way would be to use a spare sd card, install CE onto it and test it for yourself.
If it doesn’t work as expected, you can always switch back to your old sd card with LE on it.

Btw…Amazon Prime and Netflix are being decoded in software, because of some restrictions in the widevine library in conjunction with these providers.

#3

Hello relkai,

Thanks for the response and the work you do on this project, I agree that’s probably the way to go and so I’ll go ahead and give CoreELEC a try to see how it works and post the results here for anyone else who’s in a similar situation. I know you guys have added support for the RTC and such, so it certainly looks like this is a more fully “baked” solution for these devices.

I had seen another post on another forum somewhere (may have been for the Amazon Prime video addon itself), where someone mentioned the hardware decoding restrictions in the license for libwidevine. Not really sure why that is… I’d think they’d prefer to have that stuff baked into the hardware in order to make it more difficult to get at an unencrypted video stream. That doesn’t seem to apply here, since other video sources like ITV, iPlayer, RT news, Retrospect, etc., all exhibit the same behavior. These other addons worked before libwidevine was installed for Amazon, and with most of them the CPU load is very low, with 0-10% utilization across all cores.

I’ll give CE a go and post back. Thanks again for taking the time to reply.

Regards,

-Phil

#4

I’m very sure, you will be happy with CoreELEC.
Let us know, how it is working for you.

I think, the restriction isn’t a technical but a financial decision instead.
They want the hardware vendors to pay for licenses to be able to hardware decode their stuff.
So you are restricted to 720p streams for these providers - make sure to configure it as the max secure resolution in inputstream.adaptive.

I just tested it on my old S905 box and Netflix and Amazon Prime are working flawless and without any stuttering at 720p when other GUI elements are being displayed.
So I really don’t expect any problems with your C2, because it is even better supported than my random tv box.

#5

I wanted to post back on my findings after migrating from LE to CE:

The ‘bad’ news:
The UI stuttering issue wasn’t really helped by the change. Some additional experimentation shows that if you initially pull up the interface while a video is playing, everything sort of stutters briefly and is fine. If you rapidly close and re-pull up the interface, it will come up smoothly without disturbing the playback. if you wait a few seconds before pulling up the interface again, it will again briefly stutter. It acts like the interface/icons, etc., are being buffered but then are flushed from the buffer by the video that’s playing after a few seconds. I haven’t done any graphics programming on modern hardware but the UI seems like an overlay of sprites, and perhaps those are briefly cached but subsequently flushed. Not sure if that’s a GPU setting/driver issue, or if it’s embedded within Kodi but the Pi does not exhibit this behavior. I’m guessing that it’s more noticeable on SD as opposed to eMMC.

Curious behavior for better hardware but not really a big deal, this doesn’t affect our enjoyment.of movies/shows.

The GOOD news:
The interoperability issue with the TV appears to be completely gone, no more blanking out in 1080p video mode!

Attempting to play a video that is aborted before playback (i.e., selecting an Amazon Prime title that is not available for free), no longer hard locks the box. On prime, you get a message that the video hasn’t been purchased instead of having to unplug the ODroid… bonus!

Other issues like hangs and lockups replated to networking appear to be gone (EDUP 802.11ac USB network adapter dongle). Sometimes the system would get into a state where you could not get into the LibreELEC menu, it would make the little whoosh noise signifying that the command was received but not go into the menu to allow network configuration, etc. At that point you’d have to reboot the system in order to regain that functionality. I’m guessing that restarting the Kodi service would likely have fixed it as well but I don’t think it ever happened while I had a terminal window open.

So things are definitely a lot better with CoreELEC on the C2. Many thanks to all involved with this project!

Oh, and relkai, thanks for the tip on setting the Max Secure Decoder option to 720p, that definitely saved me some time in attempting to figure out why “The Expanse” was stuttering/juddering and buffering, etc., after making that change it looks great. Now someone needs to rewrite some of the libwidevine code so it makes use of the GPU… :slight_smile:

-Phil

1 Like
#6

Good to hear, that most of your problems you had with LE are gone after your switch to CE.
Personally I never had a smooth GUI experience while a video was playing in the background and just got used to simply stop any playback before.
I don’t know, what exactly is causing it (the devs could gie you some more information about this issue), but you are not alone. :wink:

Unfortunately the restriction to software decoding isn’t a problem of libwidevine, but of the providers and the widevine implementation instead.
The widevine DRM level 1 (support for hardware decoding) needs to be implemented into the hardware along with the right Android firmware, which requires an official certification. This will never happen with the solution Kodi uses.

#7

Have you disabled dirty regions. This is how i got smooth interface and playback working.

#8

Thanks, @Shoog.
I’m sure you are right, and this could solve the problem.
The temperature of my box increases too much with this setting, and I have no problem with just stopping the playback.
But maybe this could be the solution @pquesinb is searching for.

#9

Yes…@shoog, thanks for the suggestion. I played around with that last night but was unable to get any real benefit and it does indeed increase the CPU utilization when the box is doing nothing. I probably paid too much for a Cogent Design case that doubles as a heat sink (I’m a big “Fan” :slight_smile: of the passive case-is-a heatsink design and I have a Flirc case for the Pi 3 that does the same thing) but it’s beautiful and really does keep things significantly cooler. I seem to recall that the temp with relatively light usage went from 107 to 93 when I took the stock heatsink off and put it in that case. The case gets pretty warm when you’re watching Amazon Prime video content since the box has to do some real work with the crypto in software. I think it got up to 113 degrees, might have even been 117. :open_mouth:

-Phil

#10

I have a mini twelve volt fan which i run at 5v with an upgraded heatsink on my vim2 s912. Salvaged from an old vid card. Temp peaks out at 70 cent when running hard. Barely a hint of break up with gui and media playing together. Dirtyregions is off with 0 as the setting.

#11

I should mention that I’m quoting all temps in Fahrenheit. 70 centigrade sounds pretty high but you’re running an S912 which probably generates considerably more heat than an S905. I really like the heatsink-is-a-case-is-a-heatsink design since it puts that heat on the outside of the box without requiring a fan to move all that radiated outside of the enclosure.

Are you running SD or eMMC?

Yeah, a video can be playing with lots of motion and you can pull up the gui and there’s no perceptible freeze or stutter if you recently pulled up the interface but if you hadn’t done it in a while, then it can freeze for about half of a second or so, which is a pretty long time. The fact that it can do it without freezing if you pulled it up recently shows that the hardware is more than capable of handling it and definitely makes it look like short-term caching behavior. As I’d previously mentioned, I thought that setting buffermode to 1 would fix it but I’m not sure if that has an effect on the UI interface elements, icons and such. I got the impression from reading about the way the system caches icons on a local disk that it might not have an effect. Then again, it may just be that it’s all one cache and gets flushed out by the buffered video. There’s plenty of free memory on the C2 so I could always try cranking the cache up from the 50MB I have it set to now, to 300MB or more and see if the “freezeless” behavior lasts longer. Hmm…

I’m putting way too much thought into what is a very minor issue but this definitely has my curiosity piqued.

-Phil

#12

I run off emmc and the emmc in the vim2 is very fast by these boxes standards. It takes about 10 secs to boot up, about 45 secs off usb

#13

That IS fast… I think it takes about 15-20 seconds to boot from the UHS-I SD card here, probably closer to 20… I’ll have to time it from power-up to be sure.

#14

Personally agree. Im glad for dirtyregions/smartredraw, as I prefer temperatures low as possible :slight_smile:

Although must say, C2 with CE has much smoother GUI than Rpi2+LE, which always struggles with this (but easilly solved by limit GUI fps to 10 when video is played via menu). Not sure what dirty defaults in CE are, I didnt use that parameter specifically on config…

#15

If this info is still up to date, then dirtyregions defauls to 3, which is the “safest”, most-compatible option. 1 is the fastest:
https://kodi.wiki/view/Advancedsettings.xml#algorithmdirtyregions

I believe that the nofliptimeout option has been deprecated though.

- Phil

1 Like