benrr101 / dolomite Goto Github PK
View Code? Open in Web Editor NEWBackend WCF service for Dolomite
License: Other
Backend WCF service for Dolomite
License: Other
Basically, I don't think album art changes are written to the original file. This should happen.
As per http://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/ the guid primary keys in the database should probably go is we want the stupid thing to be performant.
Though we could still use GUIDs as a unique, non-clustered index.
Tracks' quality href field is currently relative and needs a '/' added at the beginning to make it consistent with everything else.
A workaround for this has been implemented in Cinnabar, so it will need to be fixed there as well.
It appears that when a WMA track is uploaded, there are multiple qualities of the file created.
There's no real reason to store 2.1mb worth of album art for one file that should only ever be viewed at ~500x500 or less. Shrinking it will make it look bad, so I think resizing it will be best. I even think that .NET has built in functionality to do this.
Add an "Any" rule option for enforcing auto playlist rules. This would differ from "All" rule option adding tracks that match any of the rules -- like an OR in the if statement.
Use it!
Not display name. That seems really dumb.
This also is worked around in Cinnabar, so that will need to be changed.
It would be really cool if there was a way to generate groupings, similar to how there are (going to be) lists for albums, artists, all tracks. The groupings would be a way to do a custom group by clause in the database and enable really quick way to sort tracks based on the information you want to sort on.
Sometimes it is JsonSerializationException, sometimes it's JsonReaderException. We should catch both and return a 400, not a 500.
After changing the metadata or updating the album art in the background, recalculate the hash for the track. This will let the clients reupload the original track after it's changed.
One issue is that a track that the hash after modification will be the same as an existing track. The odds of this occurring are astronomically low, so it's not much of an issue.
With an impending refactor, there needs to be a centralized place for the all the role configuration settings. It probably shouldn't be in the app.config files of individual roles, especially if they are shared data.
This is unsupported, and appears as a corrupted tag
Support deleting a user.
Develop a special string format that can store cue file like subtrack metadata (eg, trance sets). It could even just be a json object. Add this to supported track metadata.
Replace the if exists checks when adding rules/tracks to playlists with SQL exception handling for foreign key constraint failures.
The duplicate track shouldn't be in the calculateHash method, it should be in its own track manager method. Duh.
There could be a major cleanup of the action code if the webutilities class exposes methods that perform a given action via a delegate/lambda, validate session information, and handle the exception handling (custom exception handling could be passed in, as well, via lambdas). This could clear up the duplicated code all over the place for handling 500 errors and 403 errors.
WebUtilities.GetDolomiteSessionToken should not return a string and have an out arg. That's what classes are for. Return a new type that's stored in /Requests/ and rename the method to match
Create a thread that will look for work items every hour or so. This thread will delete a track and all traces of it from the database/Azure. Add a new column to the tracks table that will store a timestamp when the track should be deleted. Upon deleting a track via the REST API, the timestamp will be set to ~an hour later, and the deletion thread will pick it up as a work item once the timestamp has passed. This will permit a "recycle bin" of sorts to be kept, adding the similar functionality as google music's undo a deletion.
Right now, you /can/ upload huge files to dolomite, but the upload client will often balk at the huge request. To aid in this, I propose adding asynchronous upload streaming support to the track endpoint. Something like http://www.level533.com/2010/11/uploading-large-files-to-self-hosted-wcf-rest-service/
However, if this is a failing proposition, the next best alternative would be to enforce upload chunking. This would be a bitch and a half from a logistics standpoint (where do the chunks reside, how do we put them back together, etc, etc) but it would almost be guaranteed to work.
Who really uses the tag name Performer? It's an artist and should be represented by the metadatafields as such.
Add a date last modified field to the db for tracks. This can be useful if we need to do caching for the track in the browser
There's no need to keep the id3 tags of the transcoded tracks. It'll just bloat the files and every kilobyte counts!
Take a look at http://stackoverflow.com/questions/20193065/how-to-remove-id3-audio-tag-image-with-ffmpeg for the command line options to strip the id3 tags
Add a client to automate testing the RESTful service
We can easily run out of integers for the id's in the metadata table and some other tables. Let's make these columns big int so we don't run out quite so fast.
Remove the binary from the source tree and make users supply their own build. This will simplify licensing.
AC/DC is being coming out of the system as AC... Huh?
Using this will make the operations faster.
The date/times that the server handles should all be UTC. We don't know where the clients will be accessing from. The clients are assuming that the dates coming out are UTC and applying the local date/time transform to it, which is doing duplicate transforms for east coast, but completely screwing it up for anyone anywhere else.
On DolomiteBackgroundProcessing/TrackOnboarding.cs:348 change DateTime.New to DateTime.UTCNow. While you're at it, make sure we use UTC everywhere else.
Well... the authorization header was a good idea, but src attributes can't pass in headers. So, if we store it in a cookie, it'll go along with all the future requests, including src requests.
This will also allow the multiple login issue to be more easily solved
Also data: src addresses are out since they're not supported in IE<10
If the POST request for replace track operation doesn't contain anything, a bad request (400) should be issued, not fail with a 500 on a null reference.
When replacing tracks, the track's metadata is reset. This is ok for things like the metadata from the track, but not ok for the metadata from Dolomite. In other words, the play count, date added, date last played should not change.
Either encode html entities in json responses OR make sure that it happens by default in JSON.net
Add support for Range HTTP header when calling the download for a track or a art file.
See notes in the onenote doc.
The add track to static playlist function should only do arrays of tracks. This will cover all cases since adding a single track can be a simple one element GUID array.
Same goes for removing tracks from static playlists.
I was worried I'd run into some of these compatibility issues when moving from a local SQL server instance to a SQL Azure instance. Turns out RAISERROR isn't supported in SQL Azure. We use this to notify when attempting to reset a locked track when onboarding errors occur.
Solution? Uh... I guess we'll make the 'is locked' check be a separate query before running the ResetOnBoardingStatus stored proc.
When requesting updates to metadata, the metadata changes should be written to the original upload's ID3 (or equiv) tags. The same /should/ go for album art uploads
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.