PrusaSlicer unable to upload to Repetier Server if Repetier server is rebranded

[dragnmastr85]

Version

PrusaSlicer-2.4.0+win64-202112211614

Operating system type + version

Windows 10

3D printer brand / version + firmware version (if known)

Prusa i3 mk3s 3.10

Behavior

I am using PrusaSlicer to send g-code directly to repetier server. If I rebrand repetier server so that the name on the banner is something other than "Repetier-Server Pro" I get an error in PrusaSlicer when uploading that says the server is the wrong host type. When checking the host type it is still Repetier. If I unbrand the server the issue goes away. I would like to be able to use this branding without it effecting the ability to upload directly from prusaslicer.

[dragnmastr85]

Can this issue please get some acknowledgement?

[bubnikv]

@repetier ?

[dragnmastr85]

I am not sure this is a problem for repetier to solve. Slicer seems to be checking the name that resolves on the website to confirm it's host type. So if we edit that name it returns an error. If repetier is already returning data in a known format, the name shouldn't matter in Slicer.

[repetier]

I can confirm the error. It already happens when you test connection. I guess you try url
http://ip:3344/printer/info

And in the json response you compare name parameter. In my test response looked like this:

{
    "name": "Felix Server",
    "printers": [
        {
            "active": false,
            "name": "Fehler",
            "online": 0,
            "slug": "Fehler"
        },
        {
            "active": true,
            "name": "Demo",
            "online": 1,
            "slug": "Demo"
        },
        {
            "active": true,
            "name": "Felix Pro 3",
            "online": 1,
            "slug": "bla1"
        },
        {
            "active": true,
            "name": "xxx",
            "online": 0,
            "slug": "xxx"
        },
        {
            "active": false,
            "name": "DefPrusa",
            "online": 0,
            "slug": "DefPrusa"
        },
        {
            "active": false,
            "name": "iRapid Mini",
            "online": 0,
            "slug": "iRapid_Mini"
        },
        {
            "active": false,
            "name": "ErrorLouis",
            "online": 0,
            "slug": "ErrorLouis"
        },

        {
            "active": true,
            "name": "TestUpload",
            "online": 1,
            "slug": "TestUpload"
        },
        {
            "active": false,
            "name": "Marlin 2",
            "online": 0,
            "slug": "Marlin_3"
        }
    ],
    "servername": "Mac-Roland",
    "serveruuid": "xxxxxxxxxxxx",
    "version": "1.3.1"
}

And the error message was

Could not connect to Repetier: Mismatched type of print host: Felix Server
Note: Repetier version at least 0.90.0 is required.

Official version also has several names like "Repetier-Server Pro" depending on license present or using free edition. But I guess you test the first Repetier-Server to be present.

I suggest instead testing presence of printers, version and name field in root object. (servername, serveruuid were added after 0.9 so not always present). But it is unlikely that a other service at same url responds with similar json scheme.

[bubnikv]

I can confirm the error. It already happens when you test connection. I guess you try url
http://ip:3344/printer/info

If we have to support Repetier server rebranding, we need the info API to return some key that identifies the server as Repetier, so we can verify it understands the language we are using to talk to it.

@repetier

Would you please add some unique Repetier key to the JSON response of the info API, so we can verify that a rebranded Repetier server is in fact a Repetier server kind?

[repetier]

@bubnikv Why do you need another key? As I said you can test if keys "name" and "version" exist. No other software will return a json at that url with these 2 key names existing. All you need to skip is testing for the value in "name"-key. Adding a new key would require all users to update server which not all of them would do, so I think that is enough. After all user in addition also said it is a repetier-server instance.

[bubnikv]

@repetier

As I said you can test if keys "name" and "version" exist. No other software will return a json at that url with these 2 key names existing.

Sorry, but I don't find an identification of a service by the existence of "name" and "version" keys to be sufficient. We are not going to implement detection of "Repetier" service by the existence of "name" and "version" keys.

[repetier]

Don't see it that way, anyhow. If version key is "1.4.0" or higher there will be the additional key/value

"software":"Repetier-Server"

That is invariant also for branded versions. For older version it is not possible to add, so you then need to decide "name" containing "Repetier-Server" or "software" having value "Repetier-Server" to be backward compatible.

[dragnmastr85]

@bubnikv any update? Thank you.

[bubnikv]

@repetier
Do you have a list of names used to rebrand your Repetier server?
We may just hard-code "name": "Felix Server" and a handful of others.

[repetier]

No we don't have. Most companies do not tell us how they modify it. Also the list will change over time. But with the "software" addition it would work with all brandings in future at least. For testing that part you can use our nightly builds.

https://www.repetier-server.com/knowledgebase/nightly_builds/

There the new addition is already included. Final release will be end of may I hope.

[dragnmastr85]

@bubnikv
@repetier has offered an alternate key for slicer to check against. When can we expect this to be implemented in the check?

[lukasmatena]

I have made a testing build using logic described in #7807 (comment) - if there is the "software" value, it is checked to be equal to "Repetier-Server". If the value is not there, the validation is the same as it was before.

Would you guys mind to test it? Use these links to download the build:
PrusaSlicer-2.5.0-rc2+2-lm-repetier-linux-x64-GTK3-gb2eb56b
PrusaSlicer-2.5.0-rc2+2-lm-repetier-win64-gb2eb56b69

Thanks.

[repetier]

Yes that part seems to work in my test now.

What I noted is that "upload and print" is not always printing. If you add to url autostart=true as parameter you would enforce this in all cases except the case it is already printing. Actually we have 3 upload methods:

1. Upload permanently to folder selected for later use which you already have
2. Queue - put to queue. Enforced with autostart=false
3. Upload and print - add to queue and start if possible. autostart=true

Without autostart it depends on the queue state - empty queue would start (except 1.4.0 and 1.4.1) , full queue will always queue.

Old server versions might ignore autostart.

[lukasmatena]

@repetier

Yes that part seems to work in my test now.

Thanks for the testing. I understand that the build 2.5.0-rc2-gb2eb56b fixes the original issue with rebranded Repetier server. We will include the fix in the 2.6 release.

What I noted is that "upload and print" is not always printing. If you add to url autostart=true as parameter you would enforce this

Do I understand correctly that this is a separate issue and that you suggest we send "autostart=true" when the "Upload and Print" button is pressed? If so, could you please review 3856ece and test the following build:
PrusaSlicer-2.5.0-rc2+3-lm-repetier-linux-x64-GTK3-g3856ece
PrusaSlicer-2.5.0-rc2+3-lm-repetier-win64-g3856ece5f

Thanks.

[repetier]

Ok, that was a good test for server too. Condition internally was not 100% on our side. But on your side implementation is now perfect to tell that you prefer to start print if possible and otherwise just queue it until running print is finished and it gets started inside server.

[lukasmatena]

@repetier Thanks. Since you approved both the changes (b2eb56b and 3856ece), we will include them in 2.6 release.

[repetier]

Thanks.

[dragnmastr85]

Thank you both for assisting with this! I am closing the issue now @repetier @lukasmatena @bubnikv