chodeus

Oh awesome! Please let me know if you notice anything broken in the stable, that is my priority. I’ll be doing some tweaking to get things looking how I feel they should look but it won’t be anything drastic, just minor OCD things now that everything appears to be working. Once I’m ready for testing the compose addition I’ll let you know. I’ll 100% take on the suggestions you have just provided. I hope to include proper compose support and container auto start sequencing as per what is visible (and this setting off for those using compose).

This is where I have got to with my version today. Can’t imagine there’ll be any drastic changes in the next week as I’ve got family staying with me. I’ve started looking at the container start order working as per the folder order and container order in each folder. And I’ve started looking at folder view2 ignoring containers with the label ‘composeman’ Again, if anyone is willing to try out my stable/makn fork of folderview2 you can find it on page 14. As it’s vibe coded, I’m trying hard to ensure I don’t make any breaking changes which is why I’m being careful with the container startup and composeman integration. I’m really lucky because the original folderview that Vlados folderview2 was forked off was written pretty well!

Since I'm modifying Vlado's folderview2 and making it functional, I'll see what I can do about having it ignore docker autostart order if composeman is being used. My issue is, I have little interest in loading a compose manager to test it. If I can implement it I'll keep it as a beta until someone is brave enough to test it. It has been a while since I was on Unraid v6+ but I believe scolcipitato's folderview plugin's autostart procedure modified Unraids container start order as per the positioning of the container in the folder. I don't think this works with Vlado's version but I can also look at this too.

I don’t use compose so I apologise for my ignorance. I see a few different compose managers, do they all overwrite the Unraid docker container start up? Do they fundamentally function the same and just appear different? From the screenshots I’ve seen it looks like the compose managers almost do what folderview does as far as organising the containers. Are you wanting folderview2 to ignore the container start up order if compose is installed?

So they do work well with each other but the start order between the compose plugin and folder view cause conflicts. Thanks for jumping on and running that test and highlighting that. Hopefully the other people running compose can see this.

Yeah I would like to but I feel like I need a docker compose user to test my version before I do that. I’m still surprised to read that not all users are on Unraid v7+.

I believe this is only fixed in one of his betas, I’m not sure which one because I never ran it. This is fixed in the fork I modified though. If you’re wanting this resolved I’ve explained what I have done here. https://forums.unraid.net/topic/189167-plugin-folderview2/page/14/#findComment-1606306

To be fair, the dev that started this thread hasn't posted in a few months. If you're running the version from the community apps store you'll be coming up with quite a few issues.

Okay perfect. Do you use folderview2 with compose? Can you verify what the above person wrote is not a bug and just user error? Unfortunately I don’t have the luxury of a test rig.

I don’t use compose but do you not need to create the folder first? Also “latest version” doesn’t help sorry, I need to know your version number.

Just to be clear, this is nothing to do with your custom css or anything you’ve modified? I don’t use folders for VMs because I only have the 1 VM but if this is something broken in folderview2 I can have a look.

Looks good!

That’s pretty cool! Thankyou. If you notice any bugs that aren’t relevant to your customer css please let me know!

Yeah mine looks a lot better than your first screenshot but it could do with widening a little bit for other people that don’t have a custom CSS. Yours looks really good! The CPU and Memory load column heading like my screenshot. This was taken on my phone.

Mine auto updates so yes yours should too. I’ll make that fix and repackage and update tomorrow sometime! Nice work. Your heading of the column is missing.

I’m glad you’ve found it functional! That’s the main thing I was trying to achieve.

Ah yes I see, what sort of device did you take that screenshot on? I find things look a little worse on my phone but on PC and iPad it looks much better.

Okay cool. I am curious to hear how you go with your modified css file. You’ve done well with that plugin because the mover tuning is a beast! I’ll do what I can with this plugin. I’m only really interested in fixing what is broken but if I have time I’ll entertain feature requests. I just don’t want to break the plugin 😂

With my settings it is fine, what docker folder settings have you got toggled? If you want to try my branch you can use a link to update to it. Worst case, uninstall folder view and use Vlados link or the partially working Community Apps version. Just remember, always backup your docker.json and vm.json and any other files you have modified. As far as maintaining this, I’ll keep updating my fork and capturing changes against Vlados repository in hope that someone that can actually code picks up the whole lot. I just wanted to get the plugin back fully functional. If there’s anything else broken let me know and I’ll see what I can do!

Use the link again now, I had just resolved this build issue I noticed after restarting my server. Then copy your docker and vm.json back. You should then be on version 2026.02.05. Edit: again, can confirm, it’s all back 100% functional again after server reboot. Sorry about that!! Anything else you notice please let me know.

I had some time to test out my Claude Pro/claude code free trial so I decided to fork the main branch of Folder View 2 and start playing. My intention was to fix the current issues and add a couple of improvements that annoyed me. Note: Some of these fixes may have already happened in the beta branch. In doing this I/Claude have kept an updated changelog to highlight exactly what was changed and how in an effort that maybe Vlado could review what I’ve done and look at incorporating it themselves if they come back. I’m currently running my vibe coded update and it appears to be running well. I had some confidence I wouldn’t break anything as I reviewed each change Claude submitted. I mean no disrespect to Vlado vibe coding this but I have little confidence someone with actual skills was going to pick this plugin up. I’m not sure if sharing my repository is the right thing to do but here is a screenshot of the versions I have tested and currently using. Like anything I vibe code, I did this for personal use but I figured there might be some people out there this might interest. If anyone has an interest in giving it a go you can find all the info + screenshots in my fork of Vlados repository. NOTE: I’m running Unraid 7.2.3

Would it be worthwhile to start flagging issues on the GitHub instead of in here? Issues · VladoPortos/folder.view2 This would be easier for tracking if @VladoPortos returns or someone is able to fork this project and take it over.

Yesterday I setup the Mover Tuner as per Trash’s guide and I set dry run to true and ran a “move now” on the plugin and fclone repaired hardlinks. I thought nothing was suppose to happen in a dry run? It also stopped qbm and didn’t restart qbm at the end of the run. Unraid 7.2.2 and the CA latest version of the plugin. Has anyone noticed this behaviour before? Today I’ll run another test as per the schedule I have set and see what a “normal” run is meant to do.

This has been mentioned many times for the stable release. It has been resolved in a beta release that you can find in the first post.

I used this script, thankyou for sharing! It appears we are waiting for Vlado to find time or someone else with the skills and time to fork and continue on the project.