JMCC

Moderators
  • Content Count

    622
  • Joined

  • Last visited

Reputation Activity

  1. Like
    JMCC got a reaction from NicoD in Video : All my SBCs - Specs, why I got them, what the're good/bad for. What's the best for your goal. +30SBCs   
    BTW@NicoD can you send me some link about that small screen you show on the video?

    Enviado desde mi moto g(6) plus mediante Tapatalk


  2. Like
    JMCC got a reaction from NicoD in Video : All my SBCs - Specs, why I got them, what the're good/bad for. What's the best for your goal. +30SBCs   
    Cool one!

    You really hate the Tinkerboard, haha. It was my first SBC, and my unit works quite well (stable at 2 GHz). So I kind of like it.

    Enviado desde mi moto g(6) plus mediante Tapatalk


  3. Like
    JMCC reacted to NicoD in Video : All my SBCs - Specs, why I got them, what the're good/bad for. What's the best for your goal. +30SBCs   
    Hi all.
    I've just finished a long video special where I talk about all my SBCs. In the order how I got them.
    I show the specs of all of them. Say what I like, what's bad about them. What I use them for. What SBC is best for your goal.
    Here's my video, I hope you enjoy it.

    Greetings, NicoD.
     
     
    P.S. : Pictures of anyone else their collection? Mine are not all on this pic, no room for them all. 
  4. Like
    JMCC got a reaction from NicoD in Armbian v20.11 (Tamandua) Planning Thread   
    Hello. Sorry for the no-show at the IRC meeting, got the COVID and that precise day I was moving back to my home after being discharged. I'm better now, thanks be to God.
     
    I have been investigating, and got to make a set of multimedia packages that will work with Buster or Focal. I think it is a good opportunity to close AR-151, and give to users some stable and well-proven multimedia solution, while exploring newer options as Mainline or Wayland for next releases.
     
    The solution would be simply a set of packages, with some base meta-package to install them all, and do the necessary configs. We could then choose to install it at build time, or make it an option in Armbian-config, or just leave it for the user to do an "apt install armbian-multimedia-xxxx".
     
    I think I can have the binary packages ready by the freeze date (this weekend), at least for some boards (RK3288, RK3399 and probably also RK3328 and XU4). @lanefu Do you think we can include it in this release?
  5. Like
    JMCC got a reaction from Igor in Armbian v20.11 (Tamandua) Planning Thread   
    Hello. Sorry for the no-show at the IRC meeting, got the COVID and that precise day I was moving back to my home after being discharged. I'm better now, thanks be to God.
     
    I have been investigating, and got to make a set of multimedia packages that will work with Buster or Focal. I think it is a good opportunity to close AR-151, and give to users some stable and well-proven multimedia solution, while exploring newer options as Mainline or Wayland for next releases.
     
    The solution would be simply a set of packages, with some base meta-package to install them all, and do the necessary configs. We could then choose to install it at build time, or make it an option in Armbian-config, or just leave it for the user to do an "apt install armbian-multimedia-xxxx".
     
    I think I can have the binary packages ready by the freeze date (this weekend), at least for some boards (RK3288, RK3399 and probably also RK3328 and XU4). @lanefu Do you think we can include it in this release?
  6. Like
    JMCC reacted to lanefu in Armbian v20.11 (Tamandua) Planning Thread   
    I'm so glad you are okay.  That must have been traumatizing.  Welcome back!
     
    I owe you a follow-up regarding the rest of your post.
  7. Like
    JMCC reacted to Werner in Armbian v20.11 (Tamandua) Planning Thread   
    Nothing to add here. Welcome back and god bless.
  8. Like
    JMCC got a reaction from Werner in Armbian v20.11 (Tamandua) Planning Thread   
    Hello. Sorry for the no-show at the IRC meeting, got the COVID and that precise day I was moving back to my home after being discharged. I'm better now, thanks be to God.
     
    I have been investigating, and got to make a set of multimedia packages that will work with Buster or Focal. I think it is a good opportunity to close AR-151, and give to users some stable and well-proven multimedia solution, while exploring newer options as Mainline or Wayland for next releases.
     
    The solution would be simply a set of packages, with some base meta-package to install them all, and do the necessary configs. We could then choose to install it at build time, or make it an option in Armbian-config, or just leave it for the user to do an "apt install armbian-multimedia-xxxx".
     
    I think I can have the binary packages ready by the freeze date (this weekend), at least for some boards (RK3288, RK3399 and probably also RK3328 and XU4). @lanefu Do you think we can include it in this release?
  9. Like
    JMCC got a reaction from Gustavo A. Díaz in Rock64: Hardware acceleration with FFmpeg   
    I have plans to incorporate the media packages compilation into the build script. Let's see if I get the chance to do it
  10. Like
    JMCC got a reaction from Tido in Rock64: Hardware acceleration with FFmpeg   
    Currently, FFmpeg only supports HW decoding for rockchips, not encoding. Acceleration on mainline kernel is a work in progress, so I still recommend the legacy 4.4 kernel for video tasks.
     
     
    You need the legacy kernel for these codecs to work. And, again, they are only for decoding.
     
    If you want HW encoding, then you need to use gstreamer with the rockchip plugin.
  11. Like
    JMCC got a reaction from pfeerick in [Development] RK3399 media script   
    OK, you are free to do whatever you want. But this is a thread about using my media script with Armbian legacy kernel. If you want to do something different, please don't discuss it here.
  12. Like
    JMCC got a reaction from NicoD in Odroid C2 general   
    It used to work once upon a time, like 2018-ish. But it broke at some point in the latest legacy images.
  13. Like
    JMCC got a reaction from NicoD in Odroid C2 general   
    Just to be clear: last time I checked, our mainline was using the custom HK blob for the C2 ( @TonyMac32 can you confirm this?). 
     
    Which means that, even though the max frequency is 1.5 GHz, you get the real frequency. Unlike all the other S905' that report 1.5 but are actually running 1.4 GHz.
     
    Now, in order to unlock higher frequencies, you need patches both for the kernel and for the DT. The patches were done for HK's 3.16.x kernel, and it may or may not be possible to port them to mainline.
     
    It is probably not hard. But it needs a person to dive into the old 3.16.x kernel, extract the patches, and try to adapt them to mainline. You're welcome to try, you will for sure learn a lot, whether you finally get to fix it or not 
  14. Like
    JMCC reacted to mboehmer in Odroid C2 on seafloor (part II)   
    Hi all,
     
    as a small status update on the seafloor business, here are some pictures of the new Odroid C2 based instruments which will be deployed in September/October in the northers Pacific.
    Ten modules with different functionality will be deployed, all based on a standard setup of Odroid C2, TRB3sc FPGA based TDC DAQ system, one PADIWA preamp, and a modded mdedia converter serving as a fully configurable mini switch.
     

     
    One of the modules carries several Hamamatsu mini spectrometers, as well as a camera, to observe bioluminescence.

     
    Another module is targeting at muon tracking with SiPM based readout:

     
    I have some more picture of the more "fancy" PMT based modules, but don't want to flood this forum now with too many pictures.
     
    To all of you: thanks for the support you gave us over the last year, and the discussions on specific topics!
     
    Deployment pictures will follow once the modules are in place on the seafloor, 2600m deep in the Pacific (and operational, hopefully, this time we just have a GbE fiber, no serial port...)
     
    See you, Michael
     
     
  15. Like
    JMCC reacted to NicoD in [Development] RK3399 media script   
  16. Like
    JMCC got a reaction from Werner in How attach a text file?   
    When you are editing, you will see below the editor window a section with a paper-clip icon and the text "Drag files here to attach, or choose files..."
  17. Like
    JMCC got a reaction from e97 in [Development] RK3399 media script   
    So finally we have the first version of:
    The UN-official, UN-supported, etc...
    RK3399 MEDIA TESTING SCRIPT
     
    This is the first release of the RK3399 media testing script. The script provides a functionality similar to its RK3288 equivalent:
    Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 3.2 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with:  Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
    Here is a more thorough documentation:
     
    >>> DOWNLOAD LINK <<<
     
    Prerequisites:
    You need a fresh Armbian Bionic desktop image with legacy kernel installed.  
    Instructions:
    Download the file above Untar it: tar xvf media-rk3399_*.txz cd media-script ./media-rk3399.sh  
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!
  18. Like
    JMCC got a reaction from giri@nwrk.biz in NanoPi Neo 2, memory leak in proftpd, even worse if SSL encrypted   
    Okay, let me strongly state that simply installing packages from a different Debian release, or mixing sources from different releases, is a very, very bad idea. It will make your system unpredictably unstable, and probably ruin it. Even with the proper apt-pinning (which is not even being considered in this thread, except for one mention by @tkaiser above) is not a good idea IMO.
     
    If you want to install a more recent version of proftpd or any other package, simply make a backport. Debian makes it extremely easy, and there are different forms of doing it, all of them quick and easy. Like, for example, this one: https://wiki.debian.org/SimpleBackportCreation
     
  19. Like
    JMCC reacted to chwe in Armbian v20.05 (Kagu) Planning Thread   
    IMO as easy as it is.. as long as we've no proper mainline drivers for the VPU stuff and 4.4 allows us to build debian/ubuntu on top of 4.4 without affecting much. we can stick to it..
     
    I assume rockchip will rebase their BSP on something newer in the future (even their most recent SoCs are integrated into 4.4, e.g rk1808 and rk1806) and I don't think they go EOS prior to 4.4 goes EOL. Btw.. all the camera stuff also is a 4.4 only thing at the moment.. and we've a bunch of boards with doublecam ect. now.. for sure something people might get interested in once it works..
     
    So I guess the way to go is base rockchip64 and rk3399 on the same BSP kernel (this release), base both on the same patchset (maybe this maybe next) base all on upstream u-boot (next release - rochchip64 is based on the bsp u-boot) and then we can merge it.. I guess by compile the mali stuff as modules we might get around having Utgard (rk3328) and Midgard (rk3399) in the same kernel.. and otherwise.. we may just have 2 slightly different configs whatever works here.. Or prioritize rk3399 over rk3328 in terms of mali support (we clearly see that more boards based on rk3399 are developed for those usecases - but let's call this the nuclear option.. :D)...
     
    If you feel motivated - go for it. don't let my rants about 4.4 let yourself demotivate.. :D  In general I would be a fan if the buildscript allows a quick way to produce debs for custom packages. And I'll still play with 4.4 for a while anyway cause display and cameras on rk3399 are untouched till now.. and it's on my list to play with..
     
  20. Like
    JMCC got a reaction from chwe in Armbian v20.05 (Kagu) Planning Thread   
    Not if we put all RK3399 boards in rk3399, and all RK3328 in rockchip64. In that case, we could just keep our current kernel config and that would work.
  21. Like
    JMCC reacted to _r9 in [Moderation] Dealing with subtle spammers placing "tiny little ads"   
    So I read through this thread and there are a few thoughts that came up.

    I believe when you want to solve a spam problem efficiently one needs to focus on the spam itself and not on the spammers.
    I'm dealing with lots of spam on my mailservers and manually blacklisting is the least efficient way to solve this problem. In my case 2000 - 10000 Spam mails a month.
    The main reasons why this is not a good practice are already described in a few posts inside this thread. Automated mail creation for example.

    So what are the real problems with spam posts?
    I think the most potential thread, if we focus on security, is that a user could get mislead to a dangerous URL.
    There is also the problem that the Armbian Forum could get misrelated to porn pages or other ugly stuff through google searching or other online indexes.
    Worst case would be if someone types porn stuff into the google search box and gets the Armbian forum as a result
    or someone finds a post that should help him and this post is full off ads. This would harm the forums image.

    So IMO the real problem is related to the URLs the spammers uses. So maybe there's a function like "URL registering"?
    So if a user wants to add a URL which is not known by Armbian he needs to register it with a small form or so and a moderator needs to approve the URL.
    Another concept could be that posts with unknown URLs needs to be approved even if they are changed after a while.
    So the system needs to run the approval recognition not only on new posts but on each change to.

    What's with the existing spam URLs?
    I don't know if such functions exists but if we could run through all posts with URLs (maybe inside the database) and disapprove all posts with unknown URLs then we have a list we can score.
    Moderators would need to approve all this posts again and register the URLs if they are valid. Maybe we should do this with a small amount of posts each.
    So we would need a function like "disapprove the first 100 posts with unknown URLs". May be we could assign each moderator a few posts automatically so he can approve 10 posts a week or so.
    11 Moderators would solve 110 posts a week. I don't know how big the problem is but the year has 52 weeks so we could to a lot of work without really doing anything.

    I'm absolutely new to this forum so maybe this is all nonsense but hiring volunteering spamfilters does not seem to be the smart way.

     
  22. Like
    JMCC got a reaction from TonyMac32 in Armbian 20.02 (Chiru) Release Thread   
    Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent. 
     
    So a big congrats to everyone who took part on it! Great job! 
  23. Like
    JMCC got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent. 
     
    So a big congrats to everyone who took part on it! Great job! 
  24. Like
    JMCC got a reaction from 062621AM in Any remote desktop solution working over Internet?   
    Still, RDP and VNC are not secure enough to open a port directly to Internet.

    I rather suggest x2go, which is much more secure (works over ssh), and also a lot faster. Plus, it allows forwarding of sound, local folders and printers.

    http://wiki.x2go.org

    Enviado desde mi Aquaris M mediante Tapatalk
     
  25. Like
    JMCC reacted to martinayotte in using the RTC connector Nanopi R1.   
    Although the battery connector allows to keep the RTC running while board is powered off, there is no PMIC to control power of the board from some kind of WakeUp Alarm.