I should do this sometime, but so far everything's fine for me in Google-land sans RCS since I chat over SMS with so few people.

Much like true blacks over in T311, this was a matter for config.txt, namely commenting out dtparam=audio=on, so it now in total looks like:

Well, I'll deal with this later, it's #Freezerburn time ;)

Wait, did I already run into this and find a workaround in T137: Pi 3b HDMI out doesn't do pure black, goes grey instead? Yes, I did! Phew!

Sometimes getting decent enough speeds:

$ speedtest
Retrieving speedtest.net configuration...
Testing from TekSavvy Solutions (104.246.230.74)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by O-NET (Olds, AB) [193.25 km]: 21.987 ms
Testing download speed................................................................................
Download: 416.51 Mbit/s
Testing upload speed......................................................................................................
Upload: 94.61 Mbit/s

Well it's definitely faster at least:

Success, perhaps! New modem took a few tries to find non-packetlossy frequencies but now seems fine?

Got a new modem, the CBN CD8000. Now following https://help.teksavvy.com/teksavvy-faq/post/update-your-hardware-with-mysavvy-zcEJYLC0x7hpQvB

I should really get this done ASAP because Freezerburn is coming up sooooon!

mpv seems nicest to actually control in some ways:

Okay so this is driving me insane.

Judging by https://forum.f-droid.org/t/rcs-supported-message-sms-mms-app/13423 and otherwise ironically Googlin' around it really doesn't seem like there's any options for RCS chats that aren't in fact less trustworthy than Google. So the choices are actually either to fool Google or to give up on RCS I guess?

FJÄLKINGE shelf (https://www.ikeaddict.com/ikeapedia/en/Product/50221688/ca-en/fjalkinge-shelving-unit-white/Entry/)

• shelf clips part number 131295

Or maybe

This is starting to be more of a problem the more I try and run you-know-what...

Once installed, cvlc works for the self-compiled version, though also it just works fine with, say, vlc -I dummy --fullscreen --loop --no-mouse-events --no-keyboard-events --video-on-top --no-osd --mouse-hide-timeout=1 videos/some.mp4. But . . . it still visibly pauses. Arghh!

Reckoning that maybe I was just running things wrong, I've decided to install the possible-abomination I've compiled.

Running in a terminal session unfortunately doesn't seem to really benefit either very much, but VLC's CPU usage is maaaaybe even lower, and it seems entirely viable and so could bypass the need for even something like openbox (which I'm mostly using to avoid polluting the shell init for testing, but this means it could easily be a systemd service for the production approach).

Okay, actually I wayback machine'd it, which points in turn to https://code.videolan.org/videolan/vlc/-/issues/549 which in turn points to https://code.videolan.org/tguillem/vlc/-/tree/gapless-mr which was set to maybe be merged into VLC 4.0 . . . and maybe it still will be, but 4.0 isn't out yet anyways.

Got back at this, decided to try to run just direct invocations of video players that have hardware decode on the Pi.

Current status:

• OS: Ubuntu Server 24.04 (latest LTS, so good for at least another 4 years, and I keep it up to date entirely automatically)
• Nextcloud: Updated all the apps and updated the core to version 29.0.14, the latest non-.0 release of the second-latest Nextcloud version as of last I was touching this . . . but actually since then there's been a version 31. And looking now, I see at https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule that 29 is nearly EOL already:

Should still upgrade a bit more but this is mostly fine now.

https://www.pygame.org/docs/ref/image.html#pygame.image.frombuffer lists only a few pixel formats that can be used, basically all just RGB variations.

Hmmm a note in https://forums.raspberrypi.com/viewtopic.php?t=244975 (which I haven't yet read all of) implies that perhaps I need the color profile set to BGR in the videos to avoid costly CPU decoding, maybe that'll do the trick?

Just noticed it died, lets say about 19:00 to 28:00 then for 9hrs on just this portable USB battery pack, certainly couldn't power it on its own for the full weekend then but that ain't bad.

Hitting the key a bazillion times didn't make it any slower, so it's just rendering generally slow I guess. I might need to work out a more efficient way using the hardware decode of the Pi3 or such . . .

Trying to reencode for the Pi2 to be able to handle: for i in *.*; do ffmpeg -i "$i" -c:v mpeg2video -qscale:v 1 "../1080p-mpeg2/${i%.*}.mpg"; done

I absolutely just gave up on the bulk downloads and just manually downloaded each of the mere 14 titles I "own" on Amazon's Kindle platform.

Yeah I think that's it, in standard "JavaScript devs reinvent wheel but badly" it doesn't seem to try to do the postinstall step and so it doesn't show that the same problem is happening.

Mysteriously, a subsequent bun install seems to have worked? Or maybe it just died in a way where it doesn't realize it needs to try again, because

Okay so to download my Kindle books I could use https://github.com/treetrum/amazon-kindle-bulk-downloader, that in turn requires using bun which . . . appears to be yet another NodeJS package manager? Fantastic, that'll definitely work, it won't immediately fail like every other time I've touched the NodeJS ecosystem.

https://next.content.town/p/kindle-drm-deadline-is-approaching yeah yeah I should do this already

Last report from my parents is it was working well enough for them to set it to SiriusXM and leave it. Waiting to hear any further issues but shelving this for now...

Amos version (with existing text):

https://open.spotify.com/track/1GG6FA9iuU8cWiVHkrGyd2?si=33f2baac4e044afe might be another case, or a different case...

Huh, once I had finally remembered enough times to get past all the "hey, wanna replace this config file with an updated default one?" prompts I'd always say no to, including the final one to remove obsoleted packages, it booted back up into Ubuntu Server 24.04 just fine (well, after switching over the php8.1 mod enabled in the webserver to 24.04's php8.3).

The current stable News app needs at least PHP 8.2 itself, so upgrading the server itself to 24.04! Fingers crossed it doesn't go too wrong!

Well, Redirect “/nextcloud/nextcloud” “/nextcloud” gave me /var/www/owncloud/.htaccess: Redirect to non-URL, and RewriteRule “/owncloud/owncloud” “/owncloud” has changed nothing (I didn't bother yet looking up the syntax to make sure I'm doing that right though, I have a headache anyways!).

So far so good...

https://www.driveuconnect.com/support/software-update.html has the updates . . . except the downloads aren't there anymore and they expect you to use wifi, which it doesn't have I'm pretty sure.

Apparently the dealership attempt to fix it was by attempting to upgrade to version 21 of UConnect. They didn't even accomplish that.

Looking at the logs, I got the section name wrong. So I've changed it to:

... it's still OOM-killing the mariadb service

The conf got loaded on reboot, so in theory it's all good, but I should perhaps give it some more swap or RAM (and probably disk space?)

https://mariadb.com/kb/en/systemd/#configuring-the-systemd-service led me to doing this: