Print

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

[pluto]

Background – In Europe, a great many modern desktop & bedroom-style radios employ chipsets supplied by a company called Radio Frontier. These radios typically support DAB (Digital Audio Broadcasting), Internet Radio, DLNA client etc. The Internet Radio functionality is interesting insofar as it makes use of a web portal to support the Internet Radio system and enable the user to define radio stations based on custom URLs. It has to be done in this somewhat convoluted manner as the radio only has a simplistic interface from which it would not be practical to type and store complex URLs. Yes, I'm sure this could have been avoided but we are where we are.

Last week, Radio Frontier had a lover's tiff with its supplier of these back-end services and the result is that, while mainstream radio services have been restored, custom URLs have been lost and so far, the word on the wires is that the ability to add custom URLs may be gone forever. So my Roberts radio insomnia listening of choice is lost.

Proposed solution – Use a DLNA server to send my custom URLs from a computer (where they play perfectly) to the Roberts, whose DLNA client is very capable when it comes to playing my local library material (consisting mainly of FLAC). I have been using a DLNA server configured to send everything to the Roberts Radio in MP3 format for about two years so the general method is well-proven and stable.

My custom URL collection is stored within Media Center playlists which have fields "Name" and "URL" (which is typically long and complicated) and one or two other things that I find useful but, I doubt are of real significance.

Problem – I added the "playlists" item to my working DLNA configuration ("Customize Views"). I then discover that the "playlists" item shows "this item has no configuration" so I'm stuck at this point as on the Roberts, the playlist folders themselves appear but they seem devoid of actual entries.

Main question – why can the "playlists" item not be configured to show particular fields etc., exactly the same as other items? The ability to do this might, possibly, be the answer to my problem. I have to stress at this point that the Roberts DLNA client finds and plays my local library material faultlessly, so why does the "playlists" item behave differently?

Also – investigations suggest that "audio mode specified output format" doesn't seem to apply to playlists; I have proven this by using client software that shows the format being played. When playing local material, transcoding works entirely as expected. But playlist URLs seem to present in whatever format they are, resistant to transcoding. NB unless I am doing something very wrong, this still applies to the newly-added "URL" option on the transcode list.

There is one final sting in the tail – sorry to bring this up, but it's important and relevant. Setting up a Foobar-based server using its five-year old UPnP/DLNA component got audio out of the Roberts within a few minutes of installation. But I don't think of this as a solution (the server software is old, unmaintained not sufficiently stable for my liking).

Sorry for long post but I wanted to give all necessary detail. All ideas to get my Roberts radio playing custom URLs again gratefully considered (and, if I can get this working, there might be lots of disgruntled Roberts users out there who will buy copies of MC to free themselves of the tyranny of Radio Frontier's lack of service)!

[pluto]

Apologies for bumping but the problem described is causing major issues in this household 

The core problem is that playlist items do not show up on a Roberts Radio (which works as a very efficient DLNA renderer on local library material). The folders appear, the items within them do not.

[RoderickGI]

So are your custom URLs something like the Radio JRiver URLs? i.e. URLs pointing to specific tracks served from internet sites?

My custom URL collection is stored within Media Center playlists which have fields "Name" and "URL" (which is typically long and complicated) and one or two other things that I find useful but, I doubt are of real significance.

I think, based on your description, that if you copy the contents of your Custom [URL] field, which contains the URLs you want to play, to the [Filename] field, the URLs will then turn up in the Playlists and you will be able to play them. At least locally they will work. To copy the field contents, select the items in MC, then right-click on one and select "Library Tools > Move / Copy Fields" then complete the dialogue.

The question then really is whether MC will stream the URL media to your Roberts DLNA Renderer. Some streams can be sent by DLNA, some streams can't. I get very mixed results with that. So you will need to try it. Test with Radio Swiss Jazz to see how it should work, as I can stream that URL based media to a DLNA device without trouble.

For DLNA, set the Audio Mode to "Original" if that is what you want. "Options > Media Network > Add or configure DLNA servers > Audio > Mode". Radio Swiss Jazz also works with "Specified output format" when that format is supported by the DLNA Renderer. Try using L16 as that should always work, and then try other formats if you want once you have seen L16 work. You should probably set up a specific DLNA Server in MC for the Roberts radio, unless it is the only DLNA target device that you use.

If you have more than one DLNA Server in MC, you need to Associate the correct DLNA server with the Zone for the Roberts radio. Select the Zone under Playing Now, right-click it, select "Associate with DLNA Server", then select the correct Zone.

As for your Main Question, Playlists are Playlists. Their format and layout are well defined. You can display any fields as columns in a Playlist View, in the same way as any Views, but you can't change what a device is expecting in them, or what fields MC will look at when trying to play a Playlist. MC will look in the [Fielname] field for the target media. Hence the field copy recommendation above.

A simple third-party DLNA Server could easily send media to the Roberts radio, because it is simple and isn't as configurable or capable as MC. "With great power comes great responsibility", or something like that. Maybe "With greater functionality comes greater complexity". 



If I have completely misunderstood your description, sorry, but I tried. Some of what you wrote doesn't make real sense in a MC context, such as "My custom URL collection is stored within Media Center playlists", because in MC your custom URLs would need to be created as items, possibly imported into MC initially, and then those items could be added to a Playlist. You can't directly create a Playlist in MC. Well, you can create the Playlist name, but it won't have any contents unless you actually add items to it.

Perhaps some screenshots of the items you have in MC for your custom URLs, and the Playlists they belong to would help.

[pluto]

Many thanks for your thoughts and contribution. I realise that my original post was too wide-ranging and leaping around with too many different ideas. Lets clear up some basics:

The Roberts unit plays local media perfectly via DLNA, converted to whatever format is selected in the DLNA server configuration settings. I have a 'view' configured under 'audio' that shows the library by Album or Artist. Stable and reliable.



I have one playlist for each radio provider i.e. BBC streams 320kbs.



The entries within each playlist are the 'channels' offered by that provider i.e. BBC Radio One, BBC Radio Two etc. Each entry consists of a Name field and a URL in the Filename field. This approach works on most DLNA clients – the Name field showing up in the DLNA client. I have two DLNA clients 1) the Roberts Radio in question, 2) VLC software, used for testing. Both these clients have the ability to show the format in which material is received.

However, the 'playlists' entry in the DLNA view appears to behave fundamentally differently from the rest, insofar as DLNA clients are concerned. 'Specified output format' is MP3 high bandwidth and this is indeed the format to which all the local audio gets converted. But anything under the 'playlists' item is delivered to the client in its original format i.e. not transcoded.



Forgive me if this is a naive comment, but I thought the idea behind 'Specified output format' was that any and all material would be delivered to the client in that format. As the Roberts plays all my local material without problems, I assume that when 'Specified output format' was chosen and proven to work, anything sent via that DLNA server would appear, to the client, to be in exactly the same format – in other words, MC does all the heavy lifting to convert the weird and wonderful URL content to, in my case, a simple MP3 stream.

The simple fact is that this is what appears to happen when I use Foobar and its five year-old UPnP addon, and the Roberts radio is happy.

[pluto]

So the key issue, for the time being, appears to be that the specified audio mode is not being complied with when playing anything under the 'Playlists' item on a DLNA client. The 'Audio' item behaves as expected.

[bob]

Most likely your radio can't handle the mime-type of the HLS stream in which case it wouldn't show up in the playlist.
The build you have (38) is the first build to add the url type to filetypes to be converted under Advanced when using specified format when necessary.
Note that in your case the stream probably will not be converted since it probably doesn't have a content length but you could try it.

[pluto]

Thanks Bob.

Firstly. I can confirm that "specified output format" which works for local content, does not work on playlist content. I'm unsure how I can test "specified format when necessary" (with 'URL' selected) in a way that's meaningful to this problem.

Most likely your radio can't handle the mime-type of the HLS stream in which case it wouldn't show up in the playlist.

That seems highly feasible. I note that the Foobar UPnP addon (that does work) effectively lies about the content length – it shows up on the client as being 6h45m48s – hardly an issue if that approach is effectively a workaround

BUT, neither do my Jazzradio URLs show up on the Roberts client, and they are not HLS, but that too could be the content length issue. Matt has a URL you may use for testing if you wish.

They too work via the Foobar server.

I have tried the "specified format when necessary" approach in combination with the "URL" and can confirm that, sadly, the playlist entries remain absent. But your content length theory seems promising.

[bob]

Do playlists with normal files as opposed to URL's show up?

[pluto]

Do playlists with normal files as opposed to URL's show up?

Yes, and audio plays!

[RoderickGI]

Is the Duration on the items in the Playlist editable? If so, try adding a reasonable duration and see if that works. (I don't have a Playlist of streaming items set up I can test with at the moment.)

Related question:
What is the source of the Playlist? How did you build it? Was it a Playlist file that you imported? If so, can you share the Playlist file so I can test? Perhaps just export the Playlist in mpl format, post it here, and I can import it for testing? I might work out how to get the transcoding working. 


The image you posted showing the DLNA View configuration for Playlist with the message "This item has no configuration" is not a problem. I get that as well.

I tested viewing Playlists I have downloaded from Cloudplay using the free version of BubbleUPnP as both the DLNA Controller and Renderer. All my Playlist and their contents showed up in BUPnP, as expected, and as laid out in MC Standard View. I just couldn't play them because the Cloudplay URL isn't a playable stream, except in MC. So if the Playlist contents aren't showing up in the Roberts radio, it isn't to do with the View configuration.

[pluto]

Is the Duration on the items in the Playlist editable?

I don't think so.

can you share the Playlist file so I can test? Perhaps just export the Playlist in mpl format, post it here, and I can import it for testing? I might work out how to get the transcoding working. 

See your PM!

[AndrewFG]

Note that in your case the stream probably will not be converted since it probably doesn't have a content length but you could try it.

Hi bob, this is going to be an ever bigger issue as the world migrates from finite tracks to infinite (or at least indefinite streams). UPNP doesn’t have a standard answer for this. I suppose the only thing you can do is to create a pretend ContentLength that is (for example) =MaxInt or =Max Size of your transcoder buffer; and fail gently if the user listens to the media long enough to overflow the buffer..

[pluto]

...I suppose the only thing you can do is to create a pretend ContentLength that is (for example) =MaxInt or =Max Size of your transcoder buffer; and fail gently if the user listens to the media long enough to overflow the buffer.

With a real time stream, is a transcoder buffer not usually a circular arrangement of a few minutes length that reuses from the beginning when the end is near?

I wondered why the Foobar UPnP addon creates an end time of 6h45m48s. Hardly an arbitrary choice 

[bob]

Hi bob, this is going to be an ever bigger issue as the world migrates from finite tracks to infinite (or at least indefinite streams). UPNP doesn’t have a standard answer for this. I suppose the only thing you can do is to create a pretend ContentLength that is (for example) =MaxInt or =Max Size of your transcoder buffer; and fail gently if the user listens to the media long enough to overflow the buffer..

Hi Andrew,
Thank for the suggestion. I've been thinking along similar lines. I suppose I'd probably have to set the DLNA transcode flag (CI=1) so it doesn't try seeking (is that allowed for audio, it's been a while since I messed with those).

[bob]

With a real time stream, is a transcoder buffer not usually a circular arrangement of a few minutes length that reuses from the beginning when the end is near?

I wondered why the Foobar UPnP addon creates an end time of 6h45m48s. Hardly an arbitrary choice 

It has to have a content length regardless of the transcode buffer method or the renderer that can't handle streams will refuse to play it.
In a way this is a problem that is going away as devices get better at handling content.
My 2018 Samsung TV plays just about everything without conversion. A few years ago that was simply not the case.
 6h45m48s is probably equivalent to 2 gigs in whatever format they are converting to.

[pluto]

It has to have a content length .... or the renderer that can't handle streams will refuse to play it.

That seems odd in view of the fact that the renderer in question can handle 'endless' streams in the form of internet radio. Is that so very different from DLNA streaming?

[bob]

That seems odd in view of the fact that the renderer in question can handle 'endless' streams in the form of internet radio. Is that so very different from DLNA streaming?

There are a lot of different format streams out there, perhaps it can handle some and not others.
Also, it's very common for devices that have multiple methods of accessing content to not have equal capability across the access methods.
Internet radio originally meant a shoutcast type of content and many devices (like the Noxon radio we have) are setup for that specifically.
Add to that, DLNA is really completely file based. Andrew might have more to say on this...
The 6h45m48s duration/content-length hack shows that various servers are trying to account for these shortcomings.

[pluto]

Oh, it could be so much simpler if the spec. were to be worked out now.

Anyway, many thanks for your work on this. Does it look promising?

[bob]

Oh, it could be so much simpler if the spec. were to be worked out now.

Anyway, many thanks for your work on this. Does it look promising?

I think so. Just need some time to work on it...

[pluto]

I think so. Just need some time to work on it...

Better good than quick 

[RoderickGI]

Well, I have had a bit of a play. In summary, I couldn't get playback of the BBC Radio streams to a DLNA Renderer working with or without transcoding.

First, surprisingly, the UK only streams wouldn't work even when I was connected via a VPN to a UK server. They must be using tricky stuff to work out I am actually in Australia. The non-UK stuff played in MC just fine.

I tried playing the non-UK Playlist items to BubbleUPnP and JRiver for Android as DLNA Renderers on my phone. I was pushing the content from my MC Server to the DLNA Renderer. I tried no transcoding and also with "specified format when necessary" set including the "URL" format to be converted to "PCM L16 No Header" and later "MP3 Low Bandwith".

No success there so I added a Duration field to each item in the Playlist in the form;
<Field Name="Duration">14400</Field>
and edited the "Length In PCM Blocks" field from -1 to a reasonable value;
<Field Name="Length In PCM Blocks">636451200</Field>

BubbleUPnP said it didn't have a Decoder for the stream, and that it couldn't play the video! So the video message is a bit weird. I played with the settings a bit but made no significant progress. The Renderer did recognise that I was pushing, for example, "BBC Radio Four FM" to it, but wouldn't play anything. I could have tried tweaking more settings in BubbleUPnP but didn't want to go too far and break my configuration, and besides, the discussion above indicates that there needs to be more done in MC, so I didn't want to spend too much time on it. But if I configured a decoder that could handle the original stream format, it looked like BubbleUPnP would have played it.

BubbleUPnP was connected to the MC Server, so it could see the "Imported Playlists" Playlist group, the specific "BBC streams non-UK" Playlist, and the individual channels content. So the DLNA View functionality in MC is working fine.

JRiver for Android, or more correctly the MC Server, thought it was playing the first five seconds of the content to the Renderer, and then it would just stop. Nothing appeared in JRiver for Android to show that it tried playing. I ran a short log of the attempt to play, which showed there was a bunch of searching for Cover Art on YADB and similar things, including trying to connect to Amazon Webservices, but I could see a specific relevant message. The Amazon Webservices was a bit strange though, like MC was trying to get the audio from Cloudplay.

JRiver for Android didn't show any Playlists from the MC Server of course, because it doesn't have the capability to connect to an external DLNA or MC Server at this time.


Anyway, given the above discussion, that is probably enough testing for now...

Oh okay, I installed VLC for Android just to see what happened.

First, VLC could see the MC Server the "Imported Playlists" Playlist group, the specific "BBC streams non-UK" Playlist, but not the individual channels content. It said that the directory was empty. I didn't get much further than that as VLC didn't show up as a DLNA Renderer in MC. VLC on my PC behaved the same. I suspect that I would have to install more VLC components to get that working, and not being a VLC user generally, I ran out of time.

[pluto]

Well many thanks for your extensive efforts and it appears that your findings largely track mine although I didn't go anywhere near Android or the like. The only alternative approach that I tried was using Foobar's UPnP server which has, usefully, proved that it can be done, and it appears likely that Bob's theory that the Roberts radio is having difficulty with playlist streams because of their 'advertised' duration, is on – or near – the money. If you read the earlier bit of this thread, the real clue is that the Foobar UPnP server falsifies the duration of the running programme.

I was interested in your approach –

I added a Duration field to each item in the Playlist in the form;
<Field Name="Duration">14400</Field>
and edited the "Length In PCM Blocks" field from -1 to a reasonable value;
<Field Name="Length In PCM Blocks">636451200</Field>

Does that approach actually change things as far as the header sent to the rendering device is concerned? I had assumed that <Field Name="Duration"> and Length In PCM Blocks and the like applied merely to the local database rather than having any effect whatsoever on the stream itself.

Once again, many thanks for your help.

[RoderickGI]

You won't believe this.

I just started MC again this morning, open BubbleUPnP on the phone and selected it as the Zone in MC, then tried to play your non-UK BBC One Playlist.

It worked. It is playing on my phone now.


I have seen this before, where testing in MC with DLNA gets "lost" in different settings changes. Particularly when multiple Zone changes are involved. DLNA is so flaky! I should have restarted everything after editing the Playlist duration. The PC has been rebooted this morning. The phone has not.

Anyway, I can't say if the header sent to the phone has been updated with my changes or not. There is no duration shown with the metadata in BubbleUPnP. Only how long the stream has been playing. BUPnP does recognise it as a Stereo 44.1KHz stream and displays the correct m3u8 URL.

I recommend you try editing a Playlist to add just the Duration and see if that works. If not, edit the "Length In PCM Blocks" as I did to see if it then works. Maybe that is a simple solution for you. It was why I asked for a copy of your Playlist.


BBC One has been playing for over 10 minutes now. I think that is proof of stability.

My MC Server is reporting the duration in the top display line of Standard View, showing "15:37 / 4:00:00" for example. It is a bit of a worry that MC is reporting it is at position 16:22 while BUPnP is reporting 14:00. I guess that could be partly buffering, but the gap seems to be growing so there appears to be a clock difference or something. I think this line from the log I just ran tells the story:
0001015: 12392: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {BubbleUPnP (G8141)} Playback state is PLAYING but GetPosition is funky. Returned = 1127000, Estimated = 1316503, Real duration = 0

It could be that my rough guesstimate of the "Length In PCM Blocks" as compared to the Duration is causing this problem. I think DLNA, being "file based", thinks in PCM Blocks, and uses the Duration to work out elapsed time per PCM Block, or something like that. So MC is calculating the incorrect Position based on the inaccurate information I provided.

Anyway, I was happy to test because understanding DLNA a bit better is one of my things at the moment. Every so often I test DLNA (in general, not just with MC) to see if it has matured enough to be of practical, reliable use. The jury is still out. It works well in specific configurations, but isn't reliable in a changing environment.

BBC One has now been playing for 26:40 on BUPnP, and 31:10 on MC. 

[RoderickGI]

PS: In case it wasn't obvious in the above, MC isn't doing any transcoding, despite the MC DLNA Server being set to "Specified output format when necessary" and including "URL" in the "Audio formats to convert".

The MC Audio Path shows that the MC Audio Engine isn't being used. BubbleUPnP must have indicated that it can play the stream as is, which is what is happening.

BBC One is now up to 53 minutes in MC. 

[RoderickGI]

Over 3 2 hours and still going. It seems that MC is providing the more accurate elapsed time, currently with 3:05. BUPnP is currently showing a little over 2:35.

EDIT: Oops. Neither durations are accurate. It was only ~2 hours actual elapsed time since I started playing BBC One.

[AndrewFG]

It could be that my rough guesstimate of the "Length In PCM Blocks" as compared to the Duration is causing this problem. I think DLNA, being "file based", thinks in PCM Blocks, and uses the Duration to work out elapsed time per PCM Block, or something like that. So MC is calculating the incorrect Position based on the inaccurate information I provided.

Yup. UPNP is indeed “file based”. And there are a few attributes that play a role in this — namely Size (in bytes), Duration (in time), Bit Rate (in bits or bytes per second) and/or Sample Rate (in Samples per second), Channel count, and Sample size (in bits).

Depending on the media format some of these attributes can be derived from the others (e.g. Bit Rate = Size / Duration, or Size = Sample Rate x Duration x Channels x Sample size, etc.)

To make things even more challenging, some of these attributes are communicated from server to renderer via two or three parallel communication means (e.g. Size is sent in the HTTP ContentLength header, and in the meta data, and also often as a header or tag within the stream itself. Sample Rate, Channels and Bytes per Sample may be in the Mime-Type, in tags in the stream, and in the meta data. Duration may or may not be in the meta data, and/or not in the tags in the stream; and if it is absent it is usually best to calculate it from the other fields as implied above. Etc. etc. ..

As a general rule, it is important that these attributes and the relationships between them are self consistent. My own Whitebear server and renderer have code to read these respective attributes from whatever source they may come, to fill in any blank values by cross calculation, and pass them on to the render via all appropriate communication means. This code is quite furry.

And it is even more fun with lossless compressed streams (like flac where Size is NOT equal to Duration x Sample Rate x Sample Size, or on lossy compressed streams with Variable Bit Rate)

Furthermore, when media is file based, often the tags (e.g. ID3v2 tags) are at the end of the file, and so in some renderers before they actually start playing the file, they often do an HTTP Content Range seek to fetch data starting at ContentLength minus X, so they can unpack the tags before starting to actually play the file. Obviously a seek to ContentLength minus X wont work on a stream, so it’s necessary to include the necessary HTTP headers in all responses so as to discourage renderers from trying such tricks.

[pluto]

I added a Duration field to each item in the Playlist in the form;
<Field Name="Duration">14400</Field>
and edited the "Length In PCM Blocks" field from -1 to a reasonable value;
<Field Name="Length In PCM Blocks">636451200</Field>

Sadly, a quick check suggests that this approach makes no difference to the [lack of] visibility of the streams in question on the Roberts radio. I will perform a more thorough (and more careful) check later, but so far nothing.

[RoderickGI]

Sadly, a quick check suggests that this approach makes no difference to the [lack of] visibility of the streams in question on the Roberts radio. I will perform a more thorough (and more careful) check later, but so far nothing.

Note that when I am testing, I am pushing the stream from MC to my Android phone, using the MC interface. If you are trying to see the stream on the Roberts, then it sounds like you are trying to pull the streams from the MC Server to the Roberts, using the Roberts interface.

Try using a remote such as Gizmo as a DLNA Controller to push the stream to the radio. I just confirmed that I was able to connect Gizmo to my MC Server, select the playback device as BubbleUPnP, and push one of the BBC streams to BUPnP on my phone. The same phone that Gizmo is running on, but still a valid test.

When I try to use BUPnP to pull the streams to itself I still get the "no decoder" error message.

First step: Confirm the Roberts can play the stream that MC sends to it.
Next steps: Work out how to make it convenient.


Andrew, that is why I consider DLNA to be flaky. There are just too many moving parts, and none of them are supported consistently. If you set up a configuration and it works, it can be great. If you are doing a bit of mix and match, and using different components, not so much. Damn shame, as it should be great. But alas...

[pluto]

I doubt that pushing the stream to the radio will prove anything practical, as I need to get this radio (and, potentially, hundreds like it) working in good old fashioned pull mode.

Push mode, I tell myself, is little more than a hi-tech fancy way of achieving what we used to do with an extension speaker   

[bob]

This is a great discussion, thanks all for your participation.

pluto, if you create a mixed playlist for the Radio containing both fixed audio tracks and a stream or two, how does that show up on the radio? Empty or just missing the streams?

[RoderickGI]

I doubt that pushing the stream to the radio will prove anything practical

My intent was to see if the Roberts would play the streams when they are pushed to it, and if so, Bob could investigate what the difference is in the streams sent when they are pushed, or pulled.

Then if that works out, get the streams to appear in the Playlist.

As I said:

First step: Confirm the Roberts can play the stream that MC sends to it.
Next steps: Work out how to make it convenient.

If the mixed Playlist allows the streams to be seen, and they play, then all good.

[pluto]

if you create a mixed playlist for the Radio containing both fixed audio tracks and a stream or two, how does that show up on the radio? Empty or just missing the streams?

From what I remember from an experiment the other night, the latter.

But it's midnight-30 here now so too late, but I will confirm in the morning. Now confirmed. Local file playlist entries are visible and play as expected. Stream entries are not visible.

[pluto]

May I enquire (of Bob?) how work on the above is progressing with a possible ETA for a fix? Thanks.

[AndrewFG]

Andrew, that is why I consider DLNA to be flaky. There are just too many moving parts, and none of them are supported consistently. If you set up a configuration and it works, it can be great. If you are doing a bit of mix and match, and using different components, not so much. Damn shame, as it should be great. But alas...

To be fair, the committees who developed the standard, have addressed many of the issues in later versions of the standard. However no manufacturers have bothered to implement those later versions. — Either a) because they believe they can achieve better world domination by pushing their own proprietary solutions (e.g. Apple), or b) because it is cheaper to be “just good enough” (e.g. the Asian equipment makers).

[RoderickGI]

That's partly why I keep testing it every now and then, particularly when I buy new equipment, or update it.

One day everyone shall use the latest DLNA Standard, and all shall work well... maybe.

[Scobie]

Given the Alliance has been dissolved (as pointed out on their website), is it still under active development or do manufacturers drive requirements/advances?

[JimH]

Given the Alliance has been dissolved (as pointed out on their website), is it still under active development or do manufacturers drive requirements/advances?

It's moving toward a de facto standard.  On their web site, there is a reference to a company that does compliance testing, but I doubt they have much influence on DLNA implementations.

JRiver never participated in the DLNA group because it was expensive.  We wrote our own from the ground up beginning about 2006.  It has evolved over time.

The hard part was to build in enough flexibility to handle the idiosyncracies of all the implementations.

I believe that most companies license their DLNA from a few providers and that those providers started with the Intel UPnP code and added to it.

There are a lot of broken implementations, but gradually they have gotten better, to the point that they now usually work.

I think our implementation has become important enough that many manufacturers use it to test against.

AndrewFG, please correct me if I'm wrong about any of this.

[pluto]

So how's progress on this particular issue please Jim?

[bob]

So how's progress on this particular issue please Jim?

I don't consider it to be an issue, "fixing it" is kind of a hacky workaround for devices that can't play streams.
That said, I've been working on it as time permits.

[pluto]

Agreed - it's most certainly a way of propping up devices that are (possibly) not within spec., but there do seem to be server programs out there that acknowledge the need for this kind of kludge.

But I would have hoped that the option of synthesizing a false duration, to make an otherwise-useless stream playable, would not be too tricky to implement, and worth doing.  Thanks for your efforts thus far – I suspect this might be a more significant issue for your European customers than those Stateside.

We also have the (?related) issue that transcoding appears not to work when sending playlist items via DLNA.

[bob]

Agreed - it's most certainly a way of propping up devices that are (possibly) not within spec., but there do seem to be server programs out there that acknowledge the need for this kind of kludge.

But I would have hoped that the option of synthesizing a false duration, to make an otherwise-useless stream playable, would not be too tricky to implement, and worth doing.  Thanks for your efforts thus far – I suspect this might be a more significant issue for your European customers than those Stateside.

We also have the (?related) issue that transcoding appears not to work when sending playlist items via DLNA.

There are a couple of different ways to do the kludge and I think I'll do the one I didn't start down the path on.

I can see why the playlist items aren't getting transcoded, essentially the playlist itself would need to be re-written when sent.