#445 - [GH-ISSUE #675] [Bug]: Virtual Printer in Proxy mode defaults to X1C model — no model dropdown shown during initial creation - starred/bambuddy

Owner

Originally created by @PurseChicken on GitHub (Mar 12, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/675

Originally assigned to: @maziggy on GitHub.

Bug Description

When creating a new Virtual Printer and selecting Proxy mode, the printer model always defaults to X1C regardless of which destination printer is selected. The model selection dropdown is not displayed when Proxy mode is chosen after initial creation, so there is no way to set the correct model at that time.
For example, if you create a virtual printer in Proxy mode pointing at a P1S, the virtual printer will present itself to the slicer as X1C → P1S instead of the expected P1S → P1S. This causes the slicer to see the wrong printer model.

Root Cause (code-level):

backend/app/services/virtual_printer/manager.py:77 — The default model is hardcoded as X1C:

DEFAULT_VIRTUAL_PRINTER_MODEL = "3DPrinter-X1-Carbon"  # X1C

backend/app/api/routes/settings.py:619 — When updating virtual printer settings, if no model is sent by the frontend, the existing (default) model is preserved:

new_model = model if model is not None else current_model

Frontend (/app/static/assets/index-Cd7iXbgg.js) — The compiled frontend hides the model dropdown when Proxy mode is selected. Since the dropdown is hidden, no model value is ever sent to the backend during creation, so the X1C default sticks.
No auto-inheritance — The backend does not look up the destination printer's model to auto-set it when Proxy mode is selected. The destination printer's model is known (it's a configured printer in Bambuddy), but it's never used to populate the virtual printer's model field.

Workaround:

Edit the virtual printer after creation
Switch from Proxy mode to a different mode (e.g., Archive)
The model dropdown now becomes visible — select the correct model (e.g., P1S)
Switch the mode back to Proxy
The virtual printer now correctly shows P1S → P1S

Expected Behavior

When creating a virtual printer in Proxy mode and selecting a destination printer, either:

The model should auto-match to the destination printer's model (preferred — the destination printer's model is already known), or
The model dropdown should be visible and selectable in Proxy mode after initial creation, with the option to override

Auto-matching by default with the ability to override would be ideal if there are use cases where using a different model is required.

Steps to Reproduce

Go to Settings → Virtual Printer
Click Add to create a new virtual printer
Enter a name
Select Proxy as the mode
Select a destination printer (e.g., a P1S)
Save the virtual printer
Observe that the virtual printer shows as X1C → P1S instead of P1S → P1S
The model dropdown is never shown after creation

Printer Model

P1S

Bambuddy Version

0.2.3b1

Printer Firmware Version

01.09.01.00

Installation Method

Docker

Operating System

Linux (Other)

Relevant Logs / Support Package

Screenshots

No response

Additional Context

Only tested with a P1S as the destination printer, but the issue likely applies to all non-X1C models since X1C is the hardcoded default in manager.py:77 and is the first entry in the model list.
Suggested fix: When Proxy mode is selected and a target printer is chosen, the backend could auto-set the model by looking up the target printer's model from the database. The relevant code is in settings.py around line 619 — after resolving the target printer, its model could be used to set new_model when mode is "proxy" and no explicit model override was provided.

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @PurseChicken on GitHub (Mar 12, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/675 Originally assigned to: @maziggy on GitHub. ### Bug Description When creating a new Virtual Printer and selecting Proxy mode, the printer model always defaults to X1C regardless of which destination printer is selected. The model selection dropdown is not displayed when Proxy mode is chosen after initial creation, so there is no way to set the correct model at that time. For example, if you create a virtual printer in Proxy mode pointing at a P1S, the virtual printer will present itself to the slicer as X1C → P1S instead of the expected P1S → P1S. This causes the slicer to see the wrong printer model. Root Cause (code-level): 1. backend/app/services/virtual_printer/manager.py:77 — The default model is hardcoded as X1C: ```python DEFAULT_VIRTUAL_PRINTER_MODEL = "3DPrinter-X1-Carbon" # X1C ``` 2. backend/app/api/routes/settings.py:619 — When updating virtual printer settings, if no model is sent by the frontend, the existing (default) model is preserved: ```python new_model = model if model is not None else current_model ``` 3. Frontend (/app/static/assets/index-Cd7iXbgg.js) — The compiled frontend hides the model dropdown when Proxy mode is selected. Since the dropdown is hidden, no model value is ever sent to the backend during creation, so the X1C default sticks. 4. No auto-inheritance — The backend does not look up the destination printer's model to auto-set it when Proxy mode is selected. The destination printer's model is known (it's a configured printer in Bambuddy), but it's never used to populate the virtual printer's model field. Workaround: Edit the virtual printer after creation Switch from Proxy mode to a different mode (e.g., Archive) The model dropdown now becomes visible — select the correct model (e.g., P1S) Switch the mode back to Proxy The virtual printer now correctly shows P1S → P1S ### Expected Behavior When creating a virtual printer in Proxy mode and selecting a destination printer, either: - The model should auto-match to the destination printer's model (preferred — the destination printer's model is already known), or - The model dropdown should be visible and selectable in Proxy mode after initial creation, with the option to override Auto-matching by default with the ability to override would be ideal if there are use cases where using a different model is required. ### Steps to Reproduce 1. Go to Settings → Virtual Printer 2. Click Add to create a new virtual printer 3. Enter a name 4. Select Proxy as the mode 5. Select a destination printer (e.g., a P1S) 6. Save the virtual printer 7. Observe that the virtual printer shows as X1C → P1S instead of P1S → P1S 8. The model dropdown is never shown after creation ### Printer Model P1S ### Bambuddy Version 0.2.3b1 ### Printer Firmware Version 01.09.01.00 ### Installation Method Docker ### Operating System Linux (Other) ### Relevant Logs / Support Package <removed> ### Screenshots _No response_ ### Additional Context Only tested with a P1S as the destination printer, but the issue likely applies to all non-X1C models since X1C is the hardcoded default in manager.py:77 and is the first entry in the model list. Suggested fix: When Proxy mode is selected and a target printer is chosen, the backend could auto-set the model by looking up the target printer's model from the database. The relevant code is in settings.py around line 619 — after resolving the target printer, its model could be used to set new_model when mode is "proxy" and no explicit model override was provided. ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

closed this issue
added the
bug
label

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

It appears this issue was alluded to in the following issue but there does not appear to be a resolution:
https://github.com/maziggy/bambuddy/issues/564

@PurseChicken commented on GitHub (Mar 12, 2026): It appears this issue was alluded to in the following issue but there does not appear to be a resolution: https://github.com/maziggy/bambuddy/issues/564

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

Wrong branch. Please use 0.2.2b3 and upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

@maziggy commented on GitHub (Mar 12, 2026): Wrong branch. Please use 0.2.2b3 and upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

I changed to 0.2.2b3. Same issue

@PurseChicken commented on GitHub (Mar 12, 2026): I changed to 0.2.2b3. Same issue <img width="706" height="1000" alt="Image" src="https://github.com/user-attachments/assets/1c6a08f6-015b-46ec-b74d-52c8dfe4c03b" />

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

I added what I believe to be root cause in the initial bug report.

@PurseChicken commented on GitHub (Mar 12, 2026): I added what I believe to be root cause in the initial bug report.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

Need a support package.

@maziggy commented on GitHub (Mar 12, 2026): Need a support package.

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

Added to the OP

@PurseChicken commented on GitHub (Mar 12, 2026): Added to the OP

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

First of all we need to fix your network setup. The logs are full of network errors.

2026-03-09 14:06:59,088 WARNING [backend.app.services.bambu_mqtt] SERIAL MQTT disconnected: rc=Unspecified error, flags=DisconnectFlags(is_disconnect_packet_from_server=False)

2026-03-10 11:45:37,964 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]: [Errno 104] Connection reset by peer (type: ConnectionResetError)

2026-03-09 11:21:52,520 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /: timed out

2026-03-08 22:35:49,029 WARNING [backend.app.services.bambu_mqtt] SERIAL Timeout on K-profiles request attempt 3/3

2026-03-08 21:12:41,741 ERROR [backend.app.services.camera] Chamber image: failed to connect to [IP]:6000:
2026-03-08 21:12:41,742 ERROR [backend.app.api.routes.camera] Failed to connect to chamber image stream for [IP]

Also it looks like you don't enabled developer mode on your printers:

 "developer_mode": null,

This is a requirement.

@maziggy commented on GitHub (Mar 12, 2026): First of all we need to fix your network setup. The logs are full of network errors. >2026-03-09 14:06:59,088 WARNING [backend.app.services.bambu_mqtt] [[SERIAL]] MQTT disconnected: rc=Unspecified error, flags=DisconnectFlags(is_disconnect_packet_from_server=False) >2026-03-10 11:45:37,964 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]: [Errno 104] Connection reset by peer (type: ConnectionResetError) >2026-03-09 11:21:52,520 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /: timed out >2026-03-08 22:35:49,029 WARNING [backend.app.services.bambu_mqtt] [[SERIAL]] Timeout on K-profiles request attempt 3/3 >2026-03-08 21:12:41,741 ERROR [backend.app.services.camera] Chamber image: failed to connect to [IP]:6000: >2026-03-08 21:12:41,742 ERROR [backend.app.api.routes.camera] Failed to connect to chamber image stream for [IP] Also it looks like you don't enabled developer mode on your printers: > "developer_mode": null, This is a requirement.

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

Those items seem totally unrelated to the issue at hand.

Regardless the physical printers are in developer mode and have been / are working with bambuddy without issue.

@PurseChicken commented on GitHub (Mar 12, 2026): Those items seem totally unrelated to the issue at hand. Regardless the physical printers are in developer mode and have been / are working with bambuddy without issue.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

If MQTT connection isn't working, Bambuddy cannot determine the printer model from MQTT stream.

@maziggy commented on GitHub (Mar 12, 2026): If MQTT connection isn't working, Bambuddy cannot determine the printer model from MQTT stream.

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

Are you saying that logic does exist in code to detect the printer model today using mqtt?

@PurseChicken commented on GitHub (Mar 12, 2026): Are you saying that logic does exist in code to detect the printer model today using mqtt?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

I'm saying, that debugging a problem on a system that is not running properly, doesn't makes sense at all.

@maziggy commented on GitHub (Mar 12, 2026): I'm saying, that debugging a problem on a system that is not running properly, doesn't makes sense at all.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

BTW: where does the printer name come from? It shows "P1S (45". That looks odd. Please show me a screenshot with expanded selection.

@maziggy commented on GitHub (Mar 12, 2026): BTW: where does the printer name come from? It shows "P1S (45". That looks odd. Please show me a screenshot with expanded selection. <img width="706" height="1000" alt="Image" src="https://github.com/user-attachments/assets/67125d90-f3a5-4fd4-9c23-e2cd6d93881c" />

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

The target printer ip was redacted. It just shows P1S (x.x.x.x). There are two in the drop down list. Both of which are physical printers added to bambuddy:

@PurseChicken commented on GitHub (Mar 12, 2026): The target printer ip was redacted. It just shows P1S (x.x.x.x). There are two in the drop down list. Both of which are physical printers added to bambuddy: <img width="642" height="210" alt="Image" src="https://github.com/user-attachments/assets/c54da061-d6ae-48d7-82a1-044eef14f76c" />

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

Since I cannot reproduce the problem: did you try simple names? Or are there any errors in browser console?

@maziggy commented on GitHub (Mar 12, 2026): Since I cannot reproduce the problem: did you try simple names? Or are there any errors in browser console?

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

Define simple names? Is P1S not a simple name?

So you can follow these steps:

Go to Settings → Virtual Printer
Click Add to create a new virtual printer
Enter a name
Select Proxy as the mode
Select a destination printer (e.g., a P1S)
Save the virtual printer

And it saves properly as the right printer model type? The upper right of the Proxy Virtual Printer that is created shows the correct source\destination model E.G. P1S<-->P1S

@PurseChicken commented on GitHub (Mar 12, 2026): Define simple names? Is P1S not a simple name? So you can follow these steps: 1. Go to Settings → Virtual Printer 2. Click Add to create a new virtual printer 3. Enter a name 4. Select Proxy as the mode 5. Select a destination printer (e.g., a P1S) 6. Save the virtual printer And it saves properly as the right printer model type? The upper right of the Proxy Virtual Printer that is created shows the correct source\destination model E.G. P1S<-->P1S

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

Console warning: Multiple instances of Three.js being imported.

No other console errors or warnings when adding the Virtual Printer.

@PurseChicken commented on GitHub (Mar 12, 2026): Console warning: Multiple instances of Three.js being imported. No other console errors or warnings when adding the Virtual Printer.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

As already said, i cannot reproduce. And it's quite hard for me to debug a system I don't know at all, if you don't provide me the details I asked for. So please send me the screenshot requested.

@maziggy commented on GitHub (Mar 12, 2026): As already said, i cannot reproduce. And it's quite hard for me to debug a system I don't know at all, if you don't provide me the details I asked for. So please send me the screenshot requested.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 12, 2026):

Wait.....you are talking about the proxy card HEADING! OMG....checked the settings all the time. Didn't get that.

Will fix it tomorrow morning and et you know.

@maziggy commented on GitHub (Mar 12, 2026): Wait.....you are talking about the proxy card HEADING! OMG....checked the settings all the time. Didn't get that. Will fix it tomorrow morning and et you know.

BreizhHardware commented

https://github.com/maziggy/bambuddy/issues/675#issuecomment-4048144988

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

Hey man i mean no disrespect, but I literally posted the dropdown screenshot you requested here:

I feel like you are trying to dive into this problem from a troubleshooting perspective (which I can understand) but the problem this bug is showcasing is the fact that it appears your frontend code is hiding the printer selection dropdown when adding a Virtual Printer in proxy mode. When asked specifically if your code looks for \ detects the printer model, the question was not answered thus leading to believe this functionality does not exist.

As I mentioned in the original bug report, it appears the default is hardcoded and because the frontend does not show the selection for printer model to emulate, it defaults to X1C

Digging even deeper, around line 281 in frontend/src/components/VirtualPrinterCard.tsx:

{/* Printer Model - for non-proxy modes */}
{localMode !== 'proxy' && (

The frontend explicitly checks f!=="proxy" — if the mode is proxy, the entire model section (with the "Printer Model" title and dropdown) is not rendered at all. Since it's never rendered, no model value is sent to the backend, and the X1C default sticks.

@PurseChicken commented on GitHub (Mar 12, 2026): Hey man i mean no disrespect, but I literally posted the dropdown screenshot you requested here: https://github.com/maziggy/bambuddy/issues/675#issuecomment-4048144988 I feel like you are trying to dive into this problem from a troubleshooting perspective (which I can understand) but the problem this bug is showcasing is the fact that it appears your frontend code is hiding the printer selection dropdown when adding a Virtual Printer in proxy mode. When asked specifically if your code looks for \ detects the printer model, the question was not answered thus leading to believe this functionality does not exist. As I mentioned in the original bug report, it appears the default is hardcoded and because the frontend does not show the selection for printer model to emulate, it defaults to X1C Digging even deeper, around line [281](https://github.com/maziggy/bambuddy/blob/b3a91d7314bfd3a3d0ef1a749f114fa8d386adf1/frontend/src/components/VirtualPrinterCard.tsx#L281) in frontend/src/components/VirtualPrinterCard.tsx: ```tsx {/* Printer Model - for non-proxy modes */} {localMode !== 'proxy' && ( ``` The frontend explicitly checks f!=="proxy" — if the mode is proxy, the entire model section (with the "Printer Model" title and dropdown) is not rendered at all. Since it's never rendered, no model value is sent to the backend, and the X1C default sticks.

BreizhHardware commented

Author

Owner

@PurseChicken commented on GitHub (Mar 12, 2026):

An even more elegant approach could be to just detect the selected printer model and use that as the printer model to emulate. Then no dropdown would be required. Although I am not sure if other users have use cases where they would want a different printer emulated than what they actually have as a physical printer.

Seems possible maybe in backend/app/api/routes/settings.py 664

Add the auto-match inside the existing proxy printer lookup block, right after target_printer_serial is set:

            # Auto-match model from target printer when no explicit model was provided
            if model is None and printer.model:
                reverse_map = {v: k for k, v in VIRTUAL_PRINTER_MODELS.items()}
                matched_code = reverse_map.get(printer.model)
                if matched_code:
                    new_model = matched_code
                    model = matched_code  # Ensure it gets saved below

Setting model = matched_code is important because the save section only writes the model when model is not None:

if model is not None:
        await set_setting(db, "virtual_printer_model", model)

@PurseChicken commented on GitHub (Mar 12, 2026): An even more elegant approach could be to just detect the selected printer model and use that as the printer model to emulate. Then no dropdown would be required. Although I am not sure if other users have use cases where they would want a different printer emulated than what they actually have as a physical printer. Seems possible maybe in backend/app/api/routes/settings.py [664](https://github.com/maziggy/bambuddy/blob/b3a91d7314bfd3a3d0ef1a749f114fa8d386adf1/backend/app/api/routes/settings.py#L664) Add the auto-match inside the existing proxy printer lookup block, right after target_printer_serial is set: ``` # Auto-match model from target printer when no explicit model was provided if model is None and printer.model: reverse_map = {v: k for k, v in VIRTUAL_PRINTER_MODELS.items()} matched_code = reverse_map.get(printer.model) if matched_code: new_model = matched_code model = matched_code # Ensure it gets saved below ``` Setting model = matched_code is important because the save section only writes the model when model is not None: ``` if model is not None: await set_setting(db, "virtual_printer_model", model) ```

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 13, 2026):

Sorry again for the mess yesterday. It was a very long and hard day.

Fixed in branch dev. Please let me know if it works for you.

@maziggy commented on GitHub (Mar 13, 2026): Sorry again for the mess yesterday. It was a very long and hard day. Fixed in branch dev. Please let me know if it works for you.

BreizhHardware commented