Both cbr and cbz are just compressed archives - R for Rar and Z for Zip. The format has got nothing to do with how the images are displayed in a reader application.

If you want any reader to read a comic frame by frame instead of page by page, you’d have to uncompress the file, then cut out each individual frame and give them sensible names (eg. page_39_frame_03.png or somesuch) and then recompress.

Someone else in the thread mention software that can do this, but it might not always work as expected, when the layout is not straight-forward.

mc mirror is a pretty straightforward method of migration. Should work if the other end is S3-compatible.

OpenRouter has free models, but you are severely rate limited until you purchase $10 credits.

I use Ansible to deploy a bunch of containers with intradependencies (shared volumes, networks and settings). One of the containers is homemade with the source pulled from codeberg. Variables are kept in a separate file and passwords in an encrypted one and the whole thing is in a private repo. It is quite flexible.

When I started out converting from compose, I literally asked Copilot for “this, but in Ansible”, which got me pretty far.

Obsidian looks interesting.

Thanks for the suggestion, but it seems like the challenges with Komga would be similar to those when using Mylar. I’ll probably just go for a spreadsheet.

That was my first idea too, but last I checked it didn’t scrape much other than English editions (using Comicvine AFAIR) and had no way of manually adding stuff it can’t scrape.

Scraping metadata. Wish/purchase/pull lists. Keeping track of multiple editions. Perhaps even scraping entire collections/storylines into manageable lists?

At the very least a quick way to use my phone to check if I already have a specific comic when I’m at the store.

Grist might be useful if I end up setting more than a spreadsheet up, thanks.

Thanks for the suggestion. I think that might be too much work for my needs though.

The container sees each volume as a seperate filesystem, regardless of your underlying disk setup and you cannot hardlink across filesystems.

This has huge potential. What I personally look for in a podcast solution is:

• Web/desktop player
• Sync between players (down to seconds)
• Organize subscribed podcasts with folders/tags
• Per podcast/folder/tag settings for “automatically add to queue”
• Some way of dealing with older (backlog) episodes (built-in or via an API)

For now, I’m using Pocketcasts which pretty much does what I need, except for handling the backlog, which I do with a homemade python-script that adds backlog episodes to my playlist whenever it has less than 4 hours of playtime left, using Pocketcast’s web player REST API. The result is an endless playlist where newly released episodes are played within a few hours and older episodes are sprinkled on with no real need for micro-managing episodes in the playlist.

It looks like web/desktop players and sync is already in scope, but are there any “advanced” podcast organization features on your roadmap?

That is not correct. Prowlarr also searches Newznab-compatible providers (i.e. most nzb-indexers).

I had to set this in my config.h (qmk firmware) to have all the LEDs light up:

#define RGBLED_NUM 72
#define RGBLED_SPLIT \
   { 36, 36 }

While the standard Sofle RGB only has 70 LEDs defined.

Yes, but hear me out: