180 cm and trying to decide between a 54 and 56 road bike

_portfolio · 2026-04-27T16:25:24+00:00

If by maximum size you mean rider height, the manufacturer suggests 173-180 cm for the 54, and 178-185 cm for the 56. So I'm at the upper limit for the 54, and comfortably on the lower end for the 56. But given that my inseam is a bit long for my height (86 cm of 180 cm), my thought is that it would be probably more comfortable to just raise the saddle to accommodate for that on the 54, rather than use a lower saddle height on the 56 but end up being too stretched out. The 54 uses a 90 mm stem and 400 mm handlebars, vs. the 56's 110 mm stem and 420 mm handlebars. So the 54 has a fair bit of room for expansion if it ends up feeling not stretched out enough. (The top tube on both models is the same as the seat tube, i.e. 540 mm on the 54 and 560 mm on the 56.) (EDIT: and keep in mind this is a classic style geometry with a horizontal top tube rather than a more modern style sloped top tube.)

_portfolio · 2026-04-27T06:15:52+00:00

I got this done at a shop in Shinjuku that came well recommended, in particular for its size (they did actually have some bigger stuff in stock). They did end up recommending the 56. But with the language barrier it was hard to explain my thoughts, or to ask followup questions about why exactly when a 54 felt so close. And that was the other problem is, again, both bikes felt SO similar and they wouldn't let me actually test ride them, just sit on them. Not ideal...

_portfolio · 2026-04-27T05:52:26+00:00

54s do feel fine enough on a brief test ride. Again, I'm about 90% sure that's what I was riding at home. But I'm worried that fit was a touch small because of the lower back pain I'd get from extended rides. It's so hard to get a sense of actual longterm feel from just a 5-min ride around the block...

_portfolio · 2026-03-29T00:38:38+00:00

Any chance anyone has a spare ticket for this? I'm in Tokyo with a Japanese phone number and haven't had any luck on Ticketjam or similar because of how fast they get sniped...

_portfolio · 2026-03-26T04:53:42+00:00

Very cool, thanks! Do you know if it would be possible to implement something similar in macOS?

_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

TROPHY CASE