Print

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

[AndrewFG]

If you're still interested, I can send traces of these modes to see what's going on.

Sure. Go ahead.

[AndrewFG]

FLAC does work with HTTP_mode=fixed. UPnPBridge then assigns an arbitrary length defined in its config.xml (eg., <stream_length>1000000000</stream_length>). JRiver fails to advance to the next track in a playlist with gapless set to "yes" or "no," but does work with "force." If you're still interested, I can send traces of these modes to see what's going on.

I got your PM with the new traces. You can see the GET transactions below..

With LMS set to "HTTP Mode fixed" -- the LMS server sends the file with a "munged" Content-Length of 2048000000; the MC renderer accepts this and downloads the full 36 MByte file; AND the MC renderer actually plays the flac track..

Code: [Select]

GET /bridge-1.flac HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 Edge/12.246 JRiver_Internet_Reader/2.0 UPnP/1.0
Icy-Metadata: 1
Host: 192.168.6.142:49154
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: Squeezebox-player=bb%3Abb%3Aa6%3A40%3A7d%3A96

HTTP/1.1 200 OK
Server: squeezebox-bridge
Connection: close
Content-Type: audio/flac
Content-Length: 2048000000

>> flac media data starts here


With LMS NOT set to "HTTP Mode fixed" -- the LMS server sends the file "Chunked"; the MC renderer accepts this and downloads the full 36 MByte file; BUT the MC renderer does NOT play the flac track..

Code: [Select]

GET /bridge-1.flac HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 Edge/12.246 JRiver_Internet_Reader/2.0 UPnP/1.0
Icy-Metadata: 1
Host: 192.168.6.142:49153
Connection: Keep-Alive
Cache-Control: no-cache

HTTP/1.1 200 OK
Server: squeezebox-bridge
Connection: close
Content-Type: audio/flac
Transfer-Encoding: chunked

8000
>> flac media data starts here



Concerning gapless play: The principle of gapless play is that the Control Point gives the renderer two track URLs to play (the first is sent using SetAVTransportURI, and the second is sent using SetNextAVTransportURI); the renderer plays the first track, and figures out when it is due to end; it also pre-loads the second track into memory; and at the point the first track is due to end, the renderer can immediately start playing the second one.

Now, if the server is serving the files either with a "munged" Content-Length, or Chunked (i.e. without a Content-Length at all), then the renderer has no way to figure out when the first track is due to end; so it has no way to switch gaplessly to the second track. Period.

If, as above, gapless is not supported, then the Control Point must send the first track using SetAVTransportURI, and then it monitors the renderer's Transport State until it transitions from PLAYING to STOPPED; at which point the Control Point sends the second track using SetAVTransportURI; this transition PLAYING (track 1) => STOPPED => PLAYING (track 2) is what causes the gap.

You pointed out that LMS seems to have a mode setting to "force" gapless play. Actually this is not really proper gapless playback. I cannot figure exactly what it is doing, but I think that rather than LMS monitoring the renderer's Transport State (GetTransportState) it is instead monitoring the renderer's position (GetPositionInfo) so instead of waiting for the transition PLAYING to STOPPED, it already pushes the second track towards the end of playing the first track but before it actually ends. This is a kind of sleight-of-hand trick that may appear to be less gappy than a full PLAYING (track 1) => STOPPED => PLAYING (track 2) transition.

[AndrewFG]

JRiver fails to advance to the next track in a playlist with gapless set to "yes" or "no," but does work with "force."

PS I did not check the traces, but my guess is that this is because (without "force") the MC renderer is still waiting for the "munged" Content-Length of 2048000000 bytes to have been served, and so the renderer doesn't make a TransportState transition from PLAYING (track 1) => STOPPED; it is probably just sitting there with TransportState = PLAYING (or possibly TransportState = TRANSITIONING) -- although I suppose that eventually the MC renderer download should time out, at which point the CP would be able to push the second track.

EDIT: I have now checked the traces and I can confirm that when the MC render has played the 36 MBytes of actual media it changes from TransportState = PLAYING to TransportState = TRANSITIONING; and then it just sits there waiting (TRANSITIONING) for the rest of the "munged" Content-Length of 2048000000 bytes to arrive; and then finally 45 seconds later it times out and switches to TransportState = STOPPED

[theriverlethe]

Interesting stuff, thanks. Any idea why UPnPBridge (LMS UPNP control point helper application/plugin) can’t ascertain the actual content length? Is it a result of the FLAC format or something peculiar to LMS?

[AndrewFG]

Any idea why UPnPBridge (LMS UPNP control point helper application/plugin) can’t ascertain the actual content length? Is it a result of the FLAC format or something peculiar to LMS?

Actually it is a mystery to me.

If you the have the actual file on hard disk, then you can a) determine the file size on disk, AND also b) parse the file in advance to determine its playing time (duration). So..

• If you serve the file directly as is, then you can provide the Content-Length directly from a)
  
  
• If you want to transcode the track to a fixed bit-rate format such as WAV, AIFF, PCM (L16), or even MP3-CBR, then given the duration from b) and knowing and the target bit-rate you can set Content-Length = duration x bit-rate.
  
  
• If you want to transcode the track to a variable bit-rate VBR format such as FLAC or Apple Lossless, admittedly it becomes more difficult; but even in those cases you can often force the VBR encoder to a CBR mode (so for example you can encode to FLAC using zero compression) and so even in those cases you can usually make a reasonable guess for Content-Length.
  
  
• If i) the media is being delivered from a remote server, AND ii) the remote server does not give you a Content-Length either; then you really cannot make a reasonable guess for Content-Length. This is typically the (problem) case for live streams...
  

EDIT: PS perhaps since the LMS UPNP controller is "only" a plug-in, it may neither have access to the actual track on disk, nor have access to the track meta data (for the duration); that illustrates one of the problems of using plug-ins versus having a fully integrated application such as MC

[theriverlethe]

Does this explain why JRiver won’t advance to the next track even with gapless mode set to “no?” If you’re only referring to the traces from last night, HTTP mode was set to “fixed” in both The only difference was the gapless setting.

[AndrewFG]

Does this explain why JRiver won’t advance to the next track even with gapless mode set to “no?” If you’re only referring to the traces from last night, HTTP mode was set to “fixed” in both The only difference was the gapless setting.

I can only look at the traces. Only you can tell me if it actually plays. But I suppose with “fixed” and “forced” it would probably play. => Perhaps you can tell me if it does?

[theriverlethe]

I did tell you that it does.

[AndrewFG]

I did tell you that it does.

So “fixed” and “forced” is the solution! Phew. That was a bumpy ride. And along the road, we we learned (again) that MC has a bug with playing Chunked Flac.

[bob]

So “fixed” and “forced” is the solution! Phew. That was a bumpy ride. And along the road, we we learned (again) that MC has a bug with playing Chunked Flac.

It was interesting to read this thread.
I don't think there is an issue reading chunked flac, it's more likely that the input plugin doesn't like the lack of length on a flac which is typically not stream seekable. The length of the track in seconds is in the UPnP metadata but the plugin is likely looking for the file length to stop playing the track, not the length in seconds (which isn't necessarily totally accurate on non-cbr streams).

[AndrewFG]

I don't think there is an issue reading chunked flac, it's more likely that the input plugin doesn't like the lack of length on a flac which is typically not stream seekable. The length of the track in seconds is in the UPnP metadata but the plugin is likely looking for the file length to stop playing the track, not the length in seconds (which isn't necessarily totally accurate on non-cbr streams).

Hi bob, (I got your PM too), when you speak about the “input plugin” I guess you are referring to a part of MC?

You are right that the length and/or duration of the track should be in the meta data. But my real question is why you believe MC needs a length or duration at all? I had a conversation with Hendrik recently elsewhere on this forum, in which he felt that a (content) length or duration shouldn’t be required in advance at all, since the length is the number of bytes actually received from the server (“the length is what you get”)..

So in other words a GET response with i) regular transfer encoding and a valid Content-Length, ii) regular transfer encoding and a fake Content-Length, iii) regular transfer encoding without a Content-Length header, or iv) chunked transfer encoding, can be (should be) handled identically by MC, since the actual length is the actual number of bytes received until the instant when the server closes the connection.

[bob]

Hi bob, (I got your PM too), when you speak about the “input plugin” I guess you are referring to a part of MC?

You are right that the length and/or duration of the track should be in the meta data. But my real question is why you believe MC needs a length or duration at all? I had a conversation with Hendrik recently elsewhere on this forum, in which he felt that a (content) length or duration shouldn’t be required in advance at all, since the length is the number of bytes actually received from the server (“the length is what you get”)..

So in other words a GET response with i) regular transfer encoding and a valid Content-Length, ii) regular transfer encoding and a fake Content-Length, iii) regular transfer encoding without a Content-Length header, or iv) chunked transfer encoding, can be (should be) handled identically by MC, since the actual length is the actual number of bytes received until the instant when the server closes the connection.

I just don't think this is related to the http transfer at all.
The indication is simply that the issue you are seeing is format dependent.
The input plugin is the part of MC that takes the data in the particular format and unpacks  it into MC's internal 64 bit data format which eventually ends up on the output device in the correct format.
Each playable format has it's own input plugin. Wave, MP4, MP3, OGG, Flac, DSD, etc.

[Hendrik]

Bob is right that not every format is streamable. And some formats can even be encoded differently to either be streamable or not.
We can definitely handle streamed FLAC - if its designed to be streamable, eg. from an internet radio stream. A "normal" FLAC file may not be.

Unless we get a reproducable case for us to test here, there is little to say which case might apply here.

[theriverlethe]

It’s very easy to reproduce. Just install Foobar2000, get the UPNP MediaRenderer plugin, make sure “supports FLAC=true” in the plugin configuration, and attempt to stream a FLAC file to the JRiver renderer.

https://www.foobar2000.org/components/view/foo_out_upnp

[AndrewFG]

The indication is simply that the issue you are seeing is format dependent.

I’m not entirely sure about the “indication”. The OP did say he can push PCM to MC, but not Flac. And it is proven (via Wireshark traces) that when he pushes Flac, it is using chunked and failing. But he (the OP) did not give me any traces that might prove that when he successfully pushes PCM it is also using chunked. Personally I suspect that in the PCM case it is sending the file with a Content-Length..

[AndrewFG]

It’s very easy to reproduce. Just install Foobar2000, get the UPNP MediaRenderer plugin, make sure “supports FLAC=true” in the plugin configuration, and attempt to stream a FLAC file to the JRiver renderer.

https://www.foobar2000.org/components/view/foo_out_upnp

You may need to share the Wireshark traces (the last two traces) with the guys at JRiver.

[AndrewFG]

Bob is right that not every format is streamable. And some formats can even be encoded differently to either be streamable or not.
We can definitely handle streamed FLAC - if its designed to be streamable, eg. from an internet radio stream. A "normal" FLAC file may not be.

Unless we get a reproducable case for us to test here, there is little to say which case might apply here.

Hendrik, he’s given me a trace of pushing a Flac file to MC that failed, but should not have done. I have asked him to forward you the traces. At the least IMHO you have to fix the Flac case, but I think you have to fix more than that..

[theriverlethe]

Weren't the last two the ones that sort of succeeded with a fake content-length?

[AndrewFG]

Yeah, you’re right. Or should send him a full trace that failed (not “fixed”) and one that sort of succeeded (“fixed” but not “forced”).

[AndrewFG]

I just ran a few tests to see what formats the MC DMR can play depending on whether the track is delivered Chunked or with a regular Content-Length; the results are in the table below..

[bob]

I did a test to see what is being sent to MC with those defaults.
Even though foobar has a duration for the track it's not sending it when it does the SetAVTransportURI. If it sent a duration, this would likely work.

IMO foobar should send all of the metadata that it has for the track.

Code: [Select]

POST /AVTransport/control HTTP/1.1
Host:192.168.0.129:52106
Connection: close
User-Agent: foobar2000/1.x
Accept: */*
Soapaction: "urn:schemas-upnp-org:service:AVTransport:1#SetAVTransportURI"
Content-Length: 1074
Content-Type: text/xml; charset="utf-8"

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID><CurrentURI>http://192.168.0.137:56089/5/stream.flac</CurrentURI><CurrentURIMetaData>&lt;DIDL-Lite xmlns=&quot;urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/&quot; xmlns:dc=&quot;http://purl.org/dc/elements/1.1/&quot; xmlns:upnp=&quot;urn:schemas-upnp-org:metadata-1-0/upnp/&quot;&gt;&lt;item id=&quot;1&quot; parentID=&quot;0&quot; restricted=&quot;0&quot;&gt;&lt;dc:title&gt;foobar2000 audio stream&lt;/dc:title&gt;&lt;res bitsPerSample=&quot;16&quot; nrAudioChannels=&quot;2&quot; protocolInfo=&quot;http-get:*:audio/flac:*&quot; sampleFrequency=&quot;44100&quot;&gt;http://192.168.0.137:56089/5/stream.flac&lt;/res&gt;&lt;upnp:class&gt;object.item.audioItem.musicTrack&lt;/upnp:class&gt;&lt;/item&gt;&lt;/DIDL-Lite&gt;</CurrentURIMetaData></u:SetAVTransportURI></s:Body></s:Envelope>


[bob]

I'm not convinced that plugin isn't totally broken.
If I run a curl transfer on the URL that foobar pushes to MC, out of a 65MB file I get 868K then curl just spins waiting for more.
When I look at the tags of the data transferred:

Code: [Select]

$ metaflac --list stream.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 1152 samples
  maximum blocksize: 1152 samples
  minimum framesize: 0 bytes
  maximum framesize: 0 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 0
  MD5 signature: 00000000000000000000000000000000
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: true
  length: 40
  vendor string: reference libFLAC 1.3.2 20170101
  comments: 0

Not very useful.

[theriverlethe]

It works perfectly controlling a Denon receiver. It’s not intended as a browsable server, so I’m not sure why it should provide useful output in this context. I’m not familiar with curl, though...

[bob]

It works perfectly controlling a Denon receiver. It’s not intended as a browsable server, so I’m not sure why it should provide useful output in this context. I’m not familiar with curl, though...

Curl is just a very widely used command line utility for pulling http streams. I just tried a browser and wget (another utility for getting streams) and neither of them work either.
I have no idea what your Denon is doing, but from what I can see that plugin simply isn't working properly. At the very least it should be providing the duration in the DiDL.

[theriverlethe]

Why? The renderer should just play what it's given.

[bob]

Why? The renderer should just play what it's given.

Did you see that the header isn't providing the number of samples either?
At this point unless you can provide evidence to the contrary (that the plugin is producing a properly formatted stream) as far as I am concerned it's up to the author of the plugin to fix the problem.

Edit: And note that ALL of the information required to do that is already at their disposal.

[theriverlethe]

Denon clearly has no problem deriving the sample rate. Also tested with an LG television.

Edit: I got the plugins confused myself.

[bob]

Denon clearly has no problem deriving the sample rate. Also tested with an LG television.

Edit: I got the plugins confused myself.

The sample rate is provided. That's not an issue. The duration/number of samples/length is the issue. It's not provided anywhere that I can see and should be. We are not going to spend time changing MC to address a broken UPnP server.

This will be my last post on this subject until either there is a updated plugin or someone can refute the testing.

[theriverlethe]

LMS and Foobar2000 both implement FLAC streaming this way and clearly many renderers have no problem with it. I can use Foobar2000 as a DLNA renderer and output to JRiver's WASAPI or ASIO driver without a problem, so I suppose that counts as a solution.

[AndrewFG]

The duration/number of samples/length is the issue. It's not provided anywhere that I can see and should be. We are not going to spend time changing MC to address a broken UPnP server.

Bob, this is my point about indefinite length streams. Yes, a duration/size would be nice. But you need to be able to play streams where no duration/size is provided. The principle is that you download everything you can, until the server either reports the last chunk (chunk size 0), or it closes the connection. Then whatever you got from the server IS the size, by definition. Falling back on the lame argument that “the server is broken” is (IMHO) a cop-out..

[bob]

LMS and Foobar2000 both implement FLAC streaming this way and clearly many renderers have no problem with it. I can use Foobar2000 as a DLNA renderer and output to JRiver's WASAPI or ASIO driver without a problem, so I suppose that counts as a solution.

We aren't dealing with a transport layer issue. The transport could be UDP, TCP, USB, whatever.
It feels like you are making excuses for why the foo_upnp plugin shouldn't be fixed.
When have you seen an application with duration info not provide it in the DiDL?
Why doesn't it provide a properly formatted metadata block with the number of samples?
I think we've put way more time into this than it deserves where the foo_upnp maintainer has put in exactly 0 time into fixing their plugin.

[bob]

Hendrik made a change at the input plugin level to deal with content-length and duration free flac streams.
It will be in the next build.

[philippe_44]

Interesting stuff, thanks. Any idea why UPnPBridge (LMS UPNP control point helper application/plugin) can’t ascertain the actual content length? Is it a result of the FLAC format or something peculiar to LMS?

Because LMS would not give it to you because it does not know it, files are transcoded on the fly very often. Normally, when I send pcm formats, then I do calculate it from duration when I know it

[theriverlethe]

Hendrik made a change at the input plugin level to deal with content-length and duration free flac streams.
It will be in the next build.

Thanks, I look forward to testing it.

[philippe_44]

Concerning gapless play: The principle of gapless play is that the Control Point gives the renderer two track URLs to play (the first is sent using SetAVTransportURI, and the second is sent using SetNextAVTransportURI); the renderer plays the first track, and figures out when it is due to end; it also pre-loads the second track into memory; and at the point the first track is due to end, the renderer can immediately start playing the second one.

Now, if the server is serving the files either with a "munged" Content-Length, or Chunked (i.e. without a Content-Length at all), then the renderer has no way to figure out when the first track is due to end; so it has no way to switch gaplessly to the second track. Period.

Actually I disagree with that. Because it's not real time stream, the 1st URI's socket will close (or get a zero-length chunk) way ahead of the DAC running out of audio samples. So the player has plenty of time to grab the next URI and stitch samples to the current ones to do proper gapless (potentially with some resampling). Most UPnP players are not gapless because their implementation is crap, but it's not due to the standard or the lack of content-length

Now, in the LMS plugin, I've also added an option to do real gapless regarding of the player by doing this stitching and resampling myself, producing an "inifinite" stream, at the expense of metadata, unless the re-encoded stream is a format that supports icy.

[Hendrik]

Without SetNextAVTransportURI you are basically playing a timing game hoping that latencies are low enough for hardware buffers to not run out. To avoid such a potential failure point, SetNextAVTransportURI was added. Its quite a simple concept to just pass on the next URL early on so the renderer can request new data on its time, and not hope it works out when the previous one ended. Its a rather simple concept to just add much more reliability.

[bob]

Since I was only testing this setup with a single track I didn't see that the plugin stitches tracks in the playlist together which explains the lack of a content-length and duration.

That approach works within the limitations of the protocol, a total lack of metadata and no ability to seek. It's not very useful for a renderer with a display which properly supports SetNextAVTransportURI but I see it has some limited uses with headless network DAC's especially with ones that don't support SetNextAVTransportURI. We considered doing the same several years ago but let it go because of the shortcomings just discussed.

I apologize for getting caught up in the heat of the issue.
 

[philippe_44]

Without SetNextAVTransportURI you are basically playing a timing game hoping that latencies are low enough for hardware buffers to not run out. To avoid such a potential failure point, SetNextAVTransportURI was added. Its quite a simple concept to just pass on the next URL early on so the renderer can request new data on its time, and not hope it works out when the previous one ended. Its a rather simple concept to just add much more reliability.

So we agree that with SetNextTransportURI you can really have full gapless, regardless of Content-Length

[bob]

So we agree that with SetNextTransportURI you can really have full gapless, regardless of Content-Length

Yes, IMO.

[Hendrik]

So we agree that with SetNextTransportURI you can really have full gapless, regardless of Content-Length

As long as "regardless" means proper or none, a fake one is likely going to cause some stumbles.

[philippe_44]

Since I was only testing this setup with a single track I didn't see that the plugin stitches tracks in the playlist together which explains the lack of a content-length and duration.

That approach works within the limitations of the protocol, a total lack of metadata and no ability to seek. It's not very useful for a renderer with a display which properly supports SetNextAVTransportURI but I see it has some limited uses with headless network DAC's especially with ones that don't support SetNextAVTransportURI. We considered doing the same several years ago but let it go because of the shortcomings just discussed.

I apologize for getting caught up in the heat of the issue.

Sorry I was not clear. My plugin (it's a bridge between LMS and UPnP) offers 2 modes that are user-selectable

1- Uses the SetNextAVTransportURI (if available) - user can force to NOT use that by setting the gapless option (yes if permitted, no all the time). Each track is either send with its own format or decoded, resampled (option) and re-encoded to mp3,flac or pcm then sentto the UPnP devices - this allows better compatibility than just a passthrough. The gapless in that case is as good as the UPnP player's is.
2- Totally different, tracks can be decoded, resampled and re-encoded to mp3, flac or pcm and then stitched together to form an infinite stream. The gapless is really gapless then and it also allows LMS features like cross-fade. This mode comes at the expense of metadata, unless the player supports ICY (the bridge becomes a webradio)

[philippe_44]

As long as "regardless" means proper or none, a fake one is likely going to cause some stumbles.

Oh definitively. I hate the "fake" length, I had to add that because some players do not handle chunked-encoding (although they claim to be HTTP 1.1) or fail with 1.0 and no content-length. It's an ugly workaround which has the consequence that a normally "sane" player would re-open the connection if closed before the promised length has been received.