Print

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

[olepro]

As i have the same problem as others playing gapless when pushing audio from JRiver to my playback device, i got this idea.

If we have one long file there is of course no problem with gapless playback, but we cannot jump from one song to another.
Cuefiles allso cause problems over DLNA only playing the track (file) from the beginning when jumping to next track.

Now, one thing i can do from JRiver is to scroll or jump to another place in the file with the scroll bar.

If JRiver would implement into their software the ability to add index markers to a file that was stored with the file in the library i could see this work.

You have one long file, and JRiver is controlling with index markers from the scrollbar where to go in the file.

The only thing is we have to find the tracks inside the file (album/video) and add the markers our selves, but i could live with that ;-)

Any comment's

[AndrewFG]

^

Two things...

1. You can already today do gapless playback with MC UPnP in a perfectly easy and regular manner, if you buy a renderer that properly supports SetNextAvTransportUri. So my recommendation to JRiver is to not waste any efforts in kludging around their own currently very good implementation of UPnP to produce a bad compromise "solution" to problems caused by other parties bad implementations of UPnP. They should rather invest their efforts in lobbying those other parties to do things right in the first place.

2. If I understand you right you are talking about having MC deliver over UPnP a "live" stream comprising several tracks stitched gaplessly together? And you are suggesting that Seeks would cause different portions of those tracks to be stitched into that live stream? Or did I misunderstand you? If this is indeed what you are suggesting, then there are two problems with the suggestion: i) it would only work if MC is the Control Point, any other CP would continue to be sending regular Seek commands to the renderer in the normal way, and the MC server won't see those Seeks and so it could not do this stitching magic in such cases, and ii) more importantly, UPnP streaming is not a synchronous delivery mechanism, and so the renderer may have a local buffer of several tens of seconds (if not minutes) of stream input; this means that even if the server where to do such stitching magic, the renderer would still continue to play through all the buffered music, so your Seeks could take tens of seconds or minutes before taking effect..

Edit: additional to point i) above, since a stitched stream would be of unknown length, the MC server cannot provide a Content-Length value, and therefore the renderer cannot calculate the destination of a Seek command, so any Seek command coming from a third party CP would at least fail, and possibly result in a CP error message...

[6233638]

1. You can already today do gapless playback with MC UPnP in a perfectly easy and regular manner, if you buy a renderer that properly supports SetNextAvTransportUri. So my recommendation to JRiver is to not waste any efforts in kludging around their own currently very good implementation of UPnP to produce a bad compromise "solution" to problems caused by other parties bad implementations of UPnP. They should rather invest their efforts in lobbying those other parties to do things right in the first place.

That's easy enough to say when your hardware does support proper gapless playback, but it's a lot easier and cheaper to fix via software than by replacing hardware.
 
While it would be a hack and come with its own limitations, it would be a useful option to have for DLNA clients that lack proper gapless support.

[AndrewFG]

While it would be a hack and come with its own limitations, it would be a useful option to have for DLNA clients that lack proper gapless support.

I don't believe in hacks. People should do the job properly. And anyway, as I explained in my point 2. this particular hack would not work anyway..

[JimH]

I don't believe in hacks. People should do the job properly. And anyway, as I explained in my point 2. this particular hack would not work anyway..

I agree.  We already make a lot of little changes to accommodate the idiosyncrasies of hardware, but there has to be a limit.

The gapless issue is important enough that I think the hardware manufacturers will fix it.

[6233638]

The gapless issue is important enough that I think the hardware manufacturers will fix it.

Most hardware manufacturers "fix" problems like this by releasing new hardware. (e.g. PS Audio Bridge)
 
I believe other players such as Foobar can do this gapless "hack" for hardware which lacks support for it.
A $50 JRiver license would be a lot cheaper than replacing $800 hardware and seems like it could bring in new customers.
 
(the current iteration of the Bridge hardware lacks gapless support, and will require you to replace it when they release the next version, which is confirmed to have gapless support)

[olepro]

^

Two things...

1. You can already today do gapless playback with MC UPnP in a perfectly easy and regular manner, if you buy a renderer that properly supports SetNextAvTransportUri. So my recommendation to JRiver is to not waste any efforts in kludging around their own currently very good implementation of UPnP to produce a bad compromise "solution" to problems caused by other parties bad implementations of UPnP. They should rather invest their efforts in lobbying those other parties to do things right in the first place.

2. If I understand you right you are talking about having MC deliver over UPnP a "live" stream comprising several tracks stitched gaplessly together? And you are suggesting that Seeks would cause different portions of those tracks to be stitched into that live stream? Or did I misunderstand you? If this is indeed what you are suggesting, then there are two problems with the suggestion: i) it would only work if MC is the Control Point, any other CP would continue to be sending regular Seek commands to the renderer in the normal way, and the MC server won't see those Seeks and so it could not do this stitching magic in such cases, and ii) more importantly, UPnP streaming is not a synchronous delivery mechanism, and so the renderer may have a local buffer of several tens of seconds (if not minutes) of stream input; this means that even if the server where to do such stitching magic, the renderer would still continue to play through all the buffered music, so your Seeks could take tens of seconds or minutes before taking effect..

Edit: additional to point i) above, since a stitched stream would be of unknown length, the MC server cannot provide a Content-Length value, and therefore the renderer cannot calculate the destination of a Seek command, so any Seek command coming from a third party CP would at least fail, and possibly result in a CP error message...

I was not thinking about JRiver to do any track stitching.

I am talking about allready having the album as one long flac or what ever file.
But instead of using the cue file to switch tracks (because it doesn't work) i was thinking af a kind of JRiver cue file that tell the scrollbar where to go to. Maybe JRiver could steal the track index marks from the cue file and convert it to (scroll bar go-to file) that is saved in the library.

I somehow understand your point about "just" buy hardware that works, but this is yesteryears thinking.
These days many many kinds of hardware is controlled by software, to overcome hardware limitations and perform better.
I cannot see this as a problem other than it only works with JRiver.

why not make JRiver the software that does this as the only dlna client and give even more people another good reason to buy your software ;-)

But any way, i will just go on moving the scrollbar by hand to find my tracks.

Best regards

[Mike48]

I'm another victim of PS Audio's broken network implementation . . . but I don't think that JRiver needs to do anything special. As others have said, it's up to PS Audio to fix their lousy hardware. As far as I can see, they are not allocating resources to do so.

The PS Audio Network Bridge is a great product, unless you want to play music with it. PS Audio is still selling it as "a state-of-the-art network media server." There is so much wrong with that claim that it's hard to know where to begin.

[olepro]

I'm another victim of PS Audio's broken network implementation . . . but I don't think that JRiver needs to do anything special. As others have said, it's up to PS Audio to fix their lousy hardware. As far as I can see, they are not allocating resources to do so.

The PS Audio Network Bridge is a great product, unless you want to play music with it. PS Audio is still selling it as "a state-of-the-art network media server." There is so much wrong with that claim that it's hard to know where to begin.

OK
I'm using JRiver with OPPO BDP-103 as DLNA player, but they are maybe using the same hardware as PS Audio for the streaming part !

I just got this understanding that most of the hardware out there have this problem when you are pushing the stream from the client to the player.

[oldzorki]

OK
I'm using JRiver with OPPO BDP-103 as DLNA player, but they are maybe using the same hardware as PS Audio for the streaming part !

I just got this understanding that most of the hardware out there have this problem when you are pushing the stream from the client to the player.

Yep. Most of it. OPPO BDP-105 as well (I guess software is identical practically).
Too bad, as "pull" interface of Oppo is terrible, when compared to MC or Gizmo.

[AndrewFG]

I'm using JRiver with OPPO BDP-103 as DLNA player, but they are maybe using the same hardware as PS Audio for the streaming part !

I don't know about PS Audio, but I know that Oppo's UPnP implementation is done in a chipset / library supplied by a company called Mediatek.

[oldzorki]

I don't know about PS Audio, but I know that Oppo's UPnP implementation is done in a chipset / library supplied by a company called Mediatek.

Past upgrades in OPPO software included some changed in UPnP, so in theory they can change it. And I think they should, as their own Android app simply does not support DLNA at all, and regular interface is quite poor... Perhaps there was not enough demand, as I personally wrote about it to Oppo (they do read and reply on emails, and generally have good support) -but so far no changes have been made, only that they are "working on it".
I suspect that majority of requests are related to video playback, and audio streaming is important for a smaller percentage of users..

[AndrewFG]

I am talking about allready having the album as one long flac or what ever file. But instead of using the cue file to switch tracks (because it doesn't work) i was thinking af a kind of JRiver cue file that tell the scrollbar where to go to. Maybe JRiver could steal the track index marks from the cue file and convert it to (scroll bar go-to file) that is saved in the library.

Sorry but this idea simply cannot solve your problem..

In UPnP when a Control Point wants to seek to a new location, the CP sends a Seek command to the renderer telling it to restart playing at the new time offset from the beginning of the stream. And then the renderer does a new HTTP GET with a Range-Bytes header to download that new part of the stream. So there is at least one killer reason (there are probably more) why your proposal cannot work (why it is simply impossible to do Seeking on UPnP continuous streams): Since the playlist is a continuous open ended stream, its duration is indeterminate, so the original HTTP GET cannot declare a Content-Length header, and so according to the HTTP specifications it cannot declare an Accept-Range header either. For this reason, the renderer has neither the information (no content length) nor the permission (no accept range header) for it to be able to make the second HTTP GET with a valid Range-Bytes request for the purposes of seeking.

In short, you are not only asking JRiver to attempt an impolite kludge of the UPnP protocol specifications, but you asking them also to attempt an impossible kludge of the HTTP specification..

[georgB]

Sorry Andrew, from my point of view, as a customer of jriver and a normal user i would like to use jriver and my psaudio dac to play gapless. I am not interested in technical problems, i am interested in a customer oriented solution. As i told in an other thread, with foobar i am able to play gapless without any problems. The only thing i have to do is to choose to play all files of an album. But from there i can jump to any track and it plays gapless. So if jriver canīt solve this, no problem, i use foobar. It is much cheaper than replace my excellent sounding dac, worth more than 5.000,00 €.

[JimH]

I removed a foobar post.  Please use their forum for discussion of foobar. 

[AndyU]

Sorry Andrew, from my point of view, as a customer of jriver and a normal user i would like to use jriver and my psaudio dac to play gapless. I am not interested in technical problems, i am interested in a customer oriented solution. As i told in an other thread, with foobar i am able to play gapless without any problems. The only thing i have to do is to choose to play all files of an album. But from there i can jump to any track and it plays gapless. So if jriver canīt solve this, no problem, i use foobar. It is much cheaper than replace my excellent sounding dac, worth more than 5.000,00 €.

Surely it is psaudios lack of competence that is the reason for their DAC being unable to play gapless. Expecting JRiver to spend time and money fixing other folks problems is a bit much. It is psaudio who are not customer oriented. You've got a DAC that doesn't support gapless playback. Either a) the manufacturer should fix it or b) you should rip gapless albums into one rip or c) get a DAC that does what you want. $5k is a lot to pay for one that doesn't!

[oldzorki]

I removed a foobar post.  Please use their forum for discussion of foobar. 

My apologies, I understand your point.
And I've been through many various Media Servers not to realise the tremendous advantages of JRiver MC, as well it is versatily, quality and easy of use. I reccomend it now to everyone I know, have no desire to switch and can easely, when necessary, use "pull" to get gapless playback in albums requiring it.
However if another software can do "gapless" trick with apparently poorly designed hardware - perhaps one day it will be possible and with JRiver, even if solution will constitute some kind of "kludge" to an extent.

[Listener]

Sorry Andrew, from my point of view, as a customer of jriver and a normal user i would like to use jriver and my psaudio dac to play gapless. I am not interested in technical problems, i am interested in a customer oriented solution.

Perhaps you should be talking to PS Audio.

You should have researched the gapless playback issue before you bought the PS Audio DAC.

[oldzorki]

Perhaps you should be talking to PS Audio.

You should have researched the gapless playback issue before you bought the PS Audio DAC.

I do not believe it is fair requiring the customer to research all possible issues with his purchase, especially such as communication with other software.
Especially with such fairly limited quantity specialized product as PS Audio.

[Listener]

I do not believe it is fair requiring the customer to research all possible issues with his purchase, especially such as communication with other software.
Especially with such fairly limited quantity specialized product as PS Audio.

You may not mind wasting $ 5000 to avoid doing your homework.  I'd feel pretty bad after wasting that kind of money.

Issues with DLNA renderers including the gapless problem have been thoroughly discussed on this forum.

You spent ~ $ 50 on JRiver MC and $ 5000 on the PSAudio device.  Why don't you expect PSAudio to fix their problem with a firmware update?

[oldzorki]

You may not mind wasting $ 5000 to avoid doing your homework.  I'd feel pretty bad after wasting that kind of money.

Issues with DLNA renderers including the gapless problem have been thoroughly discussed on this forum.

You spent ~ $ 50 on JRiver MC and $ 5000 on the PSAudio device.  Why don't you expect PSAudio to fix their problem with a firmware update?

I am not disagreement at all with line of thought that PSAudio (or probably provider of their streaming software - I will be shocked if they wrote it themselves) is responsible for solving the problem. But my point was that no matter how much homework you do you still may not cover all the issues, especially with a third party software. People who are chosing such product probably first and foremost looking into performance then features.

[AndrewFG]

You spent ~ $ 50 on JRiver MC and $ 5000 on the PSAudio device.  Why don't you expect PSAudio to fix their problem with a firmware update?

I agree. It is unfair to expect the maker of a $50 product to hack a non standard "solution" to fix a deficiency in a $5000 product.

[Mike48]

I'm using JRiver with OPPO BDP-103 as DLNA player, but they are maybe using the same hardware as PS Audio for the streaming part !

I just got this understanding that most of the hardware out there have this problem when you are pushing the stream from the client to the player.

Some of the US DEVELOPED hardware has this problem. The European, Canadian, and Japanese solved this problem long ago. (I suspect it relates to greater respect for music in those countries.) Not that all other renderers are perfect: but Oppo and PS Audio are pretty much alone these days in the high-end world in offering renderers that are broken in this respect. Still, I would double-check before buying anything. Setting up a DLNA system can still be a bleeding-edge endeavor.

[Mike48]

You spent ~ $ 50 on JRiver MC and $ 5000 on the PSAudio device.  Why don't you expect PSAudio to fix their problem with a firmware update?

I think PS Audio should fix it. It's worth noting, though that Oppo has said explicitly and PS Audio at least implicitly that firmware can't fix this problem . . . it seems to be a hardware shortcoming.  I would also note that trying to fix the problem in software has led PS Audio down at least two difficult paths (eLyric and the not-yet-released Wavestream), not to say dead ends.