Open bgiesing opened 7 years ago
The official mirror actually points to GH Pages; it just has the reverse proxy as well. I'm going to leave this open, as I'd like to find a solution that doesn't require a reverse proxy in the first place.
maybe try switching from Drive to Dropbox? You can hotlink easy by changing www. to dl. So you don't need any special setup it just starts the transfer.
Nah, same issue with cross-domain requests.
Closing for now - there doesn't appear to be a way to circumvent CORS policy and I can't fit all the current music on a free Dropbox plan (which would work otherwise).
I also tried using Google's API, but it's rate-limited and apparently the IP my university gave me already hit the limit for today, so that's not really feasible for me.
Well the main reason I think that this would be an issue is for people using their own music. As it is right now, people (most likely) either fork to make changes to contribute back, make a special variant for certain reasons (like the one by @TheNexusAvenger for getting ROBLOX sound data), or to use songs not there (possibly to make videos if they can't afford After Effects or just to listen).
So I think some suggestions to try and avoid CORS issues are ones that allow people to use their own files.
Use local files and a localstorage database cache
Well for alt. services, it sounds like you need a host with at least 5-10 GB and an API to avoid CORS? I'm not sure if this one will work but it's the only one I've found that might work:
Google's Picker API
Reopening so I can try to play with these ideas after finals.
I think the best way would be to have the user pick the song using a file input, then it loads the info from ID3 tags (artist/title/genre), if none are present (or missing some) it will then prompt for more info and then once it has collected the mp3 and info it can store it to a local database. This would make it easy to code unrestricted editing and playlists as well.
I believe localstorage has a file size limit though, so might want to look into that or try an offline javascript database system that supports text and files (if that exists).
been wanting local mode for ages but never could get it to work because the whole thing runs on page load so it'd take a bit of restructuring and Max knows the code better than me so yeah hopefully he can figure it out.
If we can get this to work it'd be great really because then everyone can just run their own music locally and it cuts down on your servers stress as its not grabbing the CSV every time and removes file uploading from the equation.
Why should users have to upload to a site just from them to redownload it again? (even on refresh due to drives anti-caching header) kinda silly if you think about it.
@itsIncept Yeah it solves many issues.
Also @caseif on a side note (probably should be a different issue), considering Monstercat no longer uses genre colors and the space background, maybe they should be removed or be adjustable as an option?
It used to run like that with mp3 files on the server but obvs moved it to other hosting so server didnt stress and copyright stuff ..but it caused all this cors issues and upload/download sillyness so local is the way to go
I think the referencing of local files is fine, not many people move their music directory, especially iTunes stuff. You can easily store something like 'file://blah.mp3' and yeah just prompt if they try to load something from the list thats missing broken
Re genre: Keep it as a legacy option, as we worked so hard on it lol but yeah probz have to have a field for pictures too.
Regarding local storage: I might implement that in addition to the way it currently works, so maybe it'll default to the current behavior but also include a /custom
slug or something where it allows custom upload.
Regarding genre colors: probably allow background images to be set, in which case it'll use the white color. Otherwise, it should default to a genre color.
As I mentioned, I'll probably try to work on this over winter break; I definitely want to expand the project this way when I'm able to.
@caseif Yeah that's probably the best solution there as while local would be the better thing overall, it does require some more setup so there still should be a "library" like their currently is.
Also I went ahead and renamed the issue as this issue is more about CORS than GitHub pages.
I have a load of time rn so I'm gonna see if I can dodgily implement the local idea with a simple GUI for input and playlists even
Okay so I coded an offline music database thing http://incept.cc/dev/ took forever. It uses an ID3 library to quickly get song info, Base64 encoding/decoding for Mp3's/Images and IndexedDB to store all the data. I think we could implement it fairly well as IndexedDB sticks to the domain, is persistent even on browser close and has unlimited storage unlike all the other alternatives (apart from the hard drive limits of cause).
Would just need to figure out how to use base64 with web audio/convert to something usable and use the track info from the database instead of a file.
which is kinda beyond me cos yeah the vis code is pretty rough.
@itsIncept Just tried it on both Edge and Chrome and it seems to work fairly well outside a couple of issues (to be expected for something whipped up this fast)
@bgiesing lolrip I forgot to add the accept attribute I guess. I believe that's probably due to IndexedDB being a relatively new thing that only started to pick up in 2016 so edge might not support it yet.
Uh so I just loaded a flac file fine, it played and everything but the id3's didn't go through so I assume you're right there with it being the issue.
@itsIncept According to Microsoft's dev site, Edge does so IDK what happened there https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/dev-guide/storage/IndexedDB/
Well as for the FLAC crash and reboot, my computer is a shitty Celeron so maybe the ID3 could have caused the browser freeze but the Celeron couldn't take it and rebooted the computer. Essentially, I think that might have been a rare occurrence.
the console error is something completely different to db actually so yeah not sure what's going on there. It's just a prototype anyway and it works so when it's actually implemented that's when we can start being careful with it aha.
Managed to use Dexie.js (IndexedDB API Wrapper) to get the idea working even better plus edge support. Can store mp3's as blob now instead of converting to base64 (still have to do that for the image though because id3 data is different). There's not a lot of validation or styling because I wanted to keep the code minimal and clean but this should be working fine: http://codepen.io/Incept/pen/XNOReE
So, I realize its been a while, but after reading the above, I gotta ask: is this project at an official stand-still until a workaround is properly implemented, & someone commits the changes?
We developed a localdatabase method for the Trap Nation vis which works well and is being ported over to vis reborn eventually.
I have a feeling it's because GH Pages doesn't have the reverse proxy for Google Drive. Not sure how (or if) that could be worked around (outside of hosting it on a paid server). Any ideas?