OverSun wrote:should work also on my code. the only thing required is to turn off frame rate automation in kernel, it is buggy. the kodi switching works fine.

Ah - so there are two ways of implementing refresh rate switching then? Are they along the lines of :

1. Frame Rate Automation in kernel (which AIUI is a great solution for Android apps like Netflix causing the OS or kernel to switch to 24p, 25p/50p etc. as they play media with different frame rates, without the app needing to know or the user needing to intervene) Effectively this is automatic refresh rate changing at the sub-OS level?

2. OS controlled refresh rate - where the OS changes the output refresh rate. This is how most other platforms work, and how the C1/C1+ does? i.e. Kodi detects the frame rate of video on playback (using ffmpeg I think), then sets the output refresh rate (if configured to do so) to the best frame rate for the content?

It is working for me flawlessly for C1 for a year or more, and working flawlessly for C2 since commit https://github.com/Owersun/xbmc/commit/ ... 071b75db2f which is 17 days ago as github suggests. It was working even before that, but with some edge cases that could slip into dark screens. Right now I didn't experience any problems and I watched almost everything, 23.9, 24, 25, 29.9 and 30 fps these two weeks.
The process itself is there since C1, the only addition that made a difference for C2 was more precise 4k handling and figuring out the thing that "Frame rate automation" in kernel actually makes it black.

Oh common guys, do I really have to make my own package to show it to the world? We have so good packagers, I thought they figure out what works and what not in days... But for some reason patches that make it out to ELEC builds are becoming more and more looking like dirty workarounds (as it is with passthrough right now and the way Hz change go also).

OverSun wrote:It is working for me flawlessly for C1 for a year or more, and working flawlessly for C2 since commit https://github.com/Owersun/xbmc/commit/ ... 071b75db2f which is 17 days ago as github suggests. It was working even before that, but with some edge cases that could slip into dark screens. Right now I didn't experience any problems and I watched almost everything, 23.9, 24, 25, 29.9 and 30 fps these two weeks.
The process itself is there since C1, the only addition that made a difference for C2 was more precise 4k handling and figuring out the thing that "Frame rate automation" in kernel actually makes it black.

Oh common guys, do I really have to make my own package to show it to the world? We have so good packagers, I thought they figure out what works and what not in days... But for some reason patches that make it out to ELEC builds are becoming more and more looking like dirty workarounds (as it is with passthrough right now and the way Hz change go also).

Collaborating to fix all the problems would mean solutions could be found sooner with everyone getting their proper credit for their contribution and it sound as though you have a lot you can contribute. I wouldn't call myself non technical, but with respect to this I am not much better than a noob (lol) so I don't have much to contribute but my thanks and words of encouragement.

All that being said, if you have a solution to a problem facing the community, your input is highly appreciated as the frame rate switching is the main issue facing most of us! And thank you to all contributors who have helped to make the C2 realise even part of its full potential because I know it takes a lot of time which could have easily been spent doing something else.

Me similarly. Happy to help - and quite good at breaking things (and can feed back analytically when I do) - and have a good eye for stuff (particularly video decode and deinterlace artefacts)

Looks to me as if there are a few issues with the C2 at the moment in Libre Elec terms:

1. Refresh rate switching (Sounds like oversun may have a solution by not using the Kernel Frame Rate Automation?) (This is also the case in Android)
2. 2160p output (currently the Libre Elec builds seem to be stuck at 1080p - a legacy of C1-basis?) (Android supports 2160p if you manually select it with Android)
3. Interlaced DVDs not deinterlacing (MPEG2 DVD ISOs, VIDEO_TS, VOBs etc.) with native interlaced content are not deinterlaced properly. (Native progressive content can have deinterlacing disabled for 25p stuff) Can software deinterlacing (YADIF 2x) be enabled (apparently there is now some NEON support in ffmpeg to assist ?) if AMLogic don't fix the hardware deinterlace (which is apparently the current problem?)
4. Bitstreaming S/PDIF quality : DD/DTS not available in LibreElec (drop outs in Android)
5. Bitstreaming HD audio : Dolby True HD / DTS-HD MA (currently this isn't available on any ODRoid but it is on the S812 Wetek Core - but only in Android)
6. PCM Multichannel (as above - and useful for AAC 5.1 audio used on terrestrial TV in some regions and for FLAC multichannel rips)
7. IR remote (The built in IR remote currently not enabled - Meson-IR + device tree issue but there are posts that help?)

Not sure what the state of CEC is (Wetek Core now has improved CEC which allows AVR remote audio control AIUI)

I've hunted down and finally fixed Kodi Dynamic Refresh Rate Switching on the S905
Also thanks to gda and Raybuntu we now have a libCEC compatible patched C2 S905 AML Kernel for HDMI CEC configuring and AVR control within Kodi

Still working on true 4K video output and Audio for mainline Kodi, I've tested Oversun's Kodi Jarvis repo, but it breaks PVR Addon's at the moment. Time to cherry pick, as 4K was looking good during my last lot of testing (excluding dynamic refresh switching) after some minor patching for the Kodi GUI and for the 2160p50hz420 and 2160p60hz420 GUI display modes.

WARNING, this version is having Ethernet connectivity issues for those using SD cards only, eMMC no Problems. I'm suspecting a HK Kernel update to be the root cause of the issue.

I've hunted down and finally fixed Kodi Dynamic Refresh Rate Switching on the S905
Also thanks to gda and Raybuntu we now have a libCEC compatible patched C2 S905 AML Kernel for HDMI CEC configuring and AVR control within Kodi

Still working on true 4K video output and Audio for mainline Kodi, I've tested Oversun's Kodi Jarvis repo, but it breaks PVR Addon's at the moment. Time to cherry pick, as 4K was looking good during my last lot of testing (excluding dynamic refresh switching) after some minor patching for the Kodi GUI and for the 2160p50hz420 and 2160p60hz420 GUI display modes.

Tested this update and frame rate change works! There is one small caviet though...skipping through a video results in the frame rate being reset then set again so even a 10 second skip forward results in a black screen for about half a second then the video resumes. In the grand scheme of things this is indeed minor.

If anyone is using microSDHC cards, can you please tell me what brand is working properly, with good stability.
Two Samsung SD cards I have do not work properly and cause all sorts of MMC Kernel log errors. Yet to test Sandisk ones.

wrxtasy wrote:If anyone is using microSDHC cards, can you please tell me what brand is working properly, with good stability.
Two Samsung SD cards I have do not work properly and cause all sorts of MMC Kernel log errors. Yet to test Sandisk ones.

I'm using a Samsung 16gb card.

Unfortunately I have developed an issue since the latest update. I had moved the C2 to my living room before the update. I did the update out there and moved it back to my bedroom after testing it and since then the ethernet port has stopped working. The same ethernet cable works fine in my laptop but in the C2 it doesn't even light up anymore. Could the update have caused this?

Yes I'm finding that occasionally. Just let the C2 power down for about a minute to fully drain power. And then plug in and watch for the Orange Ethernet activity light. Ethernet seems to randomly not power up occasionally when the Kernel starts up.

I've fixed the black screens when skipping thru video as well, download the RSv2 from the link again and update.

tested on 32gb SAMSUNG EVO, no problems
i think Dynamic Refresh Rate if forced on now, even if in settings its disabled.
on channel switching for live tv screen goes blank for 2-3 seconds.
screen wont goes black if hardware acc is disabled, but then videos are in slow motion with h264

Sadly I moved my C2 back to the living room and the issue has presented itself again. eth0 is not being detected. Gonna set it up again and just leave it in the living room once and for all now that frame rate switching is working.

The PVR add ons are what let us use PVR backends with Kodi. PVR backends are the Live TV servers we use to receive (and in most cases record) digital TV (DVB-T/T2/C/S/S2, ATSC 8VSB/QAM or ISDB-T) The original post is about the VNSI PVR add-on which is one of the PVR add-ons used for the popular VDR TV system (an open source PVR that some people use just as a back-end).

Other popular PVRs are TV Headend, MythTV etc. Judging by the number of posts at Kodi Forums, lots of people use PVR add-ons. Personally I use TV Headend a lot for DVB-T/T2 and Sat>IP DVB-S/S2 duties.

wrxtasy wrote:If anyone is using microSDHC cards, can you please tell me what brand is working properly, with good stability.
Two Samsung SD cards I have do not work properly and cause all sorts of MMC Kernel log errors. Yet to test Sandisk ones.

I don't use Samsung SD cards anymore, especially EVO's, too many issues with Odroid and switched to SanDisk Class 10.

OverSun wrote:
...on C2 it causes black screen. Without it in the kernel everything works just fine in Kodi.

Yes I agree, looks like a Bug if Frame Rate Automation (Level 1) is left on when Refresh Mode switching and trying to play back Fractional Frame Rate Video (23.976,29.97,59,94fps), then you will end up with a black screen.

I'm no skilled Kernel coder, so will handball this one over to those with detailed knowledge of the AML Kernel.

If Frame rate automation level 2 is used, Automatic Refresh Switching occurs and playback is then in Sync. However Skip around in the video and the Frame Rate Automation process is slow to catch up and causes a short black screen. This is what I will use as a temporary workaround until AML fixes their code along with letting users disable refresh switching completely and just use 60Hz all the time if the tiny black screen issue gets annoying.

I have DD/DTS passthrough working on LibreELEC with precisely the same issue as the Android build. There are regular dropouts which are more noticeable with DTS than DD. Whilst by no means perfect it is a step forward from mute. Unfortunately the workaround that can be used on Android doesn't work with LibreELEC, if the digital_codec is changed to 2 or 3 there is no sound output.

The changes to get to this stage are quite straight forward. Firstly, 'rate 44100' has to be removed from asound.conf otherwise 48kHz DD/DTS gets routed through ffmpeg by Kodi and it doesn't work.

Next, changes to xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp to replace the code dealing with setting the buffer and period size. Credit goes to Oversun for these changes. I'm a patch file noob, so I'll just post the code block here and hope someone can patch it into a build properly.

Hopefully this will help make some progress to getting passthrough sorted.

Yes I agree, looks like a Bug if Frame Rate Automation (Level 1) is left on when Refresh Mode switching and trying to play back Fractional Frame Rate Video (23.976,29.97,59,94fps), then you will end up with a black screen.https://github.com/hardkernel/linux/blo ... ut.c#L1206

I have DD/DTS passthrough working on LibreELEC with precisely the same issue as the Android build. There are regular dropouts which are more noticeable with DTS than DD. Whilst by no means perfect it is a step forward from mute. Unfortunately the workaround that can be used on Android doesn't work with LibreELEC, if the digital_codec is changed to 2 or 3 there is no sound output.

Wonder if the frequency of drop outs is bitrate related? DTS tracks are often at a higher bitrate than DD? That may be why we get more dropouts with DTS than DD? (Or it could be error concealment / correction is better in DD - not sure/don't know)

ISTR when there were HDMI clock issues with the original C1 - which caused audio drop outs (on PCM as well as DD/DTS - so different situation) on AVRs, it was much more of a problem on HDMI modes like 1080/50p and 1080/60p rather than 720/50p, 720/60p or 1080/24p because the 1080/50p&60p modes used twice the HDMI clock rate (so were probably quicker to get 'out of tolerance')

noggin wrote:Wonder if the frequency of drop outs is bitrate related? DTS tracks are often at a higher bitrate than DD? That may be why we get more dropouts with DTS than DD? (Or it could be error concealment / correction is better in DD - not sure/don't know)

ISTR when there were HDMI clock issues with the original C1 - which caused audio drop outs (on PCM as well as DD/DTS - so different situation) on AVRs, it was much more of a problem on HDMI modes like 1080/50p and 1080/60p rather than 720/50p, 720/60p or 1080/24p because the 1080/50p&60p modes used twice the HDMI clock rate (so were probably quicker to get 'out of tolerance')

It doesn't look like it's bitrate related. I tried different DTS sources with bitrates at 1536kbps and 768kbps and I tried them with 720/60p resolution and the dropouts are just as bad and at the same frequency. DD dropouts seem less frequent but they're much harder to hear so it could just be that they're there but not noticable. There's nothing in the Kodi debug log which correlates to the dropouts and the fact that this issue can be elimiated on Android with a digital_codec change suggests to me that whatever changes are made to Kodi won't be enough.

What would be useful would be a log of how the audio is handled after it's passed on by Kodi. Does this exist anywhere? Are we simply in the dark here due to lack of docs from Amlogic regarding the S905?

Yep - the whole digital HDMI audio bit of the AMLogic kernel seems a bit opaque. Wetek have got somewhere in Android with PCM Multichannel and HD Audio bit streaming on the S812 - but AIUI they had to make changes within Android (not just Kodi) to do this. This is one area that demonstrates the advantage the Pi people have - some of their developers also know the hardware inside out (and wrote the firmware that handles the GPU stuff)

I'm throwing the odd idea out there in case it helps - sadly I'm not clever enough to fix them. (But I do have a broadcast engineering background so can spot things that aren't right quite effectively). Think this helped a bit in diagnosing the original C1 HDMI drop-outs (when Hardkernel were stumped and thought it was related to mains frequency) - but only in a roundabout way...

So I flashed the latest tar file and everything was working fine until I tested a wifi dongle on the system.
The wifi worked fine but I didn't need to use it at that location since I was nearby my ethernet connection.
I shut down and unplugged and then replugged the ethernet and now it is not working. No lights on the port at all?
I am a novice at this so I wonder if anyone has any suggestions? I thought about reapplying the update again but am not sure I should do that.
Thanks in advance for any help.

spades wrote:So I flashed the latest tar file and everything was working fine until I tested a wifi dongle on the system.
The wifi worked fine but I didn't need to use it at that location since I was nearby my ethernet connection.
I shut down and unplugged and then replugged the ethernet and now it is not working. No lights on the port at all?
I am a novice at this so I wonder if anyone has any suggestions? I thought about reapplying the update again but am not sure I should do that.
Thanks in advance for any help.

Same issue I described earlier. I don't know what it is but when you plug out the ethernet cable it doesn't seem to work after that. Initially like you I was switching between ethernet and wifi when I noticed, but it happened when moving from one wired router to another, and now you're reporting it happens when plugging out ethernet and plugging it back into the exact same cable and port.

The only solution I found was redoing the whole thing. Writing the img file all over again. Updating using the tar after that keeps it working.

Yes I have seen this numerous times now when using SD cards, looks like a Kernel issue with some MMC change HardKernel have plugged into the Kernel itself recently. I going to revert a few things and keep testing.

I'm wondering if I should withdraw the previous .tar update until I get a stable Ethernet connection on SD card setups ?
If using a eMMC Flash card I have no such problems.

2160/50p and 2160/59.94p content is playing well in 2160p on my Sony UHD. 3 CPUs around 10%, 1 CPU occasionally hitting 40 or up to 65/70% at times when the Codec OSD is on.

What I did notice is that when I had the C2 routed through my Onkyo AVR (which is limited to 1080p input resolutions via HDMI 1.4b) the 2160/59.94p was downscaled to 1080p and jerky.

The Hardkernel IR remote is working though pretty sluggish.

As others have stated - no DD/DTS passthrough.

Amazing that we can do this on such a low cost box. Still definitely a WIP - but a good WIP.

*** EDIT : Update. When watching 576/50i MPEG2 or 1080/50i H264 Live TV output at 2160p I don't get deinterlacing to 50p (it looks like it is being deinterlaced to 25p rather than not being deinterlaced as there is no combing on native 50i content - just 25p rather than 50p motion. You probably won't notice this on 25p native content like drama and most documentary, but you certainly see it on Sport, News, Entertainment etc. content, and it failed my usual BBC News Channel ticker test ). This is the case after a reboot - not just after watching 2160p native content. If I switch the System Video Setting to 1080/50p output I get proper deinterlacing of both 50i formats.

720/50p H264 recorded content plays fine output at 2160/50p (though the upscaling is quite basic - what algorithm is the S905/LibreElec using?) so it looks to be a deinterlacing issue?

AVR remote control of my Onkyo volume level is working well. CEC implementation a huge improvement.

Last edited by noggin on Fri Apr 15, 2016 9:50 pm, edited 4 times in total.

Thanks for your hard work.
The passthrough still doesn't work.
HDMI CEC is crazy, my tv remote doesn't work now, in the firt image worked without problem.
The remote control that I bought along with de OC2 works now, just apears to be a little slow.
Any idea what is my problem?

Update for me was successful - C2 with emmc card, no attached devices, on samsung tv
Hdmi-cec working great now, way better than before, the context menu button on tv remote works now.
Navigating the GUI is smooth, just like RPi 3
Can't comment on any 4k or 2160 playback...

Thanks wrxtasy....now to sort out the high temperature when kodi is idle

1. When I change to a 16:9 SD MPEG2 channel, there is a strange aspect ratio artefact. When I switch to BBC News Channel SD (704x576 16:9 SD MPEG2) it displays video - but initially it is pillarboxed (i.e. black bars left and right and squashed video each side), and then jumps to full-screen. (Never seen other platforms do this) If I switch to BBC Parliament SD (544x576 16:9 SD MPEG2) it does the same, but the video is even more squashed and the black bars either side are wider. It looks like the video is initially being scaled as square (i.e. 1:1 aspect ratio) pixels - and then the pixel aspect ratio from the signal is used to correctly 'stretch' the video horizontally.

2. When I change to a 16:9 SD H264 channel (544x576/50i 166:9 SD H264 Al Jazeera Arabic for example), it sticks in the initial pillarboxed mode and never stretches to 16:9 full-width. (It's like it's ignoring the pixel aspect ratio information from the incoming signal?) It does the same on Film4+1 SD (also 544x576/50i 16:9 SD H264). I have what appears to be a 544x576 squashed into the centre 544 samples of a 1024x576 image scaled to 1920x1080 (i.e. a half-width image with quarter width black bars each side)

My gut feeling is that at some point the source video is treated as square pixels for some reason - so 576i video is rendered initially as if it is 1024x576 (i.e. 1:1 square pixels for 702x576) or (1050x576 which is the slightly wider aspect ratio used for square pixel 720x576) So when you switch to a 704x576 channel it is displayed as if it is the central 704 pixels in a 1024 pixel 16:9 image, and if you switch to a 544x576 channel it's the middle 544x576 pixels in the 1024x576 frame. With MPEG2 content the pixel aspect ratio is then followed and the image stretched. For H264 it isn't and it sticks in pillarbox 1:1 aspect ratio..

I am in View Mode Normal in Kodi's video settings. I can force the video to 16:9 mode by changing this setting, but I shouldn't have to.