Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the requirement for a browser to be pointed to the web app in order for the playlist to work #25

Open
JonathanDCohen opened this issue Feb 8, 2022 · 5 comments · May be fixed by #44

Comments

@JonathanDCohen
Copy link

Currently the playlist state is stored in the React component for the front-end UI. This means that, if you have a field installation of Pixelblazes with Firestorm which you'd like to have shuffle through a playlist, you need a browser somewhere pointed at the Firestorm UI. I've fixed this in my installation by pointing the built-in Chromium browser on my RPi to localhost, but it's not a great solution. This also means that if there are two different browsers pointed at the Firestorm UI, they'll compete with each other.

This feels like a layering violation to me. The playlist state should live in the API server and be manipulated with the REST API. This way no browser-looking-at-localhost hack is needed and multiple people can control Firestorm at the same time without conflicting with each other.

@simap
Copy link
Owner

simap commented Feb 8, 2022

Hi @JonathanDCohen,
This feature was graciously contributed in #1 and enhanced in #8 by community members.

I won't have a chance to convert this to server side state myself, but I'd be happy to put up a bounty of a free Pixelblaze for anyone that contributes a PR with it.

@caleyg
Copy link

caleyg commented Apr 14, 2023

I know you mentioned server-side-state which would take some effort, but I think an easy win here could be a file saved in /tmp if available. Are there any users running this on Windows? If so, we might wanna consider %userprofiles%\AppData\Local\.

Thoughts?

EDIT: I'll peek at socket and see what can be done; looking at socket.io its mostly aimed at chat stuffs... I'm still partial for file storage because it can persist between restarts 🤔

another edit: I think a localdb of some sort might be best here, exploring lite options...

another another edit: tinkering withreact-native-local-mongodb I can store data, but it doesn't persist across browser sessions... and I would like to avoid adding heavy dependencies on an already light deployment, eg: database requirements and having to host it on the machine along side the pm2 server, that json file looks more and more attractive. -- I'll reach for the filestorage and see how that plays,

@jvyduna
Copy link
Contributor

jvyduna commented Apr 15, 2023

I've never used react-native-local-mongodb; since this isn't a native app I wonder if the maintained fork of NeDB is another option. Or SQLite (great project stability/longevity) or a local JSON file sound reasonable.

@caleyg
Copy link

caleyg commented Apr 15, 2023

Yeah, 💯 I will reach for SQLite, as it seems like a rational choice here and could persist between restarts. I want to keep the implementation as close to an industry standard as possible and light on the machine it is running in. The JSON file will be on the back burner as a last resort. I wasn't aware of NeDB, and I'll also look into that. Thanks!

EDIT: okay, sqlite3 is persisting data between browser sessions using a local file as its database store, and I have the routes set up. Just sorting out the UI bits now. 🍿, this is gonna be so nice to have 👍

@caleyg
Copy link

caleyg commented Apr 16, 2023

🎁 💝 #44 This is a working solution. I'll come back and clean it up a little later <3 Be well all

EDIT: I added some cleanups, it could use some polishing still, maybe, but I'll yield here for now :P Cheers 🍻

Okay, it's good to go. I've had it running on my local server for 24+ hours, and it works well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants