$ ffmpeg -i file1.m4a -acodec copy file1.aac
$ ffmpeg -i file2.m4a -acodec copy file2.aac
$ cat file1.aac file2.aac >> filenew.aac
$ ffmpeg -i filenew.aac -acodec copy -bsf:a aac_adtstoasc filenew.m4a

A number of years ago I attended the ARRL Teacher's Institute. In addition to some amazing instruction, we received some amazing gear to take home and play with. One of these was a PicoScope 2204A digital oscilloscope. I was pleasantly surprised to discover that they support the Debian family of Linux distros.

I'm sure I'm late to the party, but I recently started delving into MySQL variables. It may or may note help with the problem I'm currently dealing with, that of excessively lengthy queries.

I lost track of when Apple started using the High Efficiency Image Format (HEIF/HEIC) for iPhone photos. In my house, we typically look at our photos on a TV connected to a Raspberry Pi running the Kodi (Formerly XBMC) media center which doesn't natively support HEIF images. After some digging, I discovered that you can install the HEIF image decoder add-on from the command line:

After all these years (can't really remember when I first discovered it), I'm still using MacPorts. It's actually become more useful on my aging (obsolete?) MacBook Pro 2012, which is frozen in time running MacOS 10.15 Catalina. I'm now using macports to run both apache2 and php 7.4 on this development machine, and I sometimes forget how much I rely on it, even though it's such a PITA when upgrading the OS. In addition to php itself, I need to use macports to install libraries & dependencies as well. Here are those that I'm currently using.

As a Mac user, my primary client for mysql database management (when I'm not using command-line tools) has been Sequel Pro (formerly Cocoa MySQL). Now that Sequel Pro has been abandoned, I figured I might as well try out PHPMyAdmin, especially considering that's what most web hosting portals use.

This guide assumes you already have a functional apache2/mysql server running.

Installation on my Ubuntu web server via the command line was trivial. First, ensure that all repositories and packages are up-to-date:

Just saw that the new Raspberry Pi Zero 2 W (2nd generation, Wireless) has been released. It's equipped with a quad-core CPU, but the RAM is still limited to 512MB. I began to wonder if it may be time to start migrating all of my Kodi-equipped Raspberry Pi 4 models to the zero, but the RAM could be a bit of an issue. Digging into the benchmark tests, I realized I don't have a central record of useful RasPi tools, so here it is.

First off, it's useful to know what you're Pi is running. The following command will provide details of about the CPU.

$ touch -t <YYYYDDDDHHMM>
$ touch -t 201106301416
$ touch -r <from_file> <to_file>

I've been stuck on PHP 7.1 for my Drupal-based sites because, for some unknown reason, upgrading to PHP 7.4 results in a server Error 500. This problem stumped me for a while, but I've recently found a work-around. I wouldn't exactly call this a "fix", but I'm hoping to upgrade to Drupal 8 (or 9, or 10), so I'm willing to live with a patch or workaround. Anyway, it turns out that the error was being caused by the following line in the settings.php file:

Many things irritate me, so take this post with a grain of salt, but I hate the fact every significant MacOS update breaks my development environment. The latest was a security update to Catalina, MacOS 10.15.7. I have learned to test things out (Apache/PHP/MySQL) immediately after these updates, and I discovered (again), that Apache was broken. Now, admittedly, this is because I am using a different version of Apache from the one distributed by Apple, and installed using MacPorts. So I guess this is just something I have to live with.