Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
BBC radio streams not working
05-03-2015, 08:27
Post: #231
RE: BBC radio streams not working
(04-03-2015 23:40)Pastim Wrote:  But that's not what the user guide says is it? Have I misread it? You state "Note: For a network stream whose original type is unspecified, the choice of output type is made by MinimStreamer (not the control point) when MinimServer opens the stream and discovers its type." So MinimStreamer makes the choice, and not the CP. What am I missing?

When the renderer plays stream #2, the following happens:

If nothing is set as the stream type and stream.transcode is set to '*:wav24/-^'

1) MinimStreamer finds the list of output types for '*'
2) MinimStreamer finds the caret on the untranscoded output type
3) MinimStreamer plays the stream without transcoding

If ';aac' was set as the stream type and stream.transcode is set to 'aac:wav24/-^'

1) MinimStreamer finds the list of output types for 'aac'
2) MinimStreamer finds the caret on the untranscoded output type
3) MinimStreamer plays the stream without transcoding

The sentence that you are quoting describes a different situation that would occur if nothing is set for the stream type and stream.transcode is set to 'aac:wav24/-^' with no setting for '*'. In this case, the following would happen:

1) MinimStreamer opens the stream and finds its type (aac)
2) MinimStreamer finds the list of output types for 'aac'
3) MinimStreamer finds the caret on the untranscoded output type
4) MinimStreamer plays the stream without transcoding

This produces the same result for stream #2. The important difference is that the same steps would also happen for stream #1, which is not desired.
Find all posts by this user
Quote this message in a reply
05-03-2015, 10:45
Post: #232
RE: BBC radio streams not working
(05-03-2015 00:10)Reg Wrote:  
(04-03-2015 21:03)simoncn Wrote:  When you turned off the MIME type check in BubbleUPnP, did that make the 714 error message go away?

Yes

It sounds like you are sending the file to the renderer in a format that the renderer can't play, such as AAC ADTS. With MIME type checking enabled, BubbleUPnP shows the 714 message to tell you that you are doing this. With MIME type checking disabled, BubbleUPnP tells the renderer to play the file but the renderer can't handle it.

You have said that you have enabled *:L16 transcoding and also that you don't have a stream type ';aac' in your playlist entry for the stream. You can confirm that these settings are active by navigating to the BBC Radio playlist in BubbleUPnP, clicking the "3 dots" icon to the right of the stream and selecting 'Show metadata' from the pop-up menu. You should see something like:

Stream #1 LPCM, http://192.168.0.10:9790/minimstreamer/*/R3/$!transcode.L16

Do you see this or something different?
Find all posts by this user
Quote this message in a reply
05-03-2015, 13:23
Post: #233
RE: BBC radio streams not working
(05-03-2015 10:45)simoncn Wrote:  It sounds like you are sending the file to the renderer in a format that the renderer can't play, such as AAC ADTS. With MIME type checking enabled, BubbleUPnP shows the 714 message to tell you that you are doing this. With MIME type checking disabled, BubbleUPnP tells the renderer to play the file but the renderer can't handle it.

The 714 error has actually nothing to do with the "mime-type check" in BubbleUPnP. This error comes straight from the renderer as a SOAP error for action SetAVTransportURI or Play. It can happen due to the following reasons:
  • it rejects the mime-type (or whole protocolInfo) specified in the protocolInfo in the DIDL passed to SetAVTransportURI
  • in its SetAVTransportURI (or Play) implementation, it makes a HEAD (or GET) request to the media server and rejects the Content-Type returned in the response
  • in its SetAVTransportURI (or Play) implementation, it makes a HEAD (or GET) request to the media server with the "getcontentFeatures.dlna.org: 1" request header and doesn't get the expected response header. That's for DLNA renderers mostly, that are super annoying with this.

Moreover, since renderers can be super picky with the DIDL that is passed to SetAVTransportURI, BubbleUPNP will retry with several variations of the DIDL, until one eventually works. The 714 error is probably the error of the last attempt although there's a good chance it is also the cause of the first failure.

The only way to know what happens is for the user to send me a log file (see here for instructions)

Disabling "mime-type check" is something entirely different: if disabled and BubbleUPnP cannot find a compatible resource to play, it will force play the first resource (which may or may not work). If enabled and it cannot find a compatible resource, it displays an error toast message about "no compatible mime-type" being found and doesn't attempt playback at all.
Find all posts by this user
Quote this message in a reply
05-03-2015, 13:37
Post: #234
RE: BBC radio streams not working
(05-03-2015 13:23)bubbleguuum Wrote:  The 714 error has actually nothing to do with the "mime-type check" in BubbleUPnP. This error comes straight from the renderer as a SOAP error for action SetAVTransportURI or Play. It can happen due to the following reasons:
  • it rejects the mime-type (or whole protocolInfo) specified in the protocolInfo in the DIDL passed to SetAVTransportURI
  • in its SetAVTransportURI (or Play) implementation, it makes a HEAD (or GET) request to the media server and rejects the Content-Type returned in the response
  • in its SetAVTransportURI (or Play) implementation, it makes a HEAD (or GET) request to the media server with the "getcontentFeatures.dlna.org: 1" request header and doesn't get the expected response header. That's for DLNA renderers mostly, that are super annoying with this.
Moreover, since renderers can be super picky with the DIDL that is passed to SetAVTransportURI, BubbleUPNP will retry with several variations of the DIDL, until one eventually works. The 714 error is probably the error of the last attempt although there's a good chance it is also the cause of the first failure.

The only way to know what happens is for the user to send me a log file (see here for instructions)

Disabling "mime-type check" is something entirely different: if disabled and BubbleUPnP cannot find a compatible resource to play, it will force play the first resource (which may or may not work). If enabled and it cannot find a compatible resource, it displays an error toast message about "no compatible mime-type" being found and doesn't attempt playback at all.

Thanks very much for explaining how this works!
Find all posts by this user
Quote this message in a reply
05-03-2015, 13:50
Post: #235
RE: BBC radio streams not working
(05-03-2015 08:27)simoncn Wrote:  
(04-03-2015 23:40)Pastim Wrote:  But that's not what the user guide says is it? Have I misread it? You state "Note: For a network stream whose original type is unspecified, the choice of output type is made by MinimStreamer (not the control point) when MinimServer opens the stream and discovers its type." So MinimStreamer makes the choice, and not the CP. What am I missing?

When the renderer plays stream #2, the following happens:

If nothing is set as the stream type and stream.transcode is set to '*:wav24/-^'

1) MinimStreamer finds the list of output types for '*'
2) MinimStreamer finds the caret on the untranscoded output type
3) MinimStreamer plays the stream without transcoding

If ';aac' was set as the stream type and stream.transcode is set to 'aac:wav24/-^'

1) MinimStreamer finds the list of output types for 'aac'
2) MinimStreamer finds the caret on the untranscoded output type
3) MinimStreamer plays the stream without transcoding

The sentence that you are quoting describes a different situation that would occur if nothing is set for the stream type and stream.transcode is set to 'aac:wav24/-^' with no setting for '*'. In this case, the following would happen:

1) MinimStreamer opens the stream and finds its type (aac)
2) MinimStreamer finds the list of output types for 'aac'
3) MinimStreamer finds the caret on the untranscoded output type
4) MinimStreamer plays the stream without transcoding

This produces the same result for stream #2. The important difference is that the same steps would also happen for stream #1, which is not desired.
I have read this 5 times. I have gone away, come back, and read it again. I still don't understand. There is, as I said, something about all this that is incomprehensible to me. For instance, in the 1st scenario, why is the renderer playing stream 2, and is there ever any case in which * would map to wav24? In the 3rd scenario the user guide makes no mention of this not applying if a '*' case is included (and indeed I thought it specifically did apply in this case) and I don't understand the logic of the last sentence at all.

What is clear is that I am too old and thick to understand minimstreamer's transcoding or your user guide and explanation here. Sorry. I'm sure it is simple, but I only ever seem to get a partial understanding of it. So you had better ignore me on this subject. I'll make it work somehow (although probably not with the transcoding I expect).
Find all posts by this user
Quote this message in a reply
05-03-2015, 14:58 (This post was last modified: 05-03-2015 14:58 by simoncn.)
Post: #236
RE: BBC radio streams not working
(05-03-2015 13:50)Pastim Wrote:  I have read this 5 times. I have gone away, come back, and read it again. I still don't understand. There is, as I said, something about all this that is incomprehensible to me. For instance, in the 1st scenario, why is the renderer playing stream 2, and is there ever any case in which * would map to wav24? In the 3rd scenario the user guide makes no mention of this not applying if a '*' case is included (and indeed I thought it specifically did apply in this case) and I don't understand the logic of the last sentence at all.

What is clear is that I am too old and thick to understand minimstreamer's transcoding or your user guide and explanation here. Sorry. I'm sure it is simple, but I only ever seem to get a partial understanding of it. So you had better ignore me on this subject. I'll make it work somehow (although probably not with the transcoding I expect).

In this two-stream case, the internet radio renderer is playing stream 2 because (as I explained in my previous post) this is the only stream it knows about. It is not possible for stream 2 to map to wav24 because wav24 transcoding has been applied only to stream 1.

I have made a small addition to the sentence from the User guide that you are quoting. The added words clarify that the sentence doesn't apply to any stream that has been transcoded using the '*' input type. I hope this change is helpful.
Find all posts by this user
Quote this message in a reply
05-03-2015, 16:19
Post: #237
RE: BBC radio streams not working
(05-03-2015 14:58)simoncn Wrote:  
(05-03-2015 13:50)Pastim Wrote:  I have read this 5 times. I have gone away, come back, and read it again. I still don't understand. There is, as I said, something about all this that is incomprehensible to me. For instance, in the 1st scenario, why is the renderer playing stream 2, and is there ever any case in which * would map to wav24? In the 3rd scenario the user guide makes no mention of this not applying if a '*' case is included (and indeed I thought it specifically did apply in this case) and I don't understand the logic of the last sentence at all.

What is clear is that I am too old and thick to understand minimstreamer's transcoding or your user guide and explanation here. Sorry. I'm sure it is simple, but I only ever seem to get a partial understanding of it. So you had better ignore me on this subject. I'll make it work somehow (although probably not with the transcoding I expect).

In this two-stream case, the internet radio renderer is playing stream 2 because (as I explained in my previous post) this is the only stream it knows about. It is not possible for stream 2 to map to wav24 because wav24 transcoding has been applied only to stream 1.

I have made a small addition to the sentence from the User guide that you are quoting. The added words clarify that the sentence doesn't apply to any stream that has been transcoded using the '*' input type. I hope this change is helpful.
When you said 'renderer' I assumed you meant UPnP renderer, so I was further confused. Since I don't understand much of the 'why' and consequences (e.g. why does Internet Radio only see stream 2, what happens if there is only 1 stream, what happens if I want 2 UPnP streams, and is this explained anywhere in the guides?) I fail to comprehend the 'what'. Age (well that's my excuse). At some point I will have to sit down and create a flow chart or similar and see if that helps me. I still get the feeling that 2 quite different things have been merged together in a way I will never quite fathom, and may have unexpected consequences.

Anyway, let's stop this series of posts on transcoding now. Thanks very much indeed for trying to help me. I apologise for taking up so much of your time.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)