Print

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

[zoicoster]

Hi,
I have a MC 21 and I find this bug, only when I'm playing .cue files with my PS Audio Media Player DLNA  (Bridge II). The problem is that I view the tracklist, but  the next/previous buttons don't work. It "is" only one playing file. The files play but when I click Next button MC starts playing first track over (though in the list of tracks it shows playing 2nd, 3rd etc.). It happens only when I use DLNA renderer; direct sound device works fine.

This is not my renderer issue, but seems like software bug. When I use another program, like DSAudio, all is ok.

Please help me, thank you

Alberto

[sskom]

The same problem here. JRiver MC21, DirectStream Bridge II, Media Center on Synology NAS. Minimserver plays first track only too.

[zoicoster]

Also I have Media Center on Synology NAS. I don't use Minimserver

[AndrewFG]

This is not my renderer issue, but seems like software bug. When I use another program, like DSAudio, all is ok.

Indeed. When you press the Next button, MC should convert that into a Seek() command. And the renderer should convert that to a Byte-based GET for the respective seek offset. However on many types of file, MC a) does not provide enough information to the renderer to calculate its Byte-based seek offset, or b) does not support the respective seek GET call.

It is a known weakness in MC, and I have been campaigning for JRiver to fix it for years..

[zoicoster]

Thank you for your support. I'll hope that the bug will be resolved...

[zoicoster]

I also would get on psaudio forum:

http://www.psaudio.com/forum/jriver-music-player-tutorial-for-pc-and-mac/help-bug-witn-playing-cue-file-and-dlna/#p54810

PsAudio makes excellent Dac and streamer and MC seems to be a really good partner...

[JimH]

Andrew,
We'll get it.  Thanks for the reminder, and for all your help.

Jim

[zoicoster]

Thank you again!

[AndrewFG]

Andrew,
We'll get it.  Thanks for the reminder, and for all your help.
Jim

Hi Jim, It niggles me so much that I have often considered building an application that wraps/proxies regular UPnP renderers as "Renderer by Whitebear" and advertises itself also as a UPnP renderer to MC. It would do the following:

- Act as a proxy server that responds to TCP HTTP and UDP NOTIFY's from the regular renderer and proxies the messages onwards to MC
- Act as a proxy server that responds to HTTP GETs & POSTs from MC and proxies the calls onwards to the regular renderer
- Act as a proxy server that responds to HTTP GETs from the regular renderer and proxies the calls onwards to MC with some translation as follows:
- Tweak HTTP header fields and add ones like Content-Length, Accept-Range, etc. when MC fails to provide them
- Convert renderer byte-based seek requests that MC won't support, to native MC requests where MC does support seek, and transcode MC's native format to the format requested by the renderer.
- Pass through most of MC's Control Point commands verbatim making (possibly) the following changes:
- Selectively replace track URLs on MC to track URLs on itself, so it can do the above mentioned proxy actions, (or not in the case of native formats)..
- In the case MCs meta data does include the full trio of file size, track duration, and bits-per-second, adding the respective missing meta data element.
- Possibly in the cue file case mentioned in this thread, perhaps trying to convert a Next() command to a Seek() ..

This is basically what I did with my Whitebear renderer front end to the Logitech Media Server. So I know it is doable. But it would be a kludge. And quite some work for me. That would become obsolete when you finally decided to fix it inside MC properly. So I lack motivation..

[zoicoster]

Hi, has this bug  resolved? Or it is better to wait the new version of MC?

thank you again

[bob]

Indeed. When you press the Next button, MC should convert that into a Seek() command. And the renderer should convert that to a Byte-based GET for the respective seek offset. However on many types of file, MC a) does not provide enough information to the renderer to calculate its Byte-based seek offset, or b) does not support the respective seek GET call.

It is a known weakness in MC, and I have been campaigning for JRiver to fix it for years..

Not that we are only taking about files sent in "Original Format" here. Cue/bin files sent as say 24 bit PCM work fine already.

When MC provides a content-directory entry to the rendering device you will see something like this:


Track 1:
audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000
duration=0:02:20.000
size=40050359
nrAudioChannels=2
sampleFrequency=44100
bitsPerSample=16
bitrate=29875
http://192.168.131:52104/Music/F100469.mp3


Track 2:
audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000
duration=0:00:56.000
size=40050359
nrAudioChannels=2
sampleFrequency=44100
bitsPerSample=16
bitrate=29875
http://192.168.131.131:52104/Music/F100470.mp3

and so on.

Some particular renderer does a request like this:
GET /Music/F100469.mp3 HTTP/1.1
Host: 192.168.131.131:52104
User-Agent: NSPlayer/8.0.0.3801
transferMode.dlna.org: Streaming
getcontentFeatures.dlna.org: 1
Range: bytes=0-
Connection: close


We reply with:
HTTP/1.1 200 OK
transferMode.dlna.org: Streaming
Content-Type: audio/mpeg
contentFeatures.dlna.org: DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000
Server: Windows, UPnP/1.1 DLNADOC/1.50, JRiver/21
Content-Length: 40050359
Accept-Ranges: bytes
Connection: close
Date: Mon, 20 Jun 2016 17:24:24 GMT

Followed by the data...

Now the only difference between the 2 content directories are the Duration and the File to retrieve. Of course in the second case the file is the same but it's entry in MC's database contains a playback range (which is time based of course).

The renderer being unable to support time based seeks (90% or so of them) can only get one thing back that might work as far as I can see and that is a byte range into the file which we need to calculate for all of the different possible file types (since we can't give it a middle of a frame).

So when the renderer asks us for bytes 0- on the second track we will need to return something like 123456-40050358/40050359 and hope it can deal with it.

Does this sound correct?

Also note that we return the complete length of the bin file since it can continue to play gapless through the track transitions...

Does this sound right to you Andrew?

[AndrewFG]

So when the renderer asks us for bytes 0- on the second track we will need to return something like 123456-40050358/40050359 and hope it can deal with it.

Does this sound correct?

Also note that we return the complete length of the bin file since it can continue to play gapless through the track transitions...

Does this sound right to you Andrew?

Actually no. Not quite

But bob, let me think about this for 24 hours more, and I promise to get back to you with some useful suggestions.

EDIT: One question: Where do you get the bitrate 29875 from? If you are serving a 240kbps CBR MP3 file, that would be 30000 bytes per second..

[bob]

Actually no. Not quite

But bob, let me think about this for 24 hours more, and I promise to get back to you with some useful suggestions.

EDIT: One question: Where do you get the bitrate 29875 from? If you are serving a 240kbps CBR MP3 file, that would be 30000 bytes per second..

Sure, thanks for thinking about it!

The 29875 bitrate is the average since it's a VBR file.

[AndrewFG]

Ok bob, here you go..

1. Differentiate Individual Tracks from the Whole Album Track

On one hand we want to present the album as a single track, and on the other hand we want to present it as a multiple set of tracks. Some users may want to play the “whole album track” straight through gaplessly, other users may want to play its individual tracks, and yet others may want build playlists comprising a mix of single tracks from the album mixed with tracks from other albums. We need to separate these various use cases.

Therefore I suggest that the MC content directory (and its user interface) shall present such an album with both a “zero track” that represents the “whole album track”, plus a set of individual regular tracks based on the cue sheet.

So for example it would present such an album in the content directory as follows:

  Track #0 = whole album = start 0:00:00 / duration 0:05:50 / bitrate = 29875 / size = 10456250
  Track #1 = first track = start 0:00:00 / duration 0:02:20 / bitrate = 29875 / size = 4182500
  Track #2 = second track = start 0:02:20 / duration 0:01:10 / bitrate = 29875 / size = 2091250
  Track #3 = third track = start 0:03:30 / duration 0:02:20 / bitrate = 29875 / size = 4182500

2.   Handling User Next & Previous Track Requests

The MC User Interface must respond internally to user Next & Previous commands differently depending on whether it is currently playing the zero track or it is playing a regular track. If it is playing a regular track and the user presses Next or Previous, then MC must in the normal manner push the respective Next or Previous track’s URL by means of SetAVTransportURI. But if it is playing the zero track and the user presses Next or Previous, then MC has to determine the next or previous regular track by comparing the elapsed playing time in the zero track against the cue sheet, and then it must push the URL of the respective regular track by means of SetAVTransportURI.

3.   Handling the Renderer HTTP GET Commands

If the Renderer does a GET for the zero track, then the MC server must serve the full track, and it must give the exact Content-Length of the full album.

  GET /Music/F10000.mp3 HTTP/1.1  { zero track }
  Connection: close

  HTTP/1.1 200 OK
  Accept-Ranges: bytes
  Connection: close
  Content-Type: audio/mpeg
  Content-Length: 10456250    { full album size }

If the Renderer does a GET for a regular track, then the MC server must serve the part of the full album that corresponds to the respective track only (more on this in item 5. below), and it must give an accurate albeit calculated value of the Content-Length of that track only.

  GET /Music/F10001.mp3 HTTP/1.1  { regular track }
  Connection: close

  HTTP/1.1 200 OK
  Accept-Ranges: bytes
  Connection: close
  Content-Type: audio/mpeg
  Content-Length: 4182500    { (this track duration) * (average bit rate) }

4.   Respect the HTTP Specifications

The MC Server must comply with the HTTP specifications. If the Renderer does a GET containing a Range: bytes header (e.g. Range: bytes=0- ) then the MC Server must respond with HTTP 206 Partial Content, (and not with HTTP 200 OK), and it must give both a valid Content-Range and a valid Content-Length value.

  GET /Music/F10000.mp3 HTTP/1.1  { zero track }
  Range: bytes=0-
  Connection: close

  HTTP/1.1 206 Partial Content
  Accept-Ranges: bytes
  Connection: close
  Content-Type: audio/mpeg
  Content-Range: 0-10456249/10456250    { full album size }
  Content-Length: 10456250    { full album size }

+++

  GET /Music/F10001.mp3 HTTP/1.1  { regular track }
  Range: bytes=0-
  Connection: close

  HTTP/1.1 206 Partial Content
  Accept-Ranges: bytes
  Connection: close
  Content-Type: audio/mpeg
  Content-Range: 0-4182499/4182500    { (this track duration) * (average bit rate) }
  Content-Length: 4182500    { (this track duration) * (average bit rate) }

5.   Determining the File Offset for HTTP GET’s on Regular Tracks

If the Renderer does a GET for a regular track, (actually a regular track that is not the first track), then the MC server must start serving the stream from a valid frame boundary. The cue sheet provides a time based start point (e.g. start 0:02:20 / duration 0:01:10 ), and the MC Server has to convert these into a respective byte point.

If the media format has fixed frame sizes (L16) then the start byte point is calculated using the following algorithm:

  Start Byte := Trunc ( Start Time * Byte Rate div Frame Size ) * Frame Size;

Whereas if the media format has identifiable frame headers (MP3, FLAC, ALAC) then the start byte point is calculated using this algorithm:

  Start Byte := Start Time * Byte Rate; ++ spool forward until next frame header is found;

( For other media formats the best solution would probably be to “transcode” the source file to its own format using a time based seek e.g. use the SOX audio transcoder with identical source and destination formats, but applying a command line switch to set a time based seek. )

The MC server must continue serving the stream until it has delivered the number of bytes that it has previously declared in its Content-Range or Content-Length header. Or until it hits the end of the file. At this point the MC server must close the socket connection.

[JimH]

Thanks very much, Andrew.