starred/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-02-05 00:29:55 +03:00
Code Issues 15 Packages Projects Releases 10 Wiki Activity

BUG? Bitmagnet script - problem with script #1120

New Issue
Closed
opened 2026-02-04 23:10:08 +03:00 by OVERLORD · 20 comments
OVERLORD commented 2026-02-04 23:10:08 +03:00
Owner
Copy Link

Originally created by @samwathegreat on GitHub (Jun 19, 2025).

✅ Have you read and understood the above guidelines?

yes

📜 What is the name of the script you are using?

Bitmagnet

📂 What was the exact command used to execute the script?

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/bitmagnet.sh)"

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 12

📝 Provide a clear and concise description of the issue.

There seems to be a problem with the bitmagnet script. When it asks you for your TMDB key, it doesn't actually allow you to enter it. If you do paste in your key (it 'overwrites' other text in the window, so it's unknown if it's actually capturing your input at all), it doesn't save it anywhere. No config file is created in any location including the 2 locations listed in on script page and the program only runs on 100% defaults including the default public TMDB key that is rate-limited.

Can someone please look into both of these issues?

Once they are resolved, I'd like to point the database to a file on a bind-mount location since the database can take many many gigabytes as it grows... but I need an actual config file before I can do that.

🔄 Steps to reproduce the issue.

Run the script. When it asks for API key, try to enter one. Notice that it doesn't save it anywhere.

❌ Paste the full error output (if available).

N/A

🖼️ Additional context (optional).

No response

Originally created by @samwathegreat on GitHub (Jun 19, 2025). ### ✅ Have you read and understood the above guidelines? yes ### 📜 What is the name of the script you are using? Bitmagnet ### 📂 What was the exact command used to execute the script? bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/bitmagnet.sh)" ### ⚙️ What settings are you using? - [x] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 12 ### 📝 Provide a clear and concise description of the issue. There seems to be a problem with the bitmagnet script. When it asks you for your TMDB key, it doesn't actually allow you to enter it. If you do paste in your key (it 'overwrites' other text in the window, so it's unknown if it's actually capturing your input at all), it doesn't save it anywhere. No config file is created in any location including the 2 locations listed in on script page and the program only runs on 100% defaults including the default public TMDB key that is rate-limited. Can someone please look into both of these issues? Once they are resolved, I'd like to point the database to a file on a bind-mount location since the database can take many many gigabytes as it grows... but I need an actual config file before I can do that. ### 🔄 Steps to reproduce the issue. Run the script. When it asks for API key, try to enter one. Notice that it doesn't save it anywhere. ### ❌ Paste the full error output (if available). N/A ### 🖼️ Additional context (optional). _No response_
OVERLORD added the deferred label 2026-02-04 23:10:08 +03:00
OVERLORD commented 2026-02-04 23:10:18 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 19, 2025):

Its not a bug in the script itself, we are doing some changes on the backend part of the repo. Will be fixed tomorrow after the changes get pushed to the main repo. Just wait until tomorrow if possible

@tremor021 commented on GitHub (Jun 19, 2025): Its not a bug in the script itself, we are doing some changes on the backend part of the repo. Will be fixed tomorrow after the changes get pushed to the main repo. Just wait until tomorrow if possible
OVERLORD commented 2026-02-04 23:10:22 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 19, 2025):

Its not a bug in the script itself, we are doing some changes on the backend part of the repo. Will be fixed tomorrow after the changes get pushed to the main repo. Just wait until tomorrow if possible

Thanks. How will I know when the changes have been made and it's safe to install? Can you reply when it's done?

@samwathegreat commented on GitHub (Jun 19, 2025): > Its not a bug in the script itself, we are doing some changes on the backend part of the repo. Will be fixed tomorrow after the changes get pushed to the main repo. Just wait until tomorrow if possible Thanks. How will I know when the changes have been made and it's safe to install? Can you reply when it's done?
OVERLORD commented 2026-02-04 23:10:31 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 19, 2025):

Yes, i will reply once the merge is made

@tremor021 commented on GitHub (Jun 19, 2025): Yes, i will reply once the merge is made
OVERLORD commented 2026-02-04 23:10:36 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Jun 19, 2025):

I prepare the big pr tomorrow, other contributor need to check it, because its an really big change. So in next 1-2 days should be done, you can use in the Meantime the Same call above but with ProxmoxVED instead of ProxmoxVE, this should work

@MickLesk commented on GitHub (Jun 19, 2025): I prepare the big pr tomorrow, other contributor need to check it, because its an really big change. So in next 1-2 days should be done, you can use in the Meantime the Same call above but with ProxmoxVED instead of ProxmoxVE, this should work
OVERLORD commented 2026-02-04 23:10:40 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

I prepare the big pr tomorrow, other contributor need to check it, because its an really big change. So in next 1-2 days should be done, you can use in the Meantime the Same call above but with ProxmoxVED instead of ProxmoxVE, this should work

It doesn't work

Image

@samwathegreat commented on GitHub (Jun 20, 2025): > I prepare the big pr tomorrow, other contributor need to check it, because its an really big change. So in next 1-2 days should be done, you can use in the Meantime the Same call above but with ProxmoxVED instead of ProxmoxVE, this should work It doesn't work ![Image](https://github.com/user-attachments/assets/533b52f9-6d53-473a-b2b5-617172496779)
OVERLORD commented 2026-02-04 23:10:45 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Jun 20, 2025):

Ah maybe tremor has remove it (Speedy Gonzales)

@MickLesk commented on GitHub (Jun 20, 2025): Ah maybe tremor has remove it (Speedy Gonzales)
OVERLORD commented 2026-02-04 23:10:48 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 20, 2025):

Yea i removed it sadly...

@tremor021 commented on GitHub (Jun 20, 2025): Yea i removed it sadly...
OVERLORD commented 2026-02-04 23:10:51 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

Unfortunately, this is still broken. @MickLesk @tremor021 Can you please re-open? It won't let me do it.

When I run the script now, it DOES allow me to enter my API key, but it still isn't creating the config file. And it's ignoring the API key that I input and using the default (rate limited) api key. Same exact symptoms as my original post, except that now it does actually allow you to ENTER the api key, but it just does nothing with it....

I'd be happy to provide whatever info is requested. VERY EASILY REPRODUCIBLE, though.

Thanks in advance.

@samwathegreat commented on GitHub (Jun 20, 2025): Unfortunately, this is still broken. @MickLesk @tremor021 Can you please re-open? It won't let me do it. When I run the script now, it DOES allow me to enter my API key, but it still isn't creating the config file. And it's ignoring the API key that I input and using the default (rate limited) api key. Same exact symptoms as my original post, except that now it does actually allow you to ENTER the api key, but it just does nothing with it.... I'd be happy to provide whatever info is requested. VERY EASILY REPRODUCIBLE, though. Thanks in advance.
OVERLORD commented 2026-02-04 23:10:55 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 20, 2025):

There is no config file, there never was. API key is written in service file environment statement

@tremor021 commented on GitHub (Jun 20, 2025): There is no config file, there never was. API key is written in service file environment statement
OVERLORD commented 2026-02-04 23:10:59 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

There is no config file, there never was. API key is written in service file environment statement

@tremor021 Why is it still using the default key, then? Any ideas? Thanks in advance!

Image

@samwathegreat commented on GitHub (Jun 20, 2025): > There is no config file, there never was. API key is written in service file environment statement @tremor021 Why is it still using the default key, then? Any ideas? Thanks in advance! ![Image](https://github.com/user-attachments/assets/a43ded91-b653-42d5-9688-f7df6860ae72)
OVERLORD commented 2026-02-04 23:11:01 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

The script page says that there should be a config file...

Image

@samwathegreat commented on GitHub (Jun 20, 2025): The script page says that there should be a config file... ![Image](https://github.com/user-attachments/assets/fb1a21d6-5b10-4145-9026-1df1a47c700b)
OVERLORD commented 2026-02-04 23:11:05 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

@tremor021

Looks like there is an error in the environmental variable (should be tmdb.api_key, and not tmdb_api_key), right?

Is there any good reason to not have an actual config file instead? Seems like that would be the better option here - that way if something needs changed such as the API key, it can be easily edited without having to change the service file. Thoughts?

Image

EDIT: Changing the string in the service file to TMDB.API_KEY then running systemctl daemon-reload, then restarting the service didn't help. It still uses the default api key and ignores the variable regardless of the syntax.

@samwathegreat commented on GitHub (Jun 20, 2025): @tremor021 Looks like there is an error in the environmental variable (should be tmdb.api_key, and not tmdb_api_key), right? Is there any good reason to not have an actual config file instead? Seems like that would be the better option here - that way if something needs changed such as the API key, it can be easily edited without having to change the service file. Thoughts? ![Image](https://github.com/user-attachments/assets/1b095de8-2d29-40f5-aa7c-39af72481d19) **EDIT: Changing the string in the service file to TMDB.API_KEY then running systemctl daemon-reload, then restarting the service didn't help. It still uses the default api key and ignores the variable regardless of the syntax.**
OVERLORD commented 2026-02-04 23:11:13 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Jun 20, 2025):

Create an Feature requests Please

@MickLesk commented on GitHub (Jun 20, 2025): Create an Feature requests Please
OVERLORD commented 2026-02-04 23:11:18 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 20, 2025):

Image

Image

Environment variable gets parsed just fine, i really cant reproduce your issue

@tremor021 commented on GitHub (Jun 20, 2025): ![Image](https://github.com/user-attachments/assets/bfd2cad6-1046-4bb1-8419-4dcaed4e3f75) ![Image](https://github.com/user-attachments/assets/b7fa2b52-a0fd-4eb7-ab0b-dba8a0d5255d) Environment variable gets parsed just fine, i really cant reproduce your issue
OVERLORD commented 2026-02-04 23:11:22 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 20, 2025):

@tremor021

Looks like there is an error in the environmental variable (should be tmdb.api_key, and not tmdb_api_key), right?

No, thats not how env var should be, its TMDB_API_KEY

Is there any good reason to not have an actual config file instead? Seems like that would be the better option here - that way if something needs changed such as the API key, it can be easily edited without having to change the service file. Thoughts?

We are not stopping you from making a config file to suit your needs, we just install the app and make it run. I've put only required env vars in service file, tmdb key is also optional but i included it anyway. Noone said you should edit the service file.

Image

EDIT: Changing the string in the service file to TMDB.API_KEY then running systemctl daemon-reload, then restarting the service didn't help. It still uses the default api key and ignores the variable regardless of the syntax.

Like i said, thats not how env var should be

@tremor021 commented on GitHub (Jun 20, 2025): > [@tremor021](https://github.com/tremor021) > > Looks like there is an error in the environmental variable (should be tmdb.api_key, and not tmdb_api_key), right? No, thats not how env var should be, its TMDB_API_KEY > Is there any good reason to not have an actual config file instead? Seems like that would be the better option here - that way if something needs changed such as the API key, it can be easily edited without having to change the service file. Thoughts? We are not stopping you from making a config file to suit your needs, we just install the app and make it run. I've put only required env vars in service file, tmdb key is also optional but i included it anyway. Noone said you should edit the service file. > > ![Image](https://github.com/user-attachments/assets/1b095de8-2d29-40f5-aa7c-39af72481d19) > > **EDIT: Changing the string in the service file to TMDB.API_KEY then running systemctl daemon-reload, then restarting the service didn't help. It still uses the default api key and ignores the variable regardless of the syntax.** Like i said, thats not how env var should be
OVERLORD commented 2026-02-04 23:11:25 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

Image

Image

Environment variable gets parsed just fine, i really cant reproduce your issue

@tremor021 Thank you for the reply/help.

I guess this must be a bug with bitmagnet and not with the script. Even if the env var is being passed correctly, it's still using the default api key according to 'bitmagnet config show'.

But if I create my own config.yml file and put the API key in there, the correct, provided, api key actually works and is reflected when you run 'bitmagnet config show'

Odd. I'll just use my own config file rather than relying on the env var.

Image

@samwathegreat commented on GitHub (Jun 20, 2025): > ![Image](https://github.com/user-attachments/assets/bfd2cad6-1046-4bb1-8419-4dcaed4e3f75) > > ![Image](https://github.com/user-attachments/assets/b7fa2b52-a0fd-4eb7-ab0b-dba8a0d5255d) > > Environment variable gets parsed just fine, i really cant reproduce your issue @tremor021 Thank you for the reply/help. I guess this must be a bug with bitmagnet and not with the script. Even if the env var is being passed correctly, it's still using the default api key according to 'bitmagnet config show'. But if I create my own config.yml file and put the API key in there, the correct, provided, api key actually works and is reflected when you run 'bitmagnet config show' Odd. I'll just use my own config file rather than relying on the env var. ![Image](https://github.com/user-attachments/assets/5a3edd56-dd1e-48f5-9667-b2202a590130)
OVERLORD commented 2026-02-04 23:11:28 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Jun 20, 2025):

How you create the File? Whats the Input? Where is the File? How do you Link the File? So we can prepare an PR for this as Feature

@MickLesk commented on GitHub (Jun 20, 2025): How you create the File? Whats the Input? Where is the File? How do you Link the File? So we can prepare an PR for this as Feature
OVERLORD commented 2026-02-04 23:11:29 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 20, 2025):

Check the log when starting the service. It should tell you if your API key is good or not, i mean the one in the service file. Env vars take preceedence, so if you input a API key in a config.yml, it will read that as well if the one in service file is not correct. So its kind of working as intended.

Please double check that the key in service file is EXACTLY the same as the one you put in the config file. If they're the same, i see no reason why it shouldn't work, assuming there is no bug in Bitmagnet itself.

@tremor021 commented on GitHub (Jun 20, 2025): Check the log when starting the service. It should tell you if your API key is good or not, i mean the one in the service file. Env vars take preceedence, so if you input a API key in a `config.yml`, it will read that as well if the one in service file is not correct. So its kind of working as intended. Please double check that the key in service file is EXACTLY the same as the one you put in the config file. If they're the same, i see no reason why it shouldn't work, assuming there is no bug in Bitmagnet itself.
OVERLORD commented 2026-02-04 23:11:31 +03:00
Author
Owner
Copy Link

@samwathegreat commented on GitHub (Jun 20, 2025):

Check the log when starting the service. It should tell you if your API key is good or not, i mean the one in the service file. Env vars take preceedence, so if you input a API key in a config.yml, it will read that as well. So its kind of working as intended.

Please double check that the key in service file is EXACTLY the same as the one you put in the config file. If they're the same, i see no reason why it shouldn't work, assuming there is no bug in Bitmagnet itself.

Yes, the key is exactly the same (verified by running cat on the service file and comparing). It could just be a bug with 'bitmagnet config show' not showing the values that are defined as env vars, but it really should. I understand that is out of your purvue, though.

Perhaps it was working the entire time, but just didn't look like it was since "bitmagnet config show" failed to identify that the supplied api key was being used.

I'll remove the env var, though. Because I'd rather use a config file in case I need to change the api key.

@MickLesk

The config file is /opt/bitmagnet/config.yml

I believe this is superior to using the env var since you can easily change the key if you wanted to.

All it needs to function is this:

tmdb:
  api_key: my-api-key
@samwathegreat commented on GitHub (Jun 20, 2025): > Check the log when starting the service. It should tell you if your API key is good or not, i mean the one in the service file. Env vars take preceedence, so if you input a API key in a `config.yml`, it will read that as well. So its kind of working as intended. > > Please double check that the key in service file is EXACTLY the same as the one you put in the config file. If they're the same, i see no reason why it shouldn't work, assuming there is no bug in Bitmagnet itself. Yes, the key is exactly the same (verified by running cat on the service file and comparing). It could just be a bug with 'bitmagnet config show' not showing the values that are defined as env vars, but it really should. I understand that is out of your purvue, though. Perhaps it was working the entire time, but just didn't look like it was since "bitmagnet config show" failed to identify that the supplied api key was being used. I'll remove the env var, though. Because I'd rather use a config file in case I need to change the api key. @MickLesk The config file is /opt/bitmagnet/config.yml I believe this is superior to using the env var since you can easily change the key if you wanted to. All it needs to function is this: ``` tmdb: api_key: my-api-key ```
OVERLORD commented 2026-02-04 23:11:33 +03:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jun 20, 2025):

Image

This is the hierarchy of preceedence. Use whatever you find mosts easy to use and maintain

@tremor021 commented on GitHub (Jun 20, 2025): ![Image](https://github.com/user-attachments/assets/82013d1a-0e76-489c-b5cc-53f3c3254217) This is the hierarchy of preceedence. Use whatever you find mosts easy to use and maintain
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Implemented in VED waiting push to Main
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
in project pipeline
invalid
investigation
json
maintenance
needs triage
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
🛑 Failure to comply with the guidelines
No Label deferred
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#1120
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?