Archive for category PC Tweakage

Wyze Cam vs. Xiamoi-Dafang Hacks

The Wyze Cam is a surprisingly inexpensive camera firmly lashed to the Wyze app, with no provision for ordinary IP camera streaming. It seems to be a generic camera with custom firmware and, unsurprisingly, one can commandeer the bootloader with different firmware from a MicroSD card, thereby adding missing functions and suppressing undesired actions.

Oddly, buying a genuine Wyze Cam directly from Wyze isn’t significantly more expensive than a generic from the usual eBay / Amazon sellers. Bonus: the legit camera arrives next week rather than in a month or two.

I found one of my few remaining 2 GB MicroSD cards, formatted it with a 512 MB (!) FAT32 partition (per the suggestions), set up the “custom firmware” bootloader, and installed it with no issues.

Installing the new firmware requires copying a directory tree, configuring the WiFi SSID and password in the usual wpa_supplicant, and rebooting. Works fine and, yeah, the camera now runs Linux.

I told the router to assign a known IP address to the camera’s MAC address, set up port forwarding for port 8554 to that IP address, put the camera against the storm window in the kitchen, and rebooted everything to get it working:

Wyze Cam in kitchen window

Wyze Cam in kitchen window

Unfortunately, while it works more-or-less well with browsers on the local network, it’s apparently inaccessible from outside. The router manages a DDNS name-to-IP mapping to make itself findable, the port is open, the forwarding seems correct, no image data arrives to browsers outside, and they eventually time out.

Changing to port 8080 doesn’t help, nor does using MJPEG instead of H264 encoding.

Even more unfortunately, the router doesn’t do hairpin connections (inside to outside to inside), so I can’t debug this mess from the Comfy Chair.

This is a placeholder for what I’ve done while I accumulate more knowledge …



Troubles in PC Land

So this happened:

Dell Optiplex - SSD failure

Dell Optiplex – SSD failure

As far as I can tell, the Crucial M5500 SSD in that PC (an off-lease Dell Optiplex 760) stopped being a SATA hard drive, although it seems to work OK when jammed in a USB adapter.

So I picked up a new-to-me Optiplex 9020 with Windows 8.1 on an SSD, shrank the partition, tried to install Xubuntu 18.04, fat-fingered the UEFI password dance, reinstalled Windows from the SSD’s recovery partition, and got this display after a while (clicky for more dots):

Dell Optiplex - recovery disk stall

Dell Optiplex – recovery disk stall

After letting it stew in its own juices during supper, I forced it off (pushed the power button until it died), restarted, got through the UEFI dance, and it now seems All Good. I made recovery DVDs (remember DVDs?), both before and after the fumbled Xubuntu installation, but didn’t need them.

I expect we’ll never boot Windows 8.1 again, but it’s there Just In Case.



LibreOffice 5.3+ vs. Adobe Type 1 Fonts

LibreOffice from 5.3 onward (Xubuntu 18.04 uses LO 6.0) no longer supports Adobe Type 1 fonts, which comes as a surprise to those of us who actually bought fonts, back in the day, and have been using them ever since. Apparently, Windows dropped Type 1 font support some time ago.

Based on some hints, I set up the Adobe Font Development Kit for OpenType. It’s a Python thing, preferably running in a virtual environment to avoid screwing up the rest of one’s system with bizarre dependencies. It seems one (“I”) must not update pip using pip after installing python-pip using apt-get; recovering from that mess was good for another hour of flailing.

The default AFDKO installation spat out an error message about ufolib (I am not making this up) being at 2.1.1, instead of the required 2.3.1. In for a penny, in for a pound, I updated ADFKO with the “prerelease” option:

pip install -U afdko --pre

Which fetched ufolib 2.3.1, apparently from wherever Python keeps its prerelease stash. I have NFC what’s going on with any of this.

An Adobe blog post on the AFDKO tx tool suggested it can convert Type 1 fonts to CFF (a.k.a. Adobe Type 2) fonts and some poking around suggested CFF also figures in OTF fonts.

tx -cff -n -N -A awb_____.pfb
--- Filename: awb_____.pfb
--- FontName: ACaslon-Bold
tx: --- awb_____.pfb
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) unhinted
tx: (cfw) There are 222 additional reports of 'unhinted'.

The -A option replaces the bizarre Adobe 8.3 file names with actual font information:

awrg____.pfb ⇒ ACaslon-Bold.cff
awbi____.pfb ⇒ ACaslon-BoldItalic.cff
awi_____.pfb ⇒ ACaslon-Italic.cff
awrg____.pfb ⇒ ACaslon-Regular.cff
awsb____.pfb ⇒ ACaslon-Semibold.cff
awsbi___.pfb ⇒ ACaslon-SemiboldItalic.cff

Regrettably, CFF files don’t actually work as fonts, at least as far as LibreOffice 6.0 (or whatever it uses as a font engine) is concerned.

Although it’s possible to convert fonts locally with fontforge, doing it one-by-one is tedious and the learning curve for its Python scripting feature seems rather steep. I fired the most vital fonts at Convertio, an online converter running fontforge in the background, got a matching pile of OTF fonts, and installed them in /usr/share/fonts/custom/type1 to indicate their heritage.

Whereupon LO rammed into a problem I’d had before. The solution this time required sorting the various Caslon and American Typewriter fonts into different “font families” and forcing the TTF names to match their new families. The difference between Medium and Regular seems to have Gone Away.

I should just use Comic Sans and be done with it …


SANE Scanner vs. Xubuntu 18.04

I recently bumped the desktop PC with the scanner from an old Mint to Xubuntu 18.04, which killed a day with all the system and UI tweakage.

The old guides for setting up a networked SANE scanner became inoperative with systemd ruling the configurations, so, after some flailing around, I found a newer guide referencing a guide for USB scanners and pointing to a deeper guide for network sharing in the age of systemd.

The USB guide points out the existence of Access Control Lists for the various device files, which I didn’t know was a thing. AFAICT, you must still be in the scanner group for remote access to happen.

I lost track of the changes during all the flailing around, but it definitely didn’t Just Work.

I’m sure all this will change before I must do it again.


Amazon Basics AA Cells: Capacity

Being that sort of bear, I (sometimes) note the date on cells when I change them, as with this notation on the AA alkaline cells in the Logitech trackball:

Amazon Basics AA cell - mouse runtime

Amazon Basics AA cell – mouse runtime

These Amazon Basics AA cells lasted almost exactly two years, compared with 15 and 20 months from the previous two pairs of Duracell AAs. A few months one way or the other probably don’t mean much, but the Amazon cells aren’t complete duds.

The new Amazon Basics cells have a gray paint job, so they’ve either changed suppliers or branding.



Toshiba 3 TB Drive Format & Speed

A new Toshiba Canvio Basics 3 TB drive has two partitions:

sudo fdisk -l /dev/sdb
Disk /dev/sdb: 2.7 TiB, 3000592979968 bytes, 5860533164 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 575F7910-3F93-4FC5-B50F-7D1F05810EE6

Device      Start        End    Sectors  Size Type
/dev/sdb1      34     262177     262144  128M Microsoft reserved
/dev/sdb2  264192 5860532223 5860268032  2.7T Microsoft basic data

Partition 1 does not start on physical sector boundary.

The “Microsoft reserved” partition is new to me. It’s apparently not a real partition, but a dumping ground for Windows disk management information.

The drive is a classic Black Box:

Toshiba 3 TB USB drive

Toshiba 3 TB USB drive

It comes with no specs, other than the tediously qualified “3 TB”, and the Toshiba web page shows only a 5 Gb/s = 625 MB/s “Max. transfer rate”.

A quick test slurping data from the Sandisk video-rated MicroSD card extracted from the Fly6 camera shows it can write data at a sustained 21 MB/s:

time rsync -ahu --progress /mnt/Fly6/ /mnt/part/test/
sending incremental file list
             33 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=29/31)
             14 100%   13.67kB/s    0:00:00 (xfr#2, to-chk=28/31)
        499.32M 100%   21.61MB/s    0:00:22 (xfr#3, to-chk=21/31)
        497.75M 100%   20.95MB/s    0:00:22 (xfr#4, to-chk=20/31)
        499.06M 100%   21.31MB/s    0:00:22 (xfr#5, to-chk=19/31)
        278.10M 100%   21.48MB/s    0:00:12 (xfr#6, to-chk=18/31)

... snippage ...

real	6m26.272s
user	0m55.900s
sys	0m25.496s

That’s with the card jammed into an Anker USB 3.0 adapter and both devices plugged into the two USB 3.0 “Super Speed” ports in the front of my desktop box. Plugging them both into the adjacent USB 2.0 ports drops the data rate to 18 MB/s.

The Sandisk card claims read-write speeds of “up to” 20 MB/s, so it’s the limiting factor.

Getting reliable performance numbers is surprisingly difficult:

dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random.bin
4177526784 bytes (4.2 GB, 3.9 GiB) copied, 214.064 s, 19.5 MB/s 
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 214.922 s, 19.5 MB/s

dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random2.bin
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s  
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s

Obviously, prying bits out of the random number generator limits the overall write speed.

Zeros, however, are cheap and readily available:

dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null.bin
4169138176 bytes (4.2 GB, 3.9 GiB) copied, 23.0091 s, 181 MB/s
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.1775 s, 181 MB/s

dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null2.bin
4093640704 bytes (4.1 GB, 3.8 GiB) copied, 25.031 s, 164 MB/s 
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 25.7781 s, 163 MB/s

But the caches take a while to drain, even after the command returns:

time ( dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null3.bin ; sync )
4118806528 bytes (4.1 GB, 3.8 GiB) copied, 23.0004 s, 179 MB/s
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.5305 s, 178 MB/s

real	0m35.887s
user	0m0.008s
sys	0m4.824s

Dividing 4 GB / 35.9 s says the mechanical write speed is close to 110 MB/s.

Reading proceeds a bit faster, while also running up against the effect of the many caches between the spinning platter and the screen:

time ( cp /mnt/part/random.bin /dev/null )
real	0m36.565s
user	0m0.048s
sys	0m1.712s

time ( cp /mnt/part/random.bin /dev/null )
real	0m29.157s
user	0m0.036s
sys	0m1.800s

time ( cp /mnt/part/random.bin /dev/null )
real	0m10.265s
user	0m0.028s
sys	0m1.040s

time ( cp /mnt/part/random.bin /dev/null )
real	0m0.608s
user	0m0.004s
sys	0m0.600s

time ( cp /mnt/part/random.bin /dev/null )
real	0m0.590s
user	0m0.008s
sys	0m0.580s

time ( cp /mnt/part/random2.bin /dev/null )
real	0m31.035s
user	0m0.056s
sys	0m1.816s

time ( cp /mnt/part/random2.bin /dev/null )
real	0m31.024s
user	0m0.052s
sys	0m1.860s

Unsurprisingly, copying a brace of 4 GB files in parallel takes twice as long as each cold-buffer read, so disk’s raw read speed seems to be around 130 MB/s.

The drive’s write speed won’t be the limiting factor while saving camera video data!


Xubuntu 18.04 vs. VNC

For unknown reasons, the Gnome-ish vino-server package for Xubuntu 18.04 no longer installs vino-preferences, so it’s not obvious how to configure the server.

After considerable flailing, I installed good old x11vnc, set up a password, then started it in .xprofile:

x11vnc -forever -find -no6 -avahi -usepw

I don’t mind having programs change, but it’d be nice if features like, say, configuration wouldn’t just vanish.

Leave a comment