Last filament used on one Pi changes filament for new job on second Pi

[TLBradbury]

Describe the bug

Steps to reproduce

1. Print a job on primary networked Pi.
2. Load a new job to second networked Pi.
3. Selected filament is the same as the first Pi even though it was not the last used on this instance.
4. Print confirmation dialogs help prevent logging filament usage to the wrong spool.

Expected behavior Filament usage should be tracked in database, but should not impact selection.

Did the same happen when all other 3rd party plugins are disabled? Unknown

Log file octoprint-logs.zip

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Would be nice if Filament Manager and Spool Manager could both network and share databases (not the same one) the same way. Both plugins should sort spools for exports so exported data can be easily compared between instances. Probably a little more important on Spool Manager since they can't share a database and manual updating is needed to sync.

[ericus256]

Sigh... I hit this too and was hoping it was just something configured wrong (since it wasn't really clear how to get the second/third/etc Octoprint instance set up to pull from the main database so I kinda had to guess a bit) but it looks like it might be an actual bug or oversight.

This (almost) makes it pointless to use a shared database, since simply changing the spool on the secondary printer forces the other one to forcibly change to the same spool (EVEN when it is mid-print) and then the accounting happens on the wrong spool once the print completes.

As stated by @TLBradbury above, this would probably be fixed if the database simply kept track of quantities remaining per spool, instead of apparently also tracking "loaded spool". The latter just doesn't make sense since the purpose of the database is (almost certainly) to provide a solution for multiple printers, right?

See also #111