Glassed Silver

@KluthR The needed change for the debugging command you want us to insert has to go into /usr/local/emhttp/plugins/appdata.backup/pages/content/settings.php Probably a difference between the published version everyone else is using and you using a dev environment? Either way, I redacted the resulting file to include just one container that doesn't belong to any group as a baseline and then all containers of my MariaDB group. I noticed that the sort order isn't stored in ANY item in the unredacted file either, I wager that the order saving method must drop the actual writing, but I don't know. Anyhow, here goes nothing: abdebugPOST_redacted.txt

As of version 2024.03.17 which is the latest unless my AppData Backup updates broke it sadly is still an issue. Past a certain point adding containers to existing groups nor rearranging them in there works. Maybe you have to hit some kind of threshold, I can't really tell. I have 114 containers, 3 groups in which are 14, 5 and 3 containers. unRAID: 6.12.10 Browser: Firefox for Android Beta, always the latest version from when I first encountered this to now. Funnily enough I just tried changing the order in one group and that only caused the last item in that group to drop out rather than rearranging anything. In that case I tried moving an item to the very bottom, below the item that instead disappeared that was the last one before the move attempt. At least only that group was affected by that odd behavior, the bug didn't cascade to other groups. Naturally the groups serve a purpose, so I'm going to hold off on trying to move anymore.

Sounds like something you'd be able to expect on a paid OS accessed mainly through Web UI in 2024. Of course, I prefer to work on my unRAID instance on my tablet with a high-res screen, but it's my phone that I have on me at all times and I OFTEN need to work on unRAID from it. Maybe a neat thing to add for unRAID 7 or one of its dot releases?

@KluthR can you please consider looking into this? You probably missed the post, but the issue still persists, at least it does for me. This COULD be related to both Spiritreader and me having a lot of containers. Maybe folks with fewer containers than some unknown amount aren't affected? Just guessing since that's something they and I have in common if that helps. Thank you so much for such a configurable plugin though! The only thing I'm missing otherwise is a way to save incremental using rsync I guess.

Would it be possible to create docker tags for sub-versions rather than just specific sub-sub-versions? Meaning a catch-all tag for 10.9 would get 10.9.0, 10.9.1, etc... as they are released. This means you could mostly target a specific API and feature foundation and get your regular bug fixes as well. I know Jellyfin isn't very good at not causing breaking conceptual changes even at dot-dot releases, but I suck a lot at manually updating and this way it'd be a happy middle-ground of bug fixes coming in soonish and not sitting on an old build for too long but also not updating before I clear that a point-release works with my accompanying tools.

Did you figure something out? I'm having the same issue and feeling a bit weirded out this one went unaddressed for so long.

@Squid I'm really sorry to ping you, but I haven't found any comment from you on the docker update notification spam situation so far (maybe I didn't use the search correctly or used the wrong terms, idk...) Is it an issue you're aware of and that we can expect a fix for some time soon-ish? I don't think FCP really needs to check on any of my docker containers, I auto-update a lot and I also manually update some of them all on my own, if we could exclude that check, that'd be so helpful, especially as it would decrease the processing needed. Getting daily notifications about some dozen or so containers having an update available at a given moment is very unhelpful since it buries any possible errors that are left unseen since I notice myself just swiping away all of my Pushover notifications in bulk sometimes when I don't have time for minor stuff like that. In any case thank you so much for this wonderful plug-in!

Fair enough, but then how do I get it to download a version that's not rather old? latest gave me version 102, which happens to be what Debian's repo has. Okay, I just investigated. Apparently you use the FF ESR/Thunderbird ppa, that one only offers 102 as latest for Thunderbird. It'd be nice if you could make it an option to use their thunderbird-next repo instead through a variable. However it's nice to see you don't rely on Debian for the main third-party packages that supply reliable repos themselves. Other than that, thank you so much for the container.

Any reason why the Thunderbird container doesn't let me pick unstable? The Debian repo might not be the best source to reference for packages that need to be very up-to-date... I'd suggest adding the Mozilla repo apt repo and sourcing from there upon every reboot of the container rather than pulling from Debian. Being stuck 14-15 versions behind is no laughing matter when you try to be using the latest release and unstable is unavailable as a tag. And if it's not too much to ask, do you have any plans to switch to kasmvnc over novlc?

I don't have the GPU Stat plugin and get this error logged anyhow. Since unRAID primarily works off a web UI and is typically extended by running heaps of plugins that seem to rely on this setting being set correctly, probably preferably higher than what it's set to by default I'd suggest LimeTech to look into this a little closer. I recently re-did my docker config since I switched from a btrfs vdisk to folders on a ZFS cache pool and the more dockers I added back from my stored templates the slower the UI got, and I bet this has something to do with it as well. I have over 90 dockers (before anyone feels an itch: I'm not here to justify my setup, you will not see me entertain this discussion...) unRAID's web UI HAS to scale better with large needs, this has been an issue for years now and as you extend your use cases for unRAID the UI punishes you much for it.

Could it be none of your dockers use br0?

Probably a good idea to post this into a dedicated thread if you ask me. off-topic/rant: The longer I am on 6.11.5/6.12.x the more I wish I had heeded the cautious lessons of MACVLAN issues and remained on 6.9.2 until resolved, That being said, a few weeks ago I didn't know I'd get a Fritz!Box router...

Sure, those definitely are aspects that still need to be worked on, but this lifts ZFS from a very difficult to plan for FS for homelabbers who are attracted by unRAID's unique selling points to something that makes it workable where the remaining hurdles are a lot easier (and cheaper) to mitigate. It most certainly is 80% of the way. Way more than a little if you ask me.

A little? This is in my opinion the ONE change most homelabbers will have waited for if they want to expand as they go rather than moving, recreating pools, keeping money invested in drives that you wouldn't need storage-wise, etc... I for one am ECSTATICb and cannot wait for this to land in unRAID. Glorious times, the single-most imporant feature I've been waiting for for sure for unRAID.

More eyes = more bugs found. Beta tests and RCs are done by few people, gold releases are done by everyone except for the few who are cautious.