This one worked which the other one did not, albeit requiring gnu sed, but that's what 99% of users are running anyway.

It's not about one driver, they all do this randomness, and they do it randomly. However, I have I believe finally found a way to somewhat link the device port to the xorg ID more conclusively, I'll have to update this post once it's verified as stable and working. There is no 'group' that dictates this stuff, it's just each driver and whoever develops it. Welcome to the real world behind the scenes of computing and Linux and the BSDs, LOL.

Thus the -z filter feature.

Updated, --prop is what I'd use since it only has the data I want, and is supported xrandr 1.2 and newer. Thanks for finding this oine, this was one of the longer standing weak spots I'd found and the CONNECTOR_ID is what I needed as well.

This takes a lot of research in my experience, testing, etc, very time consuming. I found EasyTag to be toxic for tags, and avoid even opening a tagged file in it, outputting the full comments using metaflac or whatever much safer, and also more predictable. I did a lot of viewing of that raw data when doing the initial testing, but sadly with digital media, there's always more you don't know, particularly related to tags and image embeds. Very poorly designed, bad specs, bad implementations, and horrible player support which nullifies most of what you learn since not supported usually.

Oh, that's valuable, I never looked at a --verbose option. Thanks. That also outputs the EDID data in string form. That can be parsed if you know how to do it, though you can normally get EDID directly from /sys if it's drm. I may look into using this to get a better match as well. I believe wayland uses the drm port ID but not positive.

It would be more useful to note which tags don't get copied. I did a lot of testing with images, and I found that the only images that have consistent support are the main cover images, everything else has such inconsistent cross player support it wasn't worth spending time on it. But for this stuff, note which don't rather than some don't, since that does not narrow it down very much. I'll poke around with - map 0 but would be useful to know the type of image that did not transfer. Even better provide a flac sample.

Compositors (and in particular desktop effects they allow) are almost always the cause of such slowdowns and draggy screen actions, so first step to debug is always to disable any desktop effects and ideally the compositor. I stopped using those ages ago, they just add resource consumption and do nothing of positive value for your desktop imo. Obviously not possible with wayland. Though desktop effects to me should always be disabled no matter what. That includes stuff like transluscent windows etc, you'll find your experience much peppier without that stuff.

Check with /proc/partitions. If main drive shows that number, it suggests the kernel is receiving that data from the drive, and can't help but show what it's been told. The partitions however were made on the drive, so they would show the real size. Data reported by hardware can be and often is wrong or misleading, but the kernel doesn't correct it in most cases. You can also check this in /sys/block/sdc/size but it will show the same thing. You'd be amazed at how much bad data hardware reports to the kernel, it's quite random. If those sources are right, then it's a bug with lsblk.

Make sure to disable compositors if you run any in i3.

Sorry, I was unclear, meant needed to watch in real-time. I recall that the scrollback was not big enough, but I can't say I use screen much, but that was the issue I had with it for certain purposes. I believe it can be adjusted but I recall the upper limit being too low for my needs.