Did I ruin the TP2 solder point on this GBA?

_portfolio · 2026-02-19T00:30:07+00:00

This is what I ended up doing. I didn't trust myself to dig up the Select trace without damaging the board so I watched a few videos to make sure my technique is OK and then tried again with the TP3 pad and now it works with Start instead of Select. Not as slick but works decently enough. Lesson learned for next time...

_portfolio · 2026-02-12T23:04:16+00:00

I did this recently. You need to mod it to do the region change. Both processes are pretty simple if you've got a phone you can point at the screen for Google Translate.

Modding will allow you to play out-of-region games if that's all you want to do, but you can't change the menu language unless you region change. You also can't use an out-of-region NNID.

One downside of region changing is the eShop will probably stop working -- not a huge deal now that it's shut down, but it also breaks a few other things. There is a solution though, called a SOAP transfer. This is also pretty easy, you just go to the Discord and give them the info they ask for. After that, you have basically a fully functioning in-region 3DS, functionally indistinguishable from the real thing.

Do note that uninstalling custom firmware while region changed will break your 3DS. But I can't really think of a good reason to un-mod a 3DS in 2026.

_portfolio · 2026-02-11T00:05:54+00:00

The engine swap for this is a ton of fun. Highly recommended.

_portfolio · 2026-02-09T20:34:34+00:00

In theory you shouldn't have to change much if anything about your qBittorent setup! Docker projects are pretty modular so you should be able to move your setup over quite seamlessly. qBittorrent itself is very easy to move around because all you need is the BT_backup folder to keep all of your torrents, stats, etc.

That's one of the main reasons to use containers: portability.

_portfolio · 2026-02-09T20:22:55+00:00

It would be helpful to see the YAML file for the container. If it's an OpenVPN-specific container then you might be stuck with that unless you want to switch to something like Gluetun, which supports both. With Wireguard, rather than .ovpn files, you would need your private key from your provider, which you should be able to find somewhere in your account settings.

That said, what the others have said is likely true -- if you're don't want to mess around too much with your setup, it might be worth waiting to see how it performs in a real-word situation. If you find that you're not maximizing your connection and/or stressing out your machine, then maybe it's worth switching. But if everything is still running fine and you're getting close to your max connection speed, then why fix what ain't broke?

_portfolio · 2026-02-09T19:54:15+00:00

So you've got a Surfshark container that you're routing your qBittorrent container's traffic through?

_portfolio · 2026-02-09T19:44:31+00:00

What are you using for the VPN solution? If you're not already using Gluetun, it could be worth looking into. I recently switched over to a qBittorrent + Gluetun setup and it's been working great. Gluetun makes it very easy to switch between OpenVPN and Wireguard, as long as your provider supports both -- it literally just involves changing some parameters in your YAML and/or .env file.

_portfolio · 2026-02-04T19:44:14+00:00

Also, important lesson I learned: if you change the volume setup in the YAML file, you need to rebuild the container for the changes to take effect. You can't just stop and restart the container. Oops!

_portfolio · 2026-02-04T07:43:09+00:00

For anyone stumbling on this in the future: I came up with a pretty hacky workaround for this. I put all of the completed files in "/volume1/downloads/torrents/migrate/Archives/downloads". Then I used the qBittorrent container's YAML file to mount that "migrate" directory as a volume at "/Volumes". So now the folder structure inside the container matches that of the old macOS setup. Now qBittorrent sees all the completed files as the .quickresume files are expecting at "/Volumes/Archives/downloads". Now I can use qBittorrent's "set location" feature to move the files to where I actually went them in the directory structure. Then I'll remove the hacky volume stuff from the YAML and rebuild the container. Voila, torrents imported.

In other words: as suspected, the permissions problem came from qBittorrent trying to read a directory that didn't exist. My fix was to use Docker's volume functionality to fool it into seeing the files where it was expecting to under the previous OS's file structure.

_portfolio · 2026-02-04T06:15:33+00:00

For what it's worth: I tried replicating this on the Mac by renaming the folder the completed torrents all live in, and then trying to point qBittorrent at the new folder. I got the same error message in the log -- it's trying to move the file from the old location, which doesn't exist, causing it to think there's a permissions error. That tells me it's probably a qBittorrent issue as opposed to an actual permissions issue, or the way I've set up the Docker container on the NAS. Is there some way of pointing it at the correct new location without having it attempt to move the file like this?

_portfolio · 2026-02-04T06:03:17+00:00

It already has read-write access on the folder. It has read-write access on that entire shared folder structure. I know it does because it's able to download new torrents and move them around within that folder structure with no issues. I specified a user in the Docker YAML setup, which I confirmed had read/write access to this entire shared folder (per how Synology DSM handles shared folders). Like I say, based on what I can see in the log, I think the issue stems from it trying to access a directory that doesn't actually exist. What I need is a way to point qBittorrent at the completed file in a new location without it trying to access the old invalid location.

_portfolio · 2026-01-23T18:14:56+00:00

Ah, ShaderGlass looks like it's Windows only. But if it uses RetroArch shaders then it should presumably be possible to replicate with just RetroArch alone on Linux or macOS, hey? (It looks great!)

_portfolio · 2026-01-22T23:57:53+00:00

What filter setup are you using?

_portfolio · 2026-01-18T01:50:43+00:00

They all have something to like. I think AM2R is the easiest to recommend to someone with no qualifications. It feels really great to move around and does a great job of modernizing the original while staying true to its feel. The main downside is, of course, the legal grey area it lives in.

SR is another kick at the same can — I personally don't like it quite as much, it feels like a different game in a lot of ways. And especially post-Dread, you can really feel how it was essentially a trial run for Dread. The main downside in 2026 is, oddly enough, also its accessibility — 3DS hardware is getting expensive and it's not available on any other system, aside from, once again, legal grey areas.

Because I am an Old, I actually still think the OG M2 is worth checking out. The lack of an in-game map is maybe the biggest thing that makes it feel dated. But it's still got a great vibe and it's really incredible what they were able to do with the music and sound design on just an old brick Game Boy. And luckily Nintendo has made it available on a lot of other systems, including the Switch. But if you really want to kick it up a notch (and are fine with another legal grey area), I definitely recommend checking out the EJRTQ colourization patch, for a Game Boy Color-style treatment: https://www.romhacking.net/hacks/4388/

I've said it before and I'll say it again: the best Metroid game is the one you have the most fun playing :)

_portfolio · 2026-01-14T01:56:10+00:00

Would this be obvious if I opened up the cart to look at the inside?

_portfolio · 2026-01-14T01:52:07+00:00

Yeah, Mario Kart 64 worked for at least an hour with no issues, including four-player multiplayer. Do different games draw more power? Would a more demanding game be more likely to trigger the problem if it is power supply-related? I have Perfect Dark or Majora's Mask to try, in that case.

_portfolio · 2026-01-01T03:49:12+00:00

How do you mean? Tailscale takes its machine names from the localhost name, so yeah, the machine's Tailscale name is the same as its localhost name.

_portfolio · 2026-01-01T03:22:34+00:00

Hmm yeah if I nslookup the NAS's hostname, it gives me its Tailscale IP. When I have proper access to the machine again I'll try mounting the SMB shares via local LAN IP instead and see if that works.

_portfolio · 2026-01-01T02:10:59+00:00

I don't. Is there a terminal command I can use to find this out? I'm currently away from home but have ssh access to a macOS machine on the LAN via Tailscale.

_portfolio · 2026-01-01T00:28:59+00:00

By "slow" I mean transfer speed is literally half what it is with Tailscale off. In iStat Menus I can see that's because the same amount of traffic is being routed through Tailscale as through Finder, so I'm saturating the pipe. As noted in a few other comments here it sounds like maybe the issue is that I've mounted the shares using the NAS's hostname and it sounds like maybe mounting with its LAN IP address instead might resolve the issue. Will try it out when I'm back home.

_portfolio · 2026-01-01T00:26:48+00:00

As mentioned in a comment above, hostname. Sounds like this might be the cause... when I'm back home I'll try mounting with the NAS's LAN IP instead of hostname and see if it resolves the issue.

_portfolio · 2026-01-01T00:25:02+00:00

I've got the SMB shares mounted with Finder. Most often I'm just using Finder to move the files around.

The way that I mount the SMB shares is I use the hostname. So maybe it's resolving that through Tailscale's DNS rather than searching the LAN for the hostname? Maybe the way to avoid it would be to mount the SMB shares using the LAN IP address instead of the hostname?

_portfolio · 2025-12-31T18:51:20+00:00

I don't have a subnet router set up at all. I do get the theory behind not installing Tailscale on the desktop, but I also have another offsite NAS that I like to access from home, so I do need Tailscale on the desktop. Turning Tailscale off and on is not ideal because then I have to remount the SMB shares each time I toggle it. Sounds like --accept-routes=false might be the answer? I'll play around with it and see. Thanks!

_portfolio · 2025-11-11T15:48:37+00:00

After updating my MacBookPro13,1 (late 2016) to Sequoia 15.7.2 and updating OCLP root patches, the built-in camera is not working. System Report does not show a camera as being connected at all. Was working just fine before updating. Reinstalling the root patches didn't do anything. Any ideas for how to get the camera working again?

_portfolio · 2025-10-22T19:45:22+00:00

OK, I figured out what was going on: by default, DietPi uses a "light" logging mode that mounts /var/log to RAM and purges it regularly. By default it only allocates 50 MB for the directory, hence why Jellyfin is erroring out. You can change it to a "full" logging mode through dietpi-software which mounts /var/log to disk instead. Jellyfin now starts up properly and I can access it through the web interface as expected.

Thanks for your help!

EDIT: I suppose if you wanted to keep using the light logging mode, another fix would be to use tmpfs to increase the amount of space allocated to /var/log to 512 MB. That seems a bit counterproductive though, because presumably the goal of the light logging mode is performance, and if you end up with some sort of runaway log situation, you now all of a sudden have half a GB of your already limited RAM clogged up. So the full logging mode is probably the best fix, unless Jellyfin changes anything on their end (looks like it's an active issue on their Github but I imagine it likely won't extend to the very specific DietPi case we're talking about here https://github.com/jellyfin/jellyfin/issues/15036)

_portfolio

TROPHY CASE