[discovery]

@wrxtasy

What Kodi implementation or commit did you use for Jarvis in libreelec, to have auto display refresh rate switch in C2?

Smpc 16 or Kodi Jarvis when you play a movie 1080p /24p change the window in half of TV size in C1 when you set "adjust display refresh rate = on start / stop". Smpc is the best android implementation but the adjust display refresh rate doesn't work as it should in odroid c1.

Maybe a hint by you, could help. Thanks

[ShinyAndy]

Luckily community builds like mine can bypass all that, so anything I release will have problematic Audio reverted.
Raybuntu's releases still had the buggy Audio code in them last time I looked.

I went with Raybuntu's build after I couldn't get samba to work with LE official but the clicks are driving me crazy, the blue flashing led (I know I can fix this with ssh but I'm too lazy) keeps me awake and I'm getting hangs and gaps in audio playback using passthrough. Can I do a straight upgrade with your new 64bit build or does it require a wipe and new install to eMMC?

[wrxtasy]

Instructions in the first Post...

Krypton 32bit to 64bit upgrade instructions.

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

[danjames92]

Well if you change your mind and ever need testers, I'm sure there's a few of us here (myself included).

I hear the Pi 3's have full rez frame packing mvc support in regular LibreELEC builds now? Might have to dust mine off in the meantime.

Not just now, it is included since OpenELEC 6.x or so... so at least for a year, if not longer .

What about LibreELEC?

[noggin]

Well if you change your mind and ever need testers, I'm sure there's a few of us here (myself included).

I hear the Pi 3's have full rez frame packing mvc support in regular LibreELEC builds now? Might have to dust mine off in the meantime.

Not just now, it is included since OpenELEC 6.x or so... so at least for a year, if not longer .

What about LibreELEC?

LibreElec forked after that version of OpenElec - so has always had it I think...

[teefer22]

Hi,

I have been using libreelec version 8.0.1 lately and while it's working fantastically, the blinking blue LED is back. Is there any way to disable that?

Or is the only way to get rid of the blue led to do a new build? I'm hoping there might be something I can add or comment out of a config file or something.

[zaphod24]

Hi,

I have been using libreelec version 8.0.1 lately and while it's working fantastically, the blinking blue LED is back. Is there any way to disable that?

Or is the only way to get rid of the blue led to do a new build? I'm hoping there might be something I can add or comment out of a config file or something.

I did this:

edit (using vi, whatever) .config/autostart.sh and add this:

echo none > /sys/class/leds/blue\:heartbeat/trigger

[wrxtasy]

Hi,
I have been using libreelec version 8.0.1 lately and while it's working fantastically, the blinking blue LED is back. Is there any way to disable that?

Yep do a .tar update with this version

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

[teefer22]

I did this:

edit (using vi, whatever) .config/autostart.sh and add this:

echo none > /sys/class/leds/blue\:heartbeat/trigger

That worked! Thanks so much.

Yep do a .tar update with this version

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

Hmm.. I'm pretty sure I already used this version:
http://wrxtasy.libreelec.tv/Krypton-64bi...gat.img.gz

Is the one you linked to an updated version?

[infinity85]

[...]
@danjames92, Frame Packed 3D on AML S9xx depends on developers getting interested and actually having 3D display equiptment to test on. Quite a few of us don't even have 3D TV's.
[...]

Had some thoughts about this the last couple of days, so sorry to pick that up again, but feel to mention it here

There are some points worth thinking about this Frame Packing thing, if we assume that this Frame Packing commit would work:

1. Frame Packing could be used as a new "refresh rate mode". So that means that if a 3D movie starts, the auto-refresh-rate switch routine in Kodi could send e.g. 1080fp24 as a movie refresh rate instead of the usual 1080p24. And the TV would be forced to turn on 3D mode automatically. Hence the "beloved" 3D TV-autoswitch topic alltogether with "missing 3D-Support on C2" would end with this.
   
2. Working Frame Packed mode would also open the way for full-rez MVC instead of half-rez like it was on Jarvis before. Hence this would be more interesting and especially be more worth investing time and effort for programmers who want to see MVC on non-Raspberry Hardware.
   
3. But in any way: Frame Packed could be the basis to get away from specific kodi patches on AML hardware to be more compliant with Raspberry or general code.
   

I'm quite sure that the raspberry also triggers the 3D-TV-Autoswitch simply by signalling a refresh-rate-switch into FramePacking "Resolution" to the TV:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

This is from my raspberry by playing a simple H-SBS (non MVC) 3D file. Although it is not MVC, it simply sends FramePacked ("3D FP") Resolution/Refresh-rate-mode to the TV and the TV switches into proper 3D.

So from a non-programmer POV I imagine that it could be possible that the Raspberry 3D autoswitch code may be then compatible (or used as a draft) with odroid refresh-rate switch code, as raspberries 3D trigger is probably a simple Refresh-rate-switch to a FramePacking refresh-rate. So same principle could be used on Odroid to solve all the 3D-support requests.

[nickr]

@infinity85, I think you are right on all counts.

[infinity85]

@infinity85, I think you are right on all counts.

Is this:

[noggin]

[...]
@danjames92, Frame Packed 3D on AML S9xx depends on developers getting interested and actually having 3D display equiptment to test on. Quite a few of us don't even have 3D TV's.
[...]

Had some thoughts about this the last couple of days, so sorry to pick that up again, but feel to mention it here

There are some points worth thinking about this Frame Packing thing, if we assume that this Frame Packing commit would work:

1. Frame Packing could be used as a new "refresh rate mode". So that means that if a 3D movie starts, the auto-refresh-rate switch routine in Kodi could send e.g. 1080fp24 as a movie refresh rate instead of the usual 1080p24. And the TV would be forced to turn on 3D mode automatically. Hence the "beloved" 3D TV-autoswitch topic alltogether with "missing 3D-Support on C2" would end with this.
   
2. Working Frame Packed mode would also open the way for full-rez MVC instead of half-rez like it was on Jarvis before. Hence this would be more interesting and especially be more worth investing time and effort for programmers who want to see MVC on non-Raspberry Hardware.
   
3. But in any way: Frame Packed could be the basis to get away from specific kodi patches on AML hardware to be more compliant with Raspberry or general code.
   

I'm quite sure that the raspberry also triggers the 3D-TV-Autoswitch simply by signalling a refresh-rate-switch into FramePacking "Resolution" to the TV:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

This is from my raspberry by playing a simple H-SBS (non MVC) 3D file. Although it is not MVC, it simply sends FramePacked ("3D FP") Resolution/Refresh-rate-mode to the TV and the TV switches into proper 3D.

So from a non-programmer POV I imagine that it could be possible that the Raspberry 3D autoswitch code may be then compatible (or used as a draft) with odroid refresh-rate switch code, as raspberries 3D trigger is probably a simple Refresh-rate-switch to a FramePacking refresh-rate. So same principle could be used on Odroid to solve all the 3D-support requests.

Yep - the Pi has an option to let you output HSBS and HTAB as Frame Packed (rather than as HSBS/HTAB) which means the TV automatically switches - as Frame Packed is inherently 3D, whereas HSBS and HTAB are the same video format as 2D (though I think there may be a flag for one of the two you can raise in an HDMI infoframe packet - though I may be wrong)

However I think this is slightly moot - as I don't think any S905 devs are that keen on 3D, and as 3D displays became less widespread, the format is in danger of being forgotten...

[wesk05]

Yep - the Pi has an option to let you output HSBS and HTAB as Frame Packed (rather than as HSBS/HTAB)

I don't think Pi converts HSBS/HTAB to frame packing 3D output. It just codes the AVI InfoFrame for the appropriate 3D format (which will put the display in 3D mode).

[nickr]

@infinity85, I think you are right on all counts.

Is this:

Not at all!