A question of features

jimmyw

I am in the process of writing a backend for a media server for a company whos name I shall not name, and I have a few questions for our community.
What features are you looking for?

Features I have so far.
I already have full playlist response.
You can query the server for a list of all items that match artist, genre, year or name.
I wrote support for now playing art.
You can ask for play position feedback, refreshes every second with current position of playing song and max length.
Play by song name, artist name, genre, or udid of song.
Selection of playmode (shuffle,repeat song,repeat playlist)
Standard controls(duh) play pause,next,prev,ffwd 10 seconds, rew 10 seconds, jump to position.
And last the command structure is nice and simple with easy delimiters
$01,theCommand,$02,theParam,$03,theSubParam,$04,$0D,$0A
Any suggestions?

nicholasjames

Toast.

Everyone wants a product that can do one thing really well, and also makes perfect buttery toast. Or maybe julienne fries. Consider condiments.

jjames

Curious on the "full playlist" retrieval. Does that mean, if there's 200 items, it'll return all 200 items? Same thing if it has 1,800 items . . . . even though I'll only display 10 (at most) at a time?

John Nagy

If you are going to build YAMS (yet another media server) or any device that does what 200 did before you, you must have a compelling difference, or don't bother. To ask what we'd want is silly. We'd want everything that every other sever does, plus something. Better you should review what people complain about on other servers, and crack that problem in a compelling way.

jimmyw

John Nagy wrote: »

Better you should review what people complain about on other servers, and crack that problem in a compelling way.

Any complaints you can think of?
Also, I am not making the media server, I was contracted to build an addition to the existing system, because their existing one is total garbage.(non acsii, BCD, with checksums, no one likes checksums)

@jjames
Yes, the module on AMX will by default receive the full library, the module will handle sending the right items to the ui based on total number / items per page = x number of pages
for smaller systems like RTI I have in place a way to request a subset of the total library LIBRARY_SUB S=x;I=y
where x is your start point and y is the amount of items you want returned.

John Nagy

Re complaints, read the forums. Not just this one, google for it, research it, own it, live it. This is your project, don't wait for inspiration to find you.

So you will deliver all the metadata for my 100,000 song library to the Netlinx at once? I see a complaint coming.

I do feel you are being naive and unrealistic, and tackling something bigger than you imagine without enough background or support. But that doesn't entirely preclude success.
I wish you luck.

jimmyw

John Nagy wrote: »

I do feel you are being naive and unrealistic, and tackling something bigger than you imagine without enough background or support.

Always inspiring and uplifting John.

a_riot42

John Nagy wrote: »

I do feel you are being naive and unrealistic, and tackling something bigger than you imagine without enough background or support.
.

All the truly great things were done this way.
Paul

John Nagy

jimmyw wrote: »

Always inspiring and uplifting John.

I honestly gave you good product management advice, a strategy and some tactics. A successful product comes from knowing the market and the competition inside out, and then building a solution for what you find lacking.

My input on what to do is real, but it's work. I hope my comments do inspire you to do more than casually ask around for a compelling product advantage to be suggested to you... Note that the only other suggestion you got by that method so far was to make it more toasty. I think that was ironic disparagement of your research plan, and perhaps less useful than my comments.

In all seriousness, I wish good luck finding inspiration. It will be hard work to make results that stand out in a field saturated by competitors who have lived and labored over their similar vision for years.

champ

Think of it from the least technical angle possible, imagine yourself sitting down after a hard day and you just want to watch the latest episode of xyz. What buttons would get you there quickest.
Imagine you have infinite titles and zone and every online subscription possible.
Imagine you have never read a manual or been shown how to use the system.

When you think you know the best way ask your wife or your parents.
Imagine how Apple would do it if they had a product like Kaleidascape.
Look at Kaleidascape because that is currently the best product on the market.

Now figure out how a back end could make this possible.
(advice is much easier to dish out than actually turning it into reality)

ericmedley

Here's some suggestions, make it not overly dependent on the UI design. Make sure it provides implementation for more than on UI at a time controlling more than one zone at a time. Provide the ability to enable/disable feedback to UIs not currently needing it.

vining

I would only request one page at a time, not the entire library. If you want rapid response for swiping which I don't even knnow if that's practical with AMX tps but if it is I might pull the current page plus next at a time and hold one page going backwards. Never would I attempted an entire playlist unless it's only a page.

Make your pages scalable so you can display either 8 items at a time or what ever works for the UI being used. If you're only using large UI or if the UI is used in portrait mode you might want to have 20 items per page so use a variable and make this scalable even though you'll probably never need it.

a_riot42

jimmyw wrote: »

Always inspiring and uplifting John.

I think I should hire him as my life coach
Paul

PhreaK

As others have alluded, this is no small task, but anything you can do easily is often no fun.

You're definitely off to a good start. Before you even think of approaching your IDE take a few steps back and research and test. Repeat these steps until you are able to transform whinging and bitching during the testing phase to positive feedback and enthusiasm. If you can get people not to just use your product, but actually form an attachment and advocate for its use that is an extremely powerful thing.

A simple way to test is define your API in a document / wiki, then set yourself up as a mechanical turk with your target user group. This will allow you to quickly sketch out and test ideas without incurring the cost of implementing them. Staying agile and light-weight in this exploratory phase will allow you to iterate through a mass of different concepts without forming a personal attachment to one in particular due to already expended effort. As you begin to refine your API and you can fill things our a little more and maybe implemented some functionality, but don't jump straight to this step.

You should check out Joshua Bloch's talk on API design. Some concepts like object construction, inheritance etc won't apply to your situation but a lot of the core concepts will be very relevant.

Feature wise, there are two things I love in control API's:
+ The ability to subscribe to state information for asynchronous feedback. The base level provides you with a basic ACK or error response for each executed command, then you can subscribe to device state info that you are interested in. In your case this may be things like transport state, media position etc. This removes any excess communication that you have no interest in, whilst still providing access to everything you could want.
+ The ability to embed a UID in a command that requires a response (metadata query etc). When receiving a synchronous response from the device you can then associate this with the command that triggered it. This is priceless for buffer management.

Oh, and once you have officially released it do not change it or I will hunt you down.