Posts by -=guybrush=-

    Hello to everyone. :) I own an OPi PC with the latest jernej's LE 11.0 image on it and I'm trying to use it with an ancient CRT tv set through scart connection. I've also added the 50 Ohm resistor between the composite RCA connector signal and shield as adviced here but the 'issue' (not a real issue but something related to my weird setup) is another here: the lowest resolution I can set is indeed 720x480i which is way too much and the image flickers badly.

    If I'm not mistaken, scart connection works at 320x240. Am I right? Should it be the case is such a low resolution supported by LE and my OPi PC and does it leave LE enjoyable or is it just a dumb effort? Should adding such a low resolution make some sense, how to add it to the list of the available choices?

    Thanks in advance to everyone! :)

    Hello to everyone and thanks to jernej for his great effort with these builds. I own an OPi PC, I'm currently using the 20210421 image and I'm experiencing something similar (or maybe it hasn't anything to do with it) to what was being described here by levitsky86.

    First of all, there is a BIG difference between my scenario and his. I'm not talking about iptv so connection bandwidth isn't an issue for sure. I'm talking about DVB-T broadcasted contents. To view them using my OPi PC I use tvheadend server downloaded here along with an Xbox One Tuner (Panasonic MN88472). I'd like to underline that I've already ruled out issues with the tuner itself having tested another tuner (still an Xbox One) with the same results, the both of them going perfectly fine both with an RPi 3 and a Wetek Core, still on Libreelec.

    If I play SD contents, everything is absolutely fine and smooth while if I play HD contents (I've checked and they're H.264) it goes fine for a while (sometimes just a couple of minutes, sometimes even thirty minutes but sooner or later the same happens) then the image 'pixelates' and it never recovers. The more the scene is fast, the more the pixelation is worse while the audio remains perfect and smooth.

    The only way to stop it from happening is to change the channel to an SD one then back to the HD one and everything recovers till the next time it starts acting up again.

    Maybe it's just a coincidence but, prior to switching to the tvheadend server version linked above, I was using an older version from the 4.2 branch and the problem seemed even worse but probably the cause wasn't the different tvheadend server version but the fact that I was on an older image too.

    A nice day to everyone! :)

    chewitt

    I don't know how to thank you! I've taken the MicroSD out of my OPi PC, put it inside my laptop, mounted it under Ubuntu and edited the file /extlinux/extlinux.conf adding

    Code
    ssh

    at the end of the line beginning by

    Code
    APPEND

    indeed the kernel boot parameters and voila, now I've got a working SSH connection. Great! Now I can go on with my attempt to get a working tv-out. I'm marking the thread as solved. Thanks again! :)

    Hello to everyone. I fear there isn't a solution for what I'm going to talk about but I try. I have an Orange Pi PC with broken HDMI and I'd like to use it with its tv-out output. I know it isn't supported out of the box but support can be added playing with overlays on the latest nightlies from jernej (thanks to him for his great work and help).

    The problem is that I've tried to install the latest nightly image (writing it to a microsd by Passmark imageusb as I always do; I've tried even with the official LibreELEC sd creator with the same outcome) and I recall fairly well that on first run ssh needs to be activated from the GUI indeed if I try to connect to my OPi PC address as root user I always get "connection refused". My idea was to login by SSH, make the necessary modifications then get, hopefully, a working tv-out so the graphical user interface but this way I'm stuck.

    Is there a way round this problem I'm not aware of? Maybe building an image with SSH enabled OOTB or something similar? Thanks in advance for your replies and a nice day to you all! :)

    Mario77

    I've obviously read post #12 and I've also explained the reasons why I don't think it applies to my case. Thanks anyway.

    EDIT: I need to apologize both with Mario77 and gedakc. Going into details, I've missed the most obvious thing: deinterlacing always happens, no matter if the contents are locally stored, internet based or broadcasted on DVB-T! Stupid me! Indeed I've choosen MMAL - BOB as the default deinterlacing method for all kind of videos selecting the gear icon from the OSD and now (but my testing has been very limited, only one minute of viewing; I would come back with the results of a more thorough use) HD contents seem fine with no need for buying any codec or else. Usually, they began to stutter immediately so it is at least a good sign!

    A brief update on the stuttering 'issue'. I've bought a TV hat and the stuttering with HD contents (over DVB-T, we aren't talking about network contents nor recordings or local files in general) is even worse than how it was with the Xbox One tuner. By what I know (but I may be wrong) HD contents should be MPEG-4 here in my country so purchasing the MPEG-2 codec should be useless while, not being a recording, I can't follow gedakc advices (thanks anyway!).

    I've made some digging and I've found some threads like this or even more this one. Unfortunately, I'm still missing how to sum everything up...

    EDIT: I've just checked and the HD contents which stutter are H.264 1080p while SD contents (absolutely fine) are MPEG-2 576p.

    I have news which put virtually an end to the thread. I've tried to use the 8.2.5-CVBS img in dual boot on an SD card (as done previously BUT when there was the stock WeTek firmware installed on the NAND, not LE) but it didn't work: it just didn't give me the option to boot from SD as I was expecting instead (and it should have happened). I've then tried to install it directly on the NAND but it didn't install neither.

    I've got the error described here and applying the workaround suggested in the same thread at post #6 I was able to install it. The only advice is that the /flash partition is mounted readonly so to apply the workaround it is necessary to remount it rw.

    I've edited disp_cap in the userdata directory accordingly but still no output on CVBS. Then I've started to think I needed to rule out an issue with the output so I've reinstalled the stock firmware and CVBS doesn't work with it either. The cable I've used works perfectly fine with my WeTek Core with stock firmware and even with LE but only for the boot spash screen so this rules out issues with the cable but I've also tested it with a multimeter with success, just to be absolutely sure.

    I've then opened my Play and tested the same cable while connected to the CVBS output: there is connection so it isn't a physical problem with the connector itself but I'm starting to think that my Play has something wrong with the circuitry handling that output and maybe with the actions I've taken and described in my first post CVBS could have worked even with 9.0.2 (my idea is linked with the latest sentence in the thread pointed out in one of my previous posts).

    It is almost impossible to scour a Play these days and I can't do anything more than what I've already done under the current conditions so, without the help of someone else who owns a Play with a working CVBS output, we're at the end. That's a pity. I would use it with the adapter I've already bought but this is only a workaround and many questions remain unanswered unfortunately and so they would remain given that I don't see (and I understand the reasons for that) much interest around this topic. :(

    I found an LE-8.2.5 firmware that supports the CVBS output:

    libreELEC-CVBS-binaries/LibreELEC-WeTek_Play.arm-8.2.5cvbs at master · rgenoud/libreELEC-CVBS-binaries · GitHub

    If possible, try it on an SD card, and if it works, the patches will need to be integrated into version 9.0.2.

    However, the analog audio output will probably not work with this either.

    My fault. I haven't noticed your reply and in my last post I've relinked the same. Thanks but I had already found that a long ago and it didn't suit me because I use some add-ons which don't work with it. I've linked it this morning (along with the rest) just to summarize my findings, just in case they could be of help for someone.

    I understand your point though and I would make a try with it.

    I've bought an adapter online but it would get a month or so to arrive so in the meantime I'll try to solve the problem instead of going round it. I've already talked about older LE version with working CVBS for the Wetek Play. Here they are:

    LE 7.0

    LE 8.2.5

    For the latter, it is necessary to rebuild the package like described in the readme, just issuing

    cat LibreELEC-WeTek_Play.arm-8.2.5cvbs.img.xz-part* > LibreELEC-WeTek_Play.arm-8.2.5cvbs.img.xz

    while for the both of them the update process is the same as always. As already explained, older versions aren't fine for me so I wanted to apply dtech's teachings...

    Here (another of the findings with my research) I've found a patch which seems to be what I'm looking for and I wanted to apply it to build a 9.0.2-CVBS. Here is what I've done so far:

    git clone https://github.com/LibreELEC/LibreELEC.tv.git -b 9.0.2

    and in the projects folder I've found what I expected, an encouraging WeTek_Play folder so I was planning to build everything just issuing

    DISTRO=LibreELEC PROJECT=WeTek_Play ARCH=arm make image -j8

    as dtech has teached me. The problem is that I thought what I had downloaded by git were the sources but by a very quick look I couldn't find any. I'm still missing something but I don't give up. As soon as I would have a bit more time, I would go on and post here the results.

    According to the last comment in the thread linked above, it could well be that CVBS support has been re-enabled and I just need to build everything up again with no modifications: it would be my first try though I still want to understand how to successfully apply that patch.

    dtech

    Yes, I already know all of that from my research but my hope was that given, still based on my research, that someone has built older versions (LE7 for instance) with CVBS support, it was possible to do the same with newer ones so to have a let's say 9.0.2-CVBS. I would go for the adapter though it isn't solving the problem but just going round it.

    Absolutely not an issue as already said. The gain achieved is much bigger than the 'hassle' (please note the quotation marks as before!) of needing to disable the auto-update feature. There wouldn't be updates anymore and anyway! ;) I tend to believe that, given that the version stays the same, the updater likes more the official build then it restores it but it's just a wild guess.

    dtech

    First of all, please excuse me for not coming back before and THANK YOU for your effort with building a firmware for the Core and, if possible, even more for your explanations, very helpful as always! I've gone for the quick and easy way downloading the firmware you've built and installing it.

    IT WORKS LIKE A CHARM! The Xbox One tuner is detected fine and everything works. I just needed to enable the CrazyCat driver addon (it is disabled by default as it should be) and the tuner has been detected just fine: all the messages regarding it I could find issuing

    dmesg | grep dvb

    were absolutely encouraging and this was confirmed by configuring Tvheadend server accordingly.

    I have to add that, unlike it happens with the RPi2, even HD contents are viewable with no issues at all (though I still need to test a workaround another kind user has suggested me to solve that issue on the RPi2).

    My testing has been very limited (I just wanted to check the TV functionality and I haven't had the time to go deeper than that) but everything seems fine (not that I didn't expect anything different).

    The only 'issue' I could find is that the auto-update function believes the official 9.0.2 is newer (in spite of the much older compilation date; probably because it prefers official builds, I don't know) and on first boot it downloads the package and restores it. Disabling auto-update was obviously just enough to sort that out.

    What to say? I'm REALLY satisfied! :) Given that you prove to know how to handle these things... Isn't it possible to build newer Libreelec versions? I don't think so, probably because of the Kernel limitation...

    The thread is definitively solved and I think that the official build should be replaced with yours but it isn't up to me to judge. I would come back should I notice anything wrong but I think it wouldn't happen. Thanks again and have a nice day! :)