benrr101 / dolomite Goto Github PK

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.

Add support for Range HTTP header when calling the download for a track or a art file.
See notes in the onenote doc.

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.

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.

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

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.

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.

Not display name. That seems really dumb.

This also is worked around in Cinnabar, so that will need to be changed.

Using this will make the operations faster.

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

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.

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.

The duplicate track shouldn't be in the calculateHash method, it should be in its own track manager method. Duh.

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.

Either encode html entities in json responses OR make sure that it happens by default in JSON.net

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.

Who really uses the tag name Performer? It's an artist and should be represented by the metadatafields as such.

Sometimes it is JsonSerializationException, sometimes it's JsonReaderException. We should catch both and return a 400, not a 500.

Basically, I don't think album art changes are written to the original file. This should happen.

It appears that when a WMA track is uploaded, there are multiple qualities of the file created.

Replace the if exists checks when adding rules/tracks to playlists with SQL exception handling for foreign key constraint failures.

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.

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.

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

Use it!

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.

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.

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.

Add a client to automate testing the RESTful service

AC/DC is being coming out of the system as AC... Huh?

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

Remove the binary from the source tree and make users supply their own build. This will simplify licensing.

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.

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

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.

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.