PlexRecentlyAdded Widget Not Displaying Data Despite Successful Proxy Setup

[owainri]

Hi @noahpodgurski ,

I’ve been working on setting up the PlexRecentlyAdded widget using the Tidbyt app, and I’ve encountered some issues. Here’s a breakdown:

Setup:

• Running a local Plex server at 192.168.1.72 on port 32400.
• Created a proxy server using Node.js running on a NAS (QNAP) through Docker.
• The proxy server listens on port 6969 (internally) and forwards requests to the Plex server.
• Port 6969 is mapped to 32768 on the host.
• x-api-key and x-plex-token are correct, verified by successful Postman and curl tests using the API.

Testing:

• The proxy server runs fine and responds to Postman requests (using port 32768), but the Tidbyt widget shows a cloud with a line through it.
• Logs indicate that requests are forwarded to Plex correctly when tested via Postman/curl.
• The Plex server is accessible locally but not from outside the network. However, since both the Tidbyt widget and proxy are on the same local network, external access shouldn’t be required.

Troubleshooting:

• Verified the API key and token.
• Confirmed that Postman/curl requests return the expected responses from the Plex API when using the proxy.
• The issue persists specifically with the Tidbyt widget (no logs are triggered in the container when the widget is saved).
• Tried mapping the Plex server host to localhost and its IP address (192.168.1.72) within the proxy script.
• Set up proper timezone handling in the container to avoid any potential discrepancies in logs.

I made a few minor updates to the index.js file (attatched as index.txt), including changing the Plex server host from 'localhost' to the IP address of the Plex server on my network (192.168.1.72). I also added logging for forwarded requests and improved error handling for better visibility in my troubleshooting. I don’t think these changes affect the core functionality of the proxy server, but they help ensure it forwards requests correctly within my setup.

Would you have any insights on whether the widget might be experiencing an issue, or if there’s something I might be missing in the configuration?

Thanks in advance!

index.txt

[noahpodgurski]

Unless you're running the tidbyt code and pushing it to your tidbyt device yourself, you'll have to port forward to make the proxy available externally. Tidbyt's servers are not run on your local network. Once you port forward set the IP to the public IP of the proxy. Use postman to verify it's available externally with the public IP.

Hope that helps

[owainri]

Hi Noah, thanks for your previous reply. I've since discovered my ISP doesn't allow for CG-NAT/port forwarding unless I pay for their top-tier internet plan, which I'm not willing to do.

I’ve confirmed that the ngrok public URL works externally using curl and Postman while hotspotting to my phone. Unfortunately, the Tidbyt widget still shows the cloud icon and doesn't seem to access the proxy via the ngrok URL.

I suspect this is probably due to the widget not sending the necessary x-api-key and x-plex-token headers for authentication. Could this be the issue, and is there a way to configure the widget to send those headers?

Also, you mentioned "running the Tidbyt code and pushing it to your Tidbyt device yourself." Could you clarify what that means? Is hosting the widget code on my NAS and pushing it directly to the Tidbyt device an option? If so, I’d be interested in learning more about how to do this. Thanks for your help!

[noahpodgurski]

If you can't port forward I don't think it will work for you from their servers, sorry.

The other option is running a cronjob or something that runs every X minutes, which renders the file, and pushes it to your device, all within your local network. You can view more about it here

https://tidbyt.dev/docs/integrate/pushing-apps

[owainri]

Hey Noah

Thanks for the message. This thread has been super helpful, I've just decided to go down the route of configuring pixbyt and hosting the app on my NAS instead. I felt like I was banging my head on the wall until I confirmed my ISP was the cause of the issue. I'll close this off. Thanks!