JMCC

In what pertains to me, better doing it now, since I have not yet done the task of adding a number index to the patches

I think that is a different issue, probably not related to the media framework. Do you experience the same behavior on a fresh Armbian install, without the multimedia packages? If you find some clip showing the wrong behavior that you can share, please do. Otherwise, we cannot look into the issue. All my clips are playing fine in different screens and resolutions.

Do you think the patches could be ported to one of our RK3399 kernels?

Remember that our kodi-addons-full package installs all the libretro cores for Kodi retroplayer. However, it is a known limitation that cores needing 3D acceleration (N64, PSX, PSP, etc.) don't work with the built-in Retroplayer, you need to use a external app. Are you having any problem with the Armbian N2+ image? I used the Focal-Current image for a while, and worked perfectly at 2.4GHz. Only had some graphical glitches if you tried to enable Glamor, due to a lack of maturity on the Panfrost driver for S922X's Mali G52.

Can you give us some example stream that is showing this behavior?

...and a different api than Amlogic meson vdec, correct? And all the developers that were working on the meson driver are off the grid since early 2020, is that correct too? I'm asking this just to evaluate the challenges I'll have to face before moving on to create a unified Kodi for Armbian mainline, which was my original idea once I brush up the last details for the legacy Kodi's. BTW, you mentioned it is necessary to use Kodi patches too. I was aware of the FFmpeg and kernel patches, but thought that vanilla Matrix would work. What are these patches related to? (Sorry for hijacking the thread, I can move these posts to a different one if it gets too messy)

Incorrect. You can have an excellent Kodi experience on Armbian, if it is compiled properly. We have it working for Rockchip and Odroid XU4 so far with the Legacy kernels. Sunxi Mainline is in the to-do list.

That's what all of this SBC thing is about.

You are not missing anything. That is the normal process for kernel developing, things don't work at the first try normally. You already saw that the patch applied correctly, but the changes made by the patch are causing some compilation error. It worked when jernej applied it, but now there is something causing trouble. So the next step is look at the logs under output/debug, see what failed, and try to fix it. Have fun!

As I said above, you must look at the list of applied patches, and see jernej's patch at the end, if it applied OK or failed. Patches from the userpatches directory are applied at the end, and the script marks them with a "u" in the output. The message you read later is simply saying that you did not make any additional changes after applying the provided patches, and therefore it will continue. On the contrary, when you make some additional changes, it will create a new patch with the changes you made. Enviado desde mi moto g(6) plus mediante Tapatalk

The build script, after git checking out the kernel sources, will apply the patches. All of the applied patches will appear in order, with a green indicator when they are applied OK and yellow or red when there is some problem. Though, since the text moves so fast, you probably didn't notice it. The easiest way to check how the patches are applied is to add the option CREATE_PATCHES=yes to compile.sh. It will make the script pause twice, first after applying the u-boot patches and then after the kernel patches. You can see if your patch was applied correctly, and troubleshoot if not. Simply open the commit in GitHub, and then at the address bar add ".patch" at the end.

The easiest way is using some disk tool to resize the partition. In Linux, Gparted will do the job. For Windows, I'm not sure, probably minitool partition wizard. Enviado desde mi moto g(6) plus mediante Tapatalk

What? Why don't you use the Armbian Build Script? That is what all this project is about! Applying a patch is as easy as putting it on the corresponding folder under "userpatches", or either use the command line option "CREATE_PATCHES=yes" in case you want to apply it manually.

No support for anything other than Armbian Yes, I realized it recently. Only 32-bit userspace will have Widevine DRM. I thought to make Kodi run in a 32-bit docker container, but there is no ETA for that project.

I would try two things: Manually insert the module with "modprobe tv", just ot see it it there. In the thread you link, the user mentions that his TV out works with jernej's OpenELEC, by doing these modifications to the fex file. You can try that, just to make sure your cable works. For last, you can try directly with our current Mainline kernel, using the suggestions in the thread linked above

I just enabled the 1.5Ghz OPP for legacy. The board is clearly the fastest RK3328 I've used so far, most probably due to good emmc and memory, plus great thermal management. Due to the good thermals , I dared to dial down just a few uV from our standard 1.5Ghz OPP patch (1425000 instead of 1450000). I tested it extensively and found it stable. Reducing it to 1400000 caused some occasional instabilities.

Same here, I got my Station M1 and built a Buster Legacy Desktop image with no problems. But for some reason, they are not present for download, nor in the archive.

@Werner How about changing this topic title, or splitting all posts except the very first ones to a new one, calling it "Station P1/M1 Board bring up"?

Let's do it P.S.: Not a big fan of ZSH so far. I installed it on my Ubuntu PC, and it all just looked like an unconfigured BASH, needing plenty of work to make it useful. I guess the Armbian version comes pre-configured, I'll give it a chance in some near future.

Buster-Legacy images for Station M1 are not being built, even though they are in targets.conf @Igor Any idea what could be happening?

Then it is not related to the buster multimedia framework, bit something else. Your dmesg shows a USB webcam and cheese. Try without that device.

It sources /etc/armbian-release. When any update changes this file, motd will change the board name displayed.

This thread seems to give a working solution for recent kernels (pay attention to the post from jernej dating of today, 2021/01/18): You can try the old image, which should work easily with a small modification in the boot files. Use this method: https://docs.armbian.com/Hardware_Allwinner/#fex-outdatedunsupported-informational-only If it works, then you can try to make an image with a patched current kernel. No idea, I've never used AV out on my OPi+2e. However, I remember some reports that in certain OPi models the image is too bright/washed out, because of a missing filter in the schematics. That can be solved by adding a 50 ohm resistor in your cable. Not sure if it applies also to your board. Reference: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=3404

Some day I have to test this ZFS. I'm too attached to the good ol' EXT4

IIRC, AV out used to work with the old legacy kernel. You can try this image, and in case it is disabled by default, you can probably enable it by editing the fdt file: https://archive.armbian.com/orangepipc/archive/Armbian_5.90_Orangepipc_Ubuntu_xenial_default_3.4.113_desktop.7z Enviado desde mi moto g(6) plus mediante Tapatalk