manuti

My default workstation. Soon it will be deserted on those small notebooks for summer time.
 
Usually there is, little but not much, random clutter around: papers, cables and boards. Core testing and debugging infrastructure is on the right side. Under the table I have two fix mounted and easy accessible USB powered hubs, which serves as powering and debug. Half ports have secured 1.5A per port. 14 ports in total, connected to server and shared around the network. Powering via extended USB3 hub proved to be enough in most cases, for rest and for special cases I use their original power supplies. which are somewhere below, differentiated with colours. Than there are 15 gigabit and 5 fast Ethernet ports and 2.4G AP. Since I am software developer first and tinkerer second, 40" of property is central point of interest. Sometimes it also get too small and also to avoid more cables, I have another fixed 19" in debug section. On the top of folder shelves I got an extremely low noise build server and another cabinet of electronics stuff. Lower left cabinet is place for small desktop computer and printer, while right side is filled with various parts, from cables, bigger boards, soldering equipment, hard drives, etc. Most of cables are hidden / embedded, to make this mess manageable. When I don't play with boards, I move cabinets in upper level and make use of whole table (minus keyboard and mouse).

In case someone is looking to add an Emby media server to their Nextcloudpi with hardware accelerated transcoding, I made a step-by-step guide here: 
 

A good read.
I've learned something. I didn't know the ethernet and usb share the same line. The thing is even crappier than I thought.
I would also have complained (a lot) about their ancient ddr2 RAM chips. I find this the biggest flaw in the design of the 3B+. The SoC is so bottlenecked by this that even at OC of 1.5Ghz, it performs very badly on ram dependend tasks. 

The thing is just one collection of design flaws. I don't know what was going on while they were designing the 3B/3B+. They were clearly not concentrating on their work.
Either they don't have good testers, or they just don't listen to their concerns. All these issues should have been fixed after the first tests.

I still love my 2B, and still use it often. That's got advantages towards other sbc's(power efficient, no throttling, much more stable, ...) I still hope they're going to do better with the next one. But for now I'm going to use my RK3399's and dream of the Odroid N2.
Great job, thanks.

I agree.  The 2B is the one I use when I have to, the 3A+ at least represents the SoC's physical reality.

YESSSSSSSSSSSSSSSSSS!!!!! Thanks it works !!

One of the more honest Raspberry Pi ... today I think the RPi 3A+ is more decent, honest and humble with the user.
I complaint about the bottle neck longtime ago  https://raspberryparatorpes.net/dudas/el-cuello-de-botella-de-la-raspberry-pi/ in Spanish of course.
 

Check this post:
 
Maybe is that you are looking for.

Yes. is completely and always in Spanish, the XFCE GUI and the Terminal. You can check here https://raspberryparatorpes.net/comandos/armbian-en-espaol/ but I repeat also just below.
 
The steps are:
 
1. Remove and reinstall the locales from the Terminal / console / CLI:
sudo apt-get purge locales sudo apt-get install locales 2. Configure the locales choosing Spanish, es_ES UTF-8:
sudo dpkg-reconfigure locales 3. Confirm that everything is OK using locale command:
locale   If some line is not es_ES.UTF-8 you must change doing:
export LANGUAGE=es_ES.UTF-8 export LANG=es_ES.UTF-8 4. And after that regenerate the locales:
sudo locale-gen es_ES.UTF-8 5. And finally install the language pack for the common apps like LibreOffice and Firefox:
sudo apt-get install libreoffice-help-es libreoffice-l10n-es firefox-l10n-es-es

Welcome!
 
Avoid Banana M3 at all costs. Besides that, all three other devices are good, depending on your budget and how good of a deal you can get.
 
Probably Nanopi M4 is still a bit immature on the software side (too new), but if you plan to use it in the long term, it's a good choice.
 
XU4 is rather old, but it is still a great computer, and software support is excellent. Plus, now you can find it very cheap. I recommend buying in Ameridroid and adding a emmc module.
 
Tinkerboard S is a great machine, with very good software support too. Though, you'll need to find a very good microusb cable for powering, which is not always easy, and also this board will probably be the most expensive of the three.

It's easy and works for all the Orange Pi and pc
run the following script
enter the exact text below in a terminal (as root)
# /etc/init.d/resize2fs start wait 1 minute
reboot
login
and again as root:
# /etc/init.d/resize2fs start and check with:
# fdisk -l Than you will see the partition has the size of the whole sd card
I did it already with a bunch of systems, not hundreds but 40-50...
hans f4vsj
 
 

Well, while this is called a "Video Processing Unit", the thing is : there's a LOT of video file formats out there. Which mean, a lot of different parameters and decoding/decompressing methods, based on the format used. (I mean, there are different formats and there are "different" for a reason...)
All the VPU I know are specialized in decoding a few formats, at most : H264, H265, VP8, VP9, ...
 
For each format, the VPU must be configured to access external data like : The current frame, the configuration of the current stream (Width, Height, Bytes per pixel, Color format, ...), the different decoding tables if any (e.g. CABAC tables for H26x), ... .
The amount of external data and configuration vary from format to format, knowing that some formats can also have "sub-formats" (H264 is a good example of this madness) which require more or less parameters.
 
So, yeah, VPU are dedicated to a few formats, and for each format, the setup can be completely different. That can be due to configuration registers being mapped at different addresses depending on the decoded format, or the same registers having completely different meaning depending on the format decoded.
 
Note that, in this case, the VPU decode one frame per one frame.
You cannot just "Send the MKV to the VPU, get a video stream on the other end". It *clearly* doesn't have enough memory for that.
Very roughly, the procedure goes as is :
First, the user application must :
Get the first frame of the video stream Send it to the VPU driver Then VPU driver must :
Setup the VPU to decode the frame Launch the VPU decoding process Wait for the decoded result Send back the result to the user application. Then user application :
Retrieves and shows the result, Rinces and repeat for every frame of the video. So, yeah, VPU are not CODEC agnostics. They are CODEC specialized. So the driver is setup slowly, but surely, to decode each format correctly.

I suggest you to buy one of the mentioned 8812AU USB dongles or, if you want to use the embedded WiFi,  a Zero Plus2 H3 w/ Nexmon.
RTL8189FTV should support monitor mode (it's mostly a matter of drivers), but I never tested it so I can't guarantee.
 

Hi all,
 
I wrote a blog post about some of the issues with the Raspberry Pi that you can find scattered around this and other forums. Hopefully it will save us time from repeating ourselves over and over again.
 
As we know, people don't read the forums until it's too late.

https://ownyourbits.com/2019/02/02/whats-wrong-with-the-raspberry-pi/
 
Thanks tkaiser, I took a sample output from your vcgencmd script.

https://pi-hole.net/2019/02/03/pi-hole-v4-2-available-with-shared-memory-new-blocking-modes-and-more/
 
v4.2.1 Hotfix
We have released a small hotfix which addresses possible crashes experienced for users without libcap capabilities
(running FTLDNS under root). For most users, this update will not change anything.
 
HIGHLIGHTS
 
New Blocking Mode
We’ve added a new blocking mode (NODATA), where blocked requested are replied with a status code of NOERROR
and A / AAAA records are empty.  
It’s unclear if there are advantages to this mode over others, but you’re welcome to experiment with it.
 
Shared Memory
In preparation of the new API we are working on, FTLDNS will now store its data in a shared-memory space,
so that the API can come in and read from that memory to fulfill requests.  
In short, this means FTLDNS will be even lighter as it doesn’t have to care about sending the statistics to some requester.  
Instead, it will concentrate on generating the statistics and the API can read FTL’s data directly,
resulting in reduced delays in the API.
 
wpad Vulnerability Fix
We previously mentioned how you could work around a vulnerability regarding wpad entries.  
This fix is now in place as suggested by dnsmaq.conf.example.
 
Fixes And Tweaks
We updated SQLite to 3.26.0
We fixed the query status if a forwarded query was partially replied to from the cache
We now prevent multiple static DHCP entries with same IP
And more…
 
Docker Version Also Updated
We heard your feedback and we made sure to coordinate better to release our traditional install and our Docker install together.
The docker image will be released when testing is complete.

MPP/RKMPP is the RocKchip Media Process Platform.
A set of libraries, made by Rockchip, to communicate with their VPU driver. The thing is done in such a way that the "driver" basically only handle a few things like memory management.
The actual registers of the hardware are known by MPP and are setup by this library, then sent to the driver which almost blindly write the registers values into the hardware, or read them back and send them back to MPP.
Which mean that, even if you have the sources of the Rockchip VPU driver, you need the sources of MPP to understand how the hardware is actually programmed, based on the format you want to decode/encode.
This is the kind of setup which make you wonder, who's the real "driver" ?
http://opensource.rock-chips.com/wiki_Mpp
 
FFMPEG is one the most famous multimedia processing library and tool. This thing can combine audio/video from different sources and combine/convert them into a LOT of formats.
It comes as a library AND as a binary, which is one of the swiss-army knife for Audio-Video processing.
https://ffmpeg.org/
 
MPV is a Media Player, fork of Mplayer2, which use FFMPEG as a backend. It currently have a RKMPP backend to decode video frames using the RKMPP libraries.
https://mpv.io/
 
H264 is a video format.
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
 
The I-frames in H264 are reference (key) frames, from which other kind of frames (B/P frames) will be generated. The I-frame is basically the full frame, while the B/P frames are basically "patches" applied to I-frames to get the new picture.
The "patches" being generally smaller than the I frame, you get one way to "compress" the video (upon various others used simultaneously).
https://en.wikipedia.org/wiki/Inter_frame

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise.  The compromise is reduced with more active participation all around. 
 
Now, who is participating?  
 
-Vendors: Almost every vendor has some software team, or they pay for one.  They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware)
 
-Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc.
 
-Users: buy the board, try our software, ask for/provide help from/to others.  Very important for a project, a bit lacking here.  Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day.
 
Targeting a group in this requires time of its own, but honestly we need the feet on the ground.  It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues.  I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board".  A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. 
 
For other issues that have been a gnawing problem:
 
Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ .  Etc.

Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
 
First off, same nice packaging the Tinker owners are familiar with:
                         
 
The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
 
The reason for the weight becomes immediately obvious when pulling the two halves apart:

All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
 
Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
 
I can't verify (no hardware), but the holes are 85mm apart and threaded.
 
Board fits nicely:
                                 
 
Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
 

 
 
 
My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.

I have H6 DRM patches prepared for 4.20, so you can just copy them over. However, I think you would need some more of them for 4.19. Currently, we're investigating some troubles with HDMI, so it's not stable yet anyway.

Depends on your board. If it's armhf, you can use Raspbian Stretch repos, otherwise you may need to build. I recommend to build from source in any case, I did it once and didn't take long.
 
https://wiki.x2go.org/doku.php/wiki:repositories:raspbian

Thank you guys for your ideas. Until recently I was behind NAT. Therefore I totally removed the DDNS solution from my thinking. But recently I changed my ISP and I'm not sure now if I'm still behind NAT or not. So I give it a try. I would still like more easier (in terms of setting up and maintenance) solution like TeamViewer, but if DDNS is my only chance, I will be glad for it. Thank you @manuti for pointing me at it.

Is there a plan for supporting the "NanoPi Duo2" from"friendlyarm" in the future?
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2

Really depends - the Amlogic S905/S912's are interesting at the moment - some support Android 6, some are Android 7....
 
Rockchip based boards are high performance, but there's some non-technical issues around the Kodi group and Rockchip - so things generally work until they don't...
 
CNX-Software has a good follow-through on TVBoxes...
 
https://www.cnx-software.com/2017/12/26/whats-the-best-android-tv-box-2017-2018-edition/

Old Sunvell R69 just boot with proper microSD card (in my case boot directly with Toshiba Exceria but not but with Samsung or Sandisk).
I'm using images shared in Google Drive from this post 
Sunvell R69 with Allwinner H2+
Running ARMBIAN 5.67 with kernel 4.14.81 
from internal eMMC
HDMI at 1080p 24fps
Wi-Fi OK,
Ethernet OK
 

It probably already works for the box you linked, but if I may suggest, this one already works for sure, it costs just a few dollars more (4/16 model), and has twice the amount of RAM. I wouldn't think twice:
 
www.aliexpress.com/item/A5X-Max-4GB-32GB-Smart-Android-7-1-TV-Box-KD-RK3328-Quad-Core-5G-WiFi/32841541783.html

Now launched Armbian on MVR9 (rk3328), desktop resolution 1920x1080 (so-called 1080p mode). 720p video is normally played in the window. I tried to fill the entire screen - does not fly, but watchable. Launch the browser with YouTube (in normal mode, the video window on the right, a list is available) - all video works without brakes. If you expand to full screen, artifacts slip through. Switched the resolution of the desktop to 720-all video goes to full screen without brakes and artifacts, almost like in LE. Notice that I reworked the body to improve cooling (drilled pen drill for door handle hole above the CPU and did a side slot for the free passage of air (but without fan). If you bring your hand to the hole, I feel like there is warm air from the body.
For information-the system is running with SD card and wired Gigabit network.
By the way, he was surprised that YouTube in the browser at the resolution of the desktop 720 and in the YouTube indicated to use 720, when displayed in full screen (all video options, not only 720) is no problem. But if you switch to YouTube to use 1080 artifacts have already appeared ...