Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[doulos]

Hello, me again.

In writing my android tablet media controller app, it appears I am hitting another serious limitation with MC: when I browse the content directories down to the album level, the albums are listed as "container" objects, i.e. they are of UPnP type "object.container" as opposed to "object.container.album.musicAlbum", which would be the correct type according to the UPnP spec. That means I cannot handle them as such (unless I want to introduce MC specific hacks), and really my app becomes more or less unusable with MC audio. Is there something I am missing?

regards,
chris

[bob]

Hello, me again.

In writing my android tablet media controller app, it appears I am hitting another serious limitation with MC: when I browse the content directories down to the album level, the albums are listed as "container" objects, i.e. they are of UPnP type "object.container" as opposed to "object.container.album.musicAlbum", which would be the correct type according to the UPnP spec. That means I cannot handle them as such (unless I want to introduce MC specific hacks), and really my app becomes more or less unusable with MC audio. Is there something I am missing?

regards,
chris

Why do you need to know the specific type of containers in a container?

I did some checking and found that PS3MediaServer (a widely used server) doesn't ever use "object.container.album.musicAlbum". In places it uses "object.container.storageFolder" and just object.container.

[doulos]

well, because I have specific program code that reacts to the container type, e.g. by adapting the display. When there is an MusicAlbum, I display the album art prominently, and the tracks in a list on the side. For normal containers, I display a grid view, with an icon for each item. Having the same icon repeated for each track is ugly. For an album, I offer an option to play the whole album, internally using the SetNextAVContentURI action.

Then there are specific attributes attached to an album, which dont exist for a container.

Fact is, the UPnP spec explicitly states that music albums are to be represented by "object.container.album.musicAlbum" types. That is what I rely on. I am sure you have suggestions how I can change my app to deal with MC, but I cannot program specifically to each UPnP device that bends the spec in a different way. After all, the spec exists to prevent this. PS3M is famous for deviating from the spec, and I therefore really dont care to support it.

It should be very easy to change the object type on your side, and everybody would benefit IMO. This is just a suggestion, of course. I had selected MC as a target because I liked the way it handles video, I like the UPnP renderer, and I like the application somewhat (I dont like the way it handles FLAC and CUE sheets during import!). But as it stands, it falls outide of my scope as a UPnP music server.

[Matt]

The problem is that a container could be based on a simple field like artist, album, etc. but could also be built on an advanced expression.  So it's squishy when it would be called an album.

Why not react based on the files inside the container?

[doulos]

The problem is that a container could be based on a simple field like artist, album, etc. but could also be built on an advanced expression.  So it's squishy when it would be called an album.

I dont understand. I do, however, know that several other servers I know are well able to represent music albums. Specifically, these are FooBar2000, XBMC, AssetUPnP, minidlna/readydlna, Slimserver and more. MC is the first one I encountered that isnt.

Why not react based on the files inside the container?

as I said, I could implement all kinds of workarounds to deal with each devices peculiarities. Its just that I dont have the time (nor the nerve).

[doulos]

what about this: its an album, when the user upon importing the media states "this is an album. Treat it as an album". I know that I want my albums to be kept as albums and be recognizable as such

[Matt]

Imagine a view built around file paths.  If the last level of the path happens to contain only a single album, is that an album container in DLNA?

Or what if we get a little more complex and the last level of the view is built around an expression "[Year] [Album]".  Is that an album?

Or what if we get a little more complex yet and the view has a filter to remove files rated 1 and 2, so a few files aren't in the "[Year] [Album]" container.  Are we still an album?

Or what if we get more complex yet and build the view around an expression with conditionals and regex.  How do we decide if each container is an album?

I'm not saying this is an impossible problem, only that the flexibility of the view engine makes definitions of container types squishy.

[doulos]

I dont understand what all this "expression" and "view" stuff is about. I do know, as an MC user, I want to be able to feed albums into it, and get albums out. After all, nowadays music is still mostly published as albums, and thats the unit I am used to. An album has one title, one cover, one description, and several tracks. I don't tend to think in terms of "views" and "expressions". Does anyone else around here?

In MC, I can look at my albums today. If I couldn't, and only saw folders with tracks in them, I wouldnt use it. So, my suggestion is: if MC represents something as an album in the standalone UI, then pass it on as an album via UPnP.

One other item that makes sense to an end user is a playlist. That is also a UPnP type.

Bottom line: my issue here is not to gather suggestions how to rewrite my app. I have already made up my mind to write against the UPnP spec. I was just wondering whether there was any chance to get MC into this.

[Matt]

I'm trying to present a technical hurdle to your suggestion.  If you can help solve it, we can probably find something that works for both sides.

Maybe you could learn a little about views and expressions and then propose a solution to my questions above?

Thanks.

[doulos]

Maybe you could learn a little about views and expressions and then propose a solution to my questions above?

not sure.. where should I start learning about views and expressions? And why? I had a quick glance at the wiki, and didnt find anything in that regard. If you are referring to the internal workings of MC, theres not much I can suggest. I would, however, like to reiterate that as an end user, I dont think in terms of views and expressions. Its albums, movies, and playlists that matter to me. Those items should also be explicit in the UI.

A music album is still an (the most?) important medium for publishing music today. An album has at least a publisher, a title, and cover art, and it can be looked up in dedicated databases. Usually there is also performer, a composer, and the like. This concept must be appropriately represented in any software that calls itself a media center IMO, and I was under the impression until now, that it is represented in MC. The same goes for most other UPnP object types.

If the UPnP ContentDirectory service in MC doesnt provide metadata, theres no point in writing a control point for it. Just for the sake of the discussion: I could go into a container, look what items it contains, and if its all music tracks, conclude "ah, probably an album", and then try to pull album art from the container (wait, container doesnt have such a property. Should it be one track, then? Which one?). In this case, MC would behave like a primitive file server, and leave the figuring to me. Thats not what a "Media Server" should be - certainly not according to the UPnP spec.

now I've spent a lot of ink on this..

[doulos]

just had another (last) look at this: the folders I am looking at are located under the content tree at Audio/Album, so MC has already decided that these are audio albums!! The albums (I dare to call them that) even have albumArt properties (which is non-standard, because object.container does not define a property "albumArtURI"). Yet, they refuse to identify themselves as albums by using the type name "object.container" instead of "object.container.album.musicAlbum".

[Matt]

We'll use object.container.album.musicAlbum for album-like containers in a coming build.

We're planning to define an album as any container with no child containers that contains all audio where the album is the same.  Obviously this gets the simple Artist\Album example you posted, but should also cope reasonably well with the more complex examples I posted above.

[doulos]

that sounds good.