Sorry, you are going to have to be more specific than that. What did not work how? Did Cura crash/stop working when you tried to add instances manually? Did the plugin not connect to your OctoPrint instances? Or did it still connect to the wrong IP? More details, or I cannot help.
If it is all the same to you, please post it now. It should still contain some hints as to how Cura sees the octoprint instances in your network.
Just tested:
Yes, that is what I meant. I assumed that you can get the data from octoprint.
Nevermind then.
The plugin is a real help nevertheless and I appreciate it 
Thanks
Cheers,
dtose
Just as I waited for the time limit to finish for the second post, the print advanced and the timeline synced.
So maybe it's an issue with octoprint at the beginning of the job.
In your screenshot, there is an orange dot next to the 40 minutes estimate. I think there's a tooltip when you hover over it, that shows that OctoPrint is not yet very sure about that number. It could be that the Cura plugin uses a different way to estimate during this "orange phase" than OctoPrint. Once the dot becomes green, the times should match up.
About the time, what OctoPrint displays there is also artificially fuzzied. Stuff between 35min and 45min (IIRC) will report as 40min. This is to make clear that this is an estimate, not an exact number (as "00:41:35" does). You can disable that via Settings > Appearance > Show fuzzy print time estimates.
Thanks for your help @fieldOfView and @foosel
You are absolutely right.
After disabling the fuzzy print time, the estimated print times are exactly the same.
@foosel
Am I right in supposing that the fuzzy print time tries to compensate for long tasks in the gcode (I watched the timer stand still while the printer was performing a mesh bed levelling and continue afterwards)?
Well, in a way. It really is more a psychological thing. Estimates are estimates. They are inaccurate, and more inaccurate the further out they are. There's no difference between an estimate of 35min vs 44min - it'll be so inaccurate in most cases that it'll boil down "40min give or take". If I leave it at 00:36:42 people will however consider it buggy behaviour already if the print takes 00:38:21. If I just say "40min" it reflects the inaccurate reality better.
See also this comment:
To bring this back to the topic of the Cura plugin: the fuzzy formatting happens in the OctoPrint interface. The API provides a non-fuzzy-looking number, and that is what Cura gets and displays. So that explains the difference.
Exactly! Sorry, should have added that 
I have to apologise to you.
I started from basics and checked each pi and the two in question did have the same network name in raspi-config. I had changed a different file based on a google post and it was wrong.
It is now working properly and I feel a bit of a plonker.
Thank you for your time and great work and sorry for not checking that first.
With best wishes,
Andrew
Could I ask you to be more specific again? Does it now work with manually added instances, or did changing the hostnames also fix it with the automatic discovery?
That is quite unnecessary. For the record, I think the plugin should work even if a plonker like yourself ( ) has not configured unique hostnames. So I consider this a bug in the plugin. But it helps to know how I can reproduce the issue so I can fix it.
Unique hostnames on any network should be considered as something just important as unique IP addresses.
I would like to second the request to control the destination folder in OctoPrint. If the plugin could use the default folder that was selected/created in OctoPrint prior to CURA passing the file to it would be awesome!
As I said before, the hardest part here is the user interface for it.
Where would you like to select the folder? I am quite limited to the number of things I can easily add to the user interface in Cura. There are hoops I can jump through to add anything I want basically, but that makes the plugin much harder to maintain (and a new version of the plugin would have to be made for each new release of Cura).
So I am hesitant, but open to suggestions of how this feature would look. Can you draw me a picture?
I understand the possible headaches. I've attached a couple screen prints.
One screen shot shows OctoPrint starts in its root folder. Thru OctoPrint I used “Create folder” to create a folder called MakerMask.
The other screen shot, I have clicked on the MakerMask folder. Now, when I manually upload a .gcode file, it goes to the MakerMask folder. Files go to MakerMask until I hit the Back button to the root folder.
What I’m hoping is that after I manually select the “MakerMask” folder in OctoPrint, the CURA plugin would send files to the current selected folder.
Thanks for considering this!!!
OctoPrintRootFolder|690x373
I understand that you want to select a folder; what I was asking for was how you think it should look in Cura. Cura does not "know" which folder you have selected in the OctoPrint web interface.
And for the record, neither does OctoPrint's backend. Folder selection is purely frontend, and that's also not going to change. The only thing that OctoPrint knows which file might or might not be selected for printing, but not what is currently in focused in the file list.
That does present a challenge. When the "Print with OctoPrint" button is clicked, could there be an option to manually enter the folder name?
