Posts by infinity85

    If you are speaking about Android, do you mean that you use a dedicated Android apk from PIA, or do you achieve these high speeds on Android kodi with the vpn addon installed in kodi?


    Assuming you are using an app from PIA to establish your connection on Android, than this app could choose ipsec or pptp protocol, which is mostly faster (either because decryption is way faster, cause weaker, than openvpn, or because PIA has more bandwidth on ipsec and pptp than on their openvpn servers).


    But LibreELEC is limited to OpenVPN, which is more secure, but mostly slower, especially on ARM systems, compared to x86/x64. And some VPN providers may share less bandwidth for the OpenVPN protocol servers, as these need more processing power, hence more energy consumption, less efficient for them and less users care whether it is openvpn or pptp, so they may calculate with this less demand and focus on high bandwidth for the other protocols.


    It's just a guess, but this could be an explanation why your android and libreelec show so different speeds.

    As far as i know LibreELEC was the first system which integrated the IR and HDMI-CEC power on/off. The official kernel adapted it later. Don't worry, it works... The kernel number doesn't matter in terms of libreelec.


    The developer Kwiboo was responsible for this (for OpenPHT, initial testing was on LibreELEC 4 months ago or so) :)

    Storage/.config just like rpi should do it. I just know that some builds had lirc issues... Not sure whether only community builds (wrxtasy, Raybuntu) were affected, or the official ones as well. But anyhow... Storage/.config is the correct directory.
    etc/lirc is read-only, thus cannot be the right one.

    Looks like GPIO IR will be working soon again: ODROID Forum • View topic - LibreELEC 8.0 - Krypton final - media build edition - 32bit
    (have a look at @wrxtasys reply 3 post afterwards)


    It is a missing module since krypton builds.


    Edit:

    Cannot say anything to your actual issue, but you can simply take the lircd.conf from your raspberry and drop it into .config directory the same way as it was on your Rpi2. It will work on the C2 (at least it should and does on mine).


    [...]
    3D auto switch Depends on hardware. Works fine on Raspberry Pi's, not so much on Intel, and C2 apparently. 3D is EOL.


    This might be fairly true. But still the media exists and is sold and at least 50% of the blockbusters in cinemas are in 3D. Of course the TV manufacturers killed it since 2017 now, but many of us users and us "community members" do have a lot of 3D Blu-rays bought in the past and have them at home. New media is even released (looking forward to Star Wars Rogue One 3D release), so EOL is not an adequate argumentation, or are you also going to say H.264 support is going to be EOL next year in favour of superiour H.265? XviD/DivX/MPEG2 is also EOL, still every player is supporting it and every developer makes sure that issues with these formats are sorted out before calling it a beta/final build. In fact I never heard somebody say that XviD support or so is not being looked into just because it is end of life. I haven't used XviD and other older formats since 8 years or so and still naturally would not question to integrate it, as it is good that mediasupport is present for media that is and was present once. 3D is compared to that fairly new and many have it @home. Many don't like it or don't have it. However... many simply have the media and it is not ancient or so :/


    While I can understand that MVC might be a hard thing to achieve since the load of changes in krypton (MVC seems to be always almost impossible to integreate on all devices - looking at forum.kodi.tv), I would at least love to see that the TV-Autoswitch into 3D mode would be integrated somehow again, like it was in wrxtasys builds. This would trigger a TV into 3D mode upon starting a simple (2D based) HSBS and HOU movie.



    The last Odroid C2 builds with 3D support were "7.1.0 wrxtasy (october?)" community builds, if I remember it correctly. These had at least an almost fully working autoswitch TV into 3D mode, which made a good compromise (even without MVC, at least then H-SBS, H-OU)
    [hr]
    Original 3D autoswitch code from @koying: SPMC ADD: [aml] Automatic 3D HDMI switch


    @wrxtasy started then to adapt it to libreELEC:
    3D Autoswitch patch: here
    But it might have made compile issues at first, which this patch from @runnerway solved then: here @forum.odroid.com
    Subsequently wrxtasy was able to provide a working 3D build: ODROID Forum • View topic - LibreELEC 7.0.2 - Kodi Jarvis 16.1 - Archived - LE Tips HERE


    It was also MVC capable (half resolution), but it seems to be unrealistic that MVC will ever be possible on post-Jarvis builds again. Even on intel NUCs there is a fork only for the MVC capability, because it isn't possible to integrate it in the official build.
    [hr]
    But please... I beg you to integrate somehow the autoswitch, so that the TV switches into 3D mode automatically like on Raspberry Pi and other devices (this has nothing to do with MVC).


    The impact on usability with 3D TV-autoswitch feature working: No hassle needed with seeing how kodi splits its OSD into 2 parts showing H-OU or H-SBS OSD instead of simply turning TV to the appropriate 3D mode. So you're forced to pick the TVs remote and choose in TVs OSD the correct 3D mode manually, which has then to match kodi's OSD. This is simply not so user friendly and not girlfriend friendly :D:(


    [..]
    Maybe the developers would consider adding an option in the LibreELEC settings to allow the user to disable eventlircd as well as LIRC... Who do I need to contact to request this?


    I'd also like to see this. And from the logic point of view the "Disable LIRC" button should also be linked to disabling eventlircd as well altogether.


    Your eventlircd discovery explains now why I wasn't able to use ir-keytable last week, when I first tried it. There seemed to be some kind of interference in keypresses and I didn't know how that could be, as I thought LIRC was disabled.


    I'm also looking forward to test this somehow as soon as it is solved.


    Update: Nevermind; I didnt have xbmc lcdproc installed. Except that I had to use an older driver, its running now as expected.


    MAN... you got it! This was the thing I missed all the time... I thought the service addon would substitute the xbmc lcdproc addon! Finally I got it working :)


    Thanks a lot!


    Other thing:


    As the Odroid C2 doesn't cut off 3V3 power after shut down, is there a way to evoke a "XMBC LCDproc Addon service-disable" command upon LibreELEC shutdown or perhaps even as a button/keymap command as well?


    Asking specifically about service-disable command, because I see that my OLED turns off as soon as I disable the LCDproc addon. And it turns on again as soon as I enable the service again. But if I shutdown the Odroid, my OLED I2C display remains displaying the "bye bye message" until I pull the power cable. And after I power the Odroid again, the Display still shows the "bye bye message" until kodi is loaded... so the display kind of remembers the bye bye message in its cache or so, because it was shut down not safely.


    So: If there is a command/script, which automatically "presses" the "Disable Addon" button for XBMC LCDproc addon, that would turn off my OLED.
    This does perhaps just turn off the backlight of an LCD? I don't know, but on my OLED it looks as if it is simply off then.


    EDIT
    But then again... if "XBMC LCDproc Addon" was disabled and thus turned off my OLED, then it would jump into the "bye bye" message if shutting down the system :/... Any ideas how to turn it off on an Odroid C2?


    It is a 10bit hevc file. It's using the developmental hevc vaapi driver. I tried playing it on the Braswell which plays 8bit 4K well and it died. I can tell you that the picture quality/color depth is night and day between the 8bit file playing on the Braswell and the 10bit file playing on the Apollo Lake. Not sure how to verify the TV side of the feed but the picture is amazing!


    Look at the following link for performance.


    4_K_Play_Libre_Elec.jpg


    Yeah, heard that performance should be no big deal, the nuc is perfectly suited for handling all current formats :). Unfortunately I don't know either, how to confirm whether the actual output is 10bit, but this would be the most interesting thing besides HD-Audio passthrough, which still seems to be not working if using HDMI connection and 4k resolutions, if I remember it correctly from forum.kodi.tv.


    I've been evaluating my NUC6CAYS with 4K HEVC dev build. Get great 4K 10bit playback at 60Hz on my Samsung UHD TV but the build is still buggy (occasional crashes, lock ups, etc). It's early but I would say the hardware has no problem with 10bit 60Hz playback (Super low load 30% RAM usage and I'd say an average of 15% - 25% processor load... the software is getting there. Looking forward to the final product!


    Cool, thanks for the feedback :)


    As you have got an UHD TV: Does it indicate somehow whether the NUC output signal (input into TV) is 8bit or 10bit? Would like to know whether the NUC does also output the 10bit decoded stream as 10bit and not as 8bit, like most devices do unfortunately.


    Are there any news about that? Had bought an ODroid, switched from an RPi 2 ( OSMC ).
    In the latest beta i had used Amazon Prime worked like a charm, slow but it worked. After i wanted to try Amazon Prime by inputstream on libreelec now with my ODroi it dont. The problem is the known DRM. On kodinerds i had rad about the libwidevinecdm.so file that isnt working with an droid c2.


    So maybe it is allready working but if so i dont know how, maybe someone can told me how to solve that problem?


    Here you are: ODROID Forum • View topic - LibreELEC Krypton/Leia/Agile 64bit kernel 32bit libs


    but I'm afraid, that lrusak is right about this. It least the above builds from Raybuntu are 32bit, thus capable of skygo etc.


    OK you might found something. Let's discuss this further in my Thread since these thread is for official Bugreports.


    I might have, but I'm still not sure myself. I couldn't reproduce it later on and I believe that the issue is rather occuring if the internet connection is limited. The thing could be that with slower internet the stream could run into a limit and get hickups, the other builds (pre peak3d) were tolerant, they could catch up after the interrupt and it wouldn't occur again. Your builds may be a bit sensitive during tuning process or with interruptions (which may occur with IPTV here and there if downloading something at the same time).


    So I think it could've been that there was a download running, when this sync issues occured. As I said, the other builds simply stuttered some seconds and got in sync and smooth again. Yours may get out of the "flow" and then no resync gets it back to normal again. But as I still have probs to reproduce it, I will report it @forum.odroid.com as soon as I have more certainty.


    FYI: I wanted to write you yesterday after you've mentioned that it is not the right place here, but upon bringing the odroid tab in front, I ran into this malware issue on hardkernel websites and I lost the thought then.


    It looks like your issues are in those streams you are using. Sometimes they work sometimes they don't. I am no expert to ask about Kodi audio issues.

    I'm afraid that's not the case here. These are not illegal sky stream links or so, and they work on wrxtasys builds as well as on a raspberry and my firetv. It seems to be a muxing problem when tuning. Sometimes it works, sometimes your build struggles at the beginning. If it tunes in sync, then it stays in sync. But I can switch to another channel and back to the first again and it is most probably struggling at the beginning and then it plays with many seconds asynchronously. Doesn't happen on older krypton aarch64 alphas (before the patches from peak3d) and not on wrxtasys 7.x.x.


    I've tested this new build yesterday and yep, I can confirm all this.


    But there appeared a huge issue regarding LiveTV through IPTV Simple Client: Watching and zapping has improved a lot since raybuntus betas, but the beta1j cannot establish audio video sync here. I cannot even say how many seconds async there is, it seems to be different after every channel switch, but clearly 5 seconds or so, not just 300ms or so. Apparently such a live stream is a problem compared to a mkv video file.


    EDIT
    Okay... that was yesterday. Now this doesn't happen anymore hmm.
    Now it behaves like on the betas before: After switching to another channel the sound comes, video freezes for 4 seconds and then unfreezes in sync with audio. And mostly it repeats the audio of the last second then. So apparently the video waits for a timestamp where it is in sync with audio and unfreezes in sync then. in 7 out of 10 times it simply echoes the sound of the last second after unfreezing.
    But this happens only in LiveTV. All this on Raybuntus 32bit betas. I will have to catch the logs and post them odroid forums. Perhaps this will help to narrow it down somehow.


    EDIT #2
    and now it begins again. I see ~3s async on one channel. ~1s on another channel. Zapping back to the first channel it is almost in sync instead of 3s async.
    Which component-specific logging would be useful for this?

    • FFmpeg
    • Audio component
    • Video component


    ?

    I don't know either, unfortunately. But that could certainly be answered at forum.odroid.com in hardware and peripheral or in issues section.

    I'm not sure why you don't simply follow the guide for making your own lircd.conf...


    I've tried it with my harmony... Your given profile does not work for me either. But following the above linked guide, I made a custom lircd.conf (see attachment: lircd_harmony-hauppauge-pvr350.zip)


    The thing is that some buttons give the same codes:

    • INFO and MENU button have the same code 0x17CD



    • and the buttons SUBTITLE/CLOSED CAPTION/ # have the same code 0x17CE


    This is likely because I used a harmony to simulate yours. Perhaps you don't even have some of the mentioned buttons on the Hauppauge remote. But as I said: Simply follow the guide to create your own lircd.conf and it will work this time with the hauppage remote. Seems to be a pretty appropriate one for LibreELEC :)