Print

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

[RayDiant]

There have been similar threads on this topic but I believe mine is unique enough to create a new one.

I have a Marantz NA7004 media player. Great unit, integrates well with MC 18, through my home LAN. Plays hi def FLACs flawlessly. Except gapless is an issue.

If I use the 7004's remote and select Mark W PC (JRiver DLNA) as the Media Server, scroll to Jethro Tull's Passion Play (sorry I am a prog rocker from way back), select Lifebeats then hit play, it works gapless through the whole thing. The original vinyl had 4 songs. The version I have has it broken into 16 songs so it sounds silly if it isn't gapless. The files are flac 24/96. I believe this is referred to as pulling from the 7004. When I look at MC 18 to see what is playing on the 7004 only one song appears and it has a strange name like FP10015 that changes as it plays through the 16 songs.

If I get onto MC 18 pick the 7004 as the player, tell it to play A Passion Play, it doesn't play gapless. The 7004 is associated with the JRiver DLNA, Mark W PC is the Windows name of my computer so it appears to be using the same DLNA server in both cases. This is the push option.

What is the difference between the push and the pull? I keep hearing that MC is fully capable of gapless playback over DLNA. My device can play gaplessly over DLNA. So why won't the push option work? Is there an issue with server, player, renderer? I am not a DLNA expert but I am pretty sure that in the pull option the 7004 is the player and in the push option MC 18 is the player. In both options the 7004 is the renderer and MC 18 is the server.

If I can get my 7004 to work gaplessly direct from MC 18 I will chuffed.

[pcstockton]

Ray,

When you push from the server, only the current track is loaded.  The Marantz doesn't know what is coming next and cannot then play gaplessly.  However if you pull from the server, it will pull the whole playlist and play gaplessly.

-patrick

[RayDiant]

Patrick

So if the Marantz can pull the whole playlist, why can't I push the whole playlist to the Marantz?

Mark

[pcstockton]

it's not how one of them works.

[doulos]

I'll chime in here, since this is one of my favorite subjects..

It is unfortunatly quite common for manufacturers to (initially) implement gapless for pull mode only. The reason is that implementing the UPnP/DLNA protocol for gapless playback incurs a little extra efffort on top of the effort spent for the gapless pull infrastructure, and if your software department isn't capable, the effort may even rise. Hifi manufacturers are hardware-oriented, and the shift towards software is sometimes difficult, it seems..

Of course, gapless pull is rather useless, because who wants to browse a 500-item list with a remote and a 3-line LCD display? In my view, selling a "high-end" network streamer that doesnt do gapless via UPnP and/or Airplay is a plain ripoff.

Regarding the requirements for gapless over UPnP: what is required is that the firmware implement not only the SetAVTransportURI action, but also SetNextAVTransportURI. With that, the control point can send the currrent track and the next one, and the player can perform the appropriate internal setup (buffering) to avoid the gap when changing tracks.

regards,
chris
====
Author, MediaSteersman UPnP for Android

[RayDiant]

The whole thing is interesting and frustrating. When I asked Marantz (about 6 months ago) their response was that the NA 7004 wasn't designed to do gapless. Now I have found conditions under which it will play gapless with DLNA but only when the NA7004 is acting as the player. This does imply that the unit can play gapless. So, why not under the most used condition?

Is the gapless playback happening because when the NA7004 is the DLNA player, it isn't really the DLNA renderer, rather renderering is taking place without the use of DLNA messages (like SetNextAVTransportURI). Why would it when it is all internal?

And does that mean there is nothing MC can do - like tell the NA7004 it is the player and play these songs?

[doulos]

if SetNextAVTransportURI is not implemented, there is nothing MC (or anybody else) can do. You can check whether its implemented by using the free UPnP tools.

[AndrewFG]

if SetNextAVTransportURI is not implemented, there is nothing MC (or anybody else) can do.

Well, actually you could lobby the manufacturer to add support for SetNextAVTransportURI in their next firmware release

[RayDiant]

I checked with Device Spy. There is no SetNextAVTransportURI.  There is a NextAVTransportURI variable which means little to me. I was a bit too optimistic about the latest firmware upgrade. I am not certain if the gapless pull worked before this. Before all this testing I would have said no but now I am not 100% sure.

[pcstockton]

Why does my laptop not know the entire playlist when using it to control another instance of MC.  Does MC not use the nexttransponrturl thing?

[AndrewFG]

Does MC not use the nexttransponrturl thing?

MC is actually one of the very few good guys who does support gapless push. i.e. they do support SetNextAVTransportURI

[nhegde]

I have been researching NA-7004 product and considering purchasing it. Do you guys think it is likely they will support gapless for pull in the near-medium term? A second question I have for those who own this player, will it play 88.1, 176.2Mhz flacs in the DLNA mode. Would appreciate any feedback. Thank You

[pcstockton]

MC is actually one of the very few good guys who does support gapless push. i.e. they do support SetNextAVTransportURI

I see.  What about simple control?  Why do I only see the current track in Playing Now when I "look" at MC from another MC?

[AndrewFG]

Why do I only see the current track in Playing Now when I "look" at MC from another MC?

An interesting question. I did not check it myself but I would have assumed that the playlist of the MC renderer should contain two tracks. Namely the currently playing track, and the next one. (The latter having been pushed to the playlist by SetNextAVTransportURI).

{
For info, the actual process is as follows:

1) the server pushes the first track to the renderer's playlist using SetAVTransportURI
2) the server pushes the second track to the renderer's playlist using SetNextAVTransportURI
3) once the first track has finished playing, the renderer deletes it from its playlist, and the second track moves up to become the now playing one
4) if the server is not finished then jump to 2) and repeat
}

[AndrewFG]

Do you guys think it is likely they will support gapless for pull in the near-medium term?

Unlikely. Most hardware vendors build their products around a media chip-set that they purchase from one the Chinese or Taiwanese chip foundries. And usually such chip-set comes with a standard application software library that includes (among other things) the UPnP code. I would not expect a box manufacturer to be messing with it's third party suppliers chip-set library because it opens up a can of worms in terms of quality control.

So most likely, new features only get added to boxes, when a wholly new generation is released, that uses a wholly new chip-set, which can then have new functions in its application software library.

PS I think one of the more responsive box manufacturers is Sony. This is probably because they are big enough to be making their own chip-sets, and writing their own application software library.

[doulos]

An interesting question. I did not check it myself but I would have assumed that the playlist of the MC renderer should contain two tracks. Namely the currently playing track, and the next one. (The latter having been pushed to the playlist by SetNextAVTransportURI).

well, as the OP said earlier, there is no  SetNextAVTransportURI for the Marantz NA7004. Which causes MC to operate in one-song-at-a-time mode.

[doulos]

PS I think one of the more responsive box manufacturers is Sony. This is probably because they are big enough to be making their own chip-sets, and writing their own application software library.

my impression is that Denon has a software department of its own (or some closely linked supplier), because they have been cranking out firmware updates for some of their products (e.g. DNP-F109, Piccolo) pretty regularily, with one recent update also bringing in full gapless  playback. Interestingly, gapless via DLNA was not delivered for the the more "high-end" DNP-720AE (as I said earlier - I consider a streamer that doesn't do gapless via DLNA and claims to be high-end a ripoff). One other interesting piece of information is the fact that Denon is owned by "D&M Holdings, Inc.", where the M stands for Marantz...

Real high-end manufacturers often get their comonents from dedicated suppliers that provide complete solutions. For example, the austrian StreamUnlimited sells the Stream700 board complete with UPnP client firmware and control point apps for IPhone and Android. The same goes for the german AUDIVO. Both do gapless with no questions asked.

regards,
Christian

[AndrewFG]

well, as the OP said earlier, there is no  SetNextAVTransportURI for the Marantz NA7004. Which causes MC to operate in one-song-at-a-time mode.

Well, actually, I was not answering the OP !! 

I was answering a question by pcstockton "Why do I only see the current track in Playing Now when I look at MC from another MC?". And since MC does support SetNextAVTransportURI on both its server side, and on its renderer side, then (to repeat my answer again) I would still expect in this case to see two tracks in the playlist of the MC instance on the renderer end.

(Of course, the proviso is that you would only expect to see two tracks in the renderer playlist if the playlist on the MC server instance also has at least two tracks in it)..

[AndrewFG]

Real high-end manufacturers often get their comonents from dedicated suppliers that provide complete solutions. For example, the austrian StreamUnlimited sells the Stream700 board complete with UPnP client firmware and control point apps for IPhone and Android. The same goes for the german AUDIVO. Both do gapless with no questions asked.

I am sure that is all true. For example MediaTek is such a dedicated supplier who supplies "chip sets with complete solutions".

Only problem is that MediaTek's "complete solution" does not include SetNextAVTransportURI support. And if a box manufacturer had chosen MediaTek, then frankly I don't see such manufacturer trying to self engineer a bolt on implementation of SetNext on top of the already existing "complete solution". Would you?

[doulos]

Would you?

surely not. I was just trying to point out that Denon, who are a sister company of Marantz, do seem to have a development of their own, or a supplier that is quite responsive. However, I certainly wouldn't bet on the NA7004 benefitting from this, since the older denon models aren't either

[nhegde]

Don't necessarily disagree with what you guys are saying on the updates from Denon and Marantz on Firmware but NA 7004 seems to have seen several firmwire updates since it came out in 2009-2010. the recent one seem to be in May of 2013. It got push gapless, 192/24 bit playback from network no? It also seems several Denon, Marantz players got similar looking upgrades. Interestingly Denon f109 is the only one who recently got the pull gapless update. May be they have discontinued support for NA 7004 starting this year.

Also besides getting similar updates, it also seems there is more collaboration behind the scenes between Denon and Marantz. Look at the manual on line for Denon F109 and Marantz NA-7004.
Check out page 40 of http://assets.denoneu.com/DocumentMaster/UK/DNP-F109E2_ENG_CD-ROM_v00.pdf
 and page 32 of http://m.marantz.asia/DocumentMaster/sg/dfu_NA7004N.pdf
written basically in the same format

[AndrewFG]

... but NA 7004 seems to have seen several firmwire updates since it came out in 2009-2010. the recent one seem to be in May of 2013. It got push gapless, 192/24 bit playback from network no?

Hmm. The OP was complaining that it got pull gapless but did not get push gapless.

Interestingly Denon f109 is the only one who recently got the pull gapless update.

Now I am confused...

[nhegde]

Sorry Andrew, I got the push and pull mixed up. I meant push where I wrote pull and vice-versa. Thanks for pointing it out

[pcstockton]

Well, actually, I was not answering the OP !! 

I was answering a question by pcstockton "Why do I only see the current track in Playing Now when I look at MC from another MC?". And since MC does support SetNextAVTransportURI on both its server side, and on its renderer side, then (to repeat my answer again) I would still expect in this case to see two tracks in the playlist of the MC instance on the renderer end.

(Of course, the proviso is that you would only expect to see two tracks in the renderer playlist if the playlist on the MC server instance also has at least two tracks in it)..

Thanks for chiming in Andrew.

Any thoughts on why I only see one track?

[AndrewFG]

Any thoughts on why I only see one track?

Try this...

In the Server instance of MC, you should be able to see the Renderer instance of MC under Players. If you right click on that player, there is a menu something like Upnp / DLNA settings (I don't have MC open just now, so I am saying this is from memory), and under that is a check box "Use SetNextAVTransportURI" -- which should indeed be checked.

[bob]

The option is as Andrew says, in the zone for the remote renderer. You right click on it and there are DLNA controller options for the zone. The option is
Disable SetNext support which should be unchecked.

[gypsykirk]

Hi there guys,

I've been trying to work out where to post this and i think this post is probably as close to what I'm experiencing, or rather is most related to what is happening to me playing music files via JRiver with J.Remote to my M1 CLiC. I currently have my working library ripped with dbpoweramp and stored on a readynas duo in WAV format.

I've upgraded to a trial version of JRiver 19 (from 16) and purchased J. Remote (after trying out plugplayer, kinsky etc using j.river 16 as well as twonky and other servers running on the NAS and deciding that performance is poor this way and want to use J.river as my server with an iphone/android/ipad app as my control point). I love the app! It's great and exactly what I'm looking for, however, upon further inspection, or rather hours of tinkering and playing music, I've discovered that things aren't quite working exactly as I'd first thought.

Let me give you an example..... (I'm sorry, I embedded the photos but the file size was too large so I apologise for the links)

Let's say I add Pink Floyd Dark side of the moon using "play all now" with J.Remote,
http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6129_zps3ad7075c.png

The track begins and all i see for the duration of the first track on the clic is this buffering screen...
http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6131_zps9704d0e4.jpg


 The first track plays and continues gaplessly (something i couldn't get to work with j.river 16) onto track two, when i can now see the artwork and track info for the second track on the clic
http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6134_zpse2f16a5b.jpg


however j.remote and j.river still show track one as being played (albeit with the correct time bar for the second track 3:32).
http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6135_zps5a7ce836.jpg


Then,.. when it's time to move onto track 3, track 2 goes back to the start on the clic and repeats, with all artwork and track details updating on j.remote and j.river to track two, the clic goes back to a buffer screen and the process continues like this throughout the entire album.
http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6137_zps53ebda3a.jpg

http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6138_zps0b1b08c0.jpg

If I check "disable setnext support (for broken renders)" everything once again appears great at first glance, everything updates at the same time, ie, j.remote, j.river and the clic all display relevant track info and album art together, however I experience a loss of about 5 seconds at the end of each track and gapless playback doesn't work. (like plugplayer).

With J.river 19 the Musical Fidelity (stream700) app is slightly faster than it was with JRiver 16 (albeit still pants) but it still plays gapless and both the app and j river update artwork and track details at the same time.

It also doesn't matter how I add tracks to the J.remote playlist, (play now, play next, play all next etc) the behaviour is always the same.

I realise J.remote and J.river are basically one and the same and that whilst I'm using J.remote as a control point, it isn't really controlling J.river as such, more mirroring it, I just can't understand why the mf app works with both JRiver 16 + 19 and plays gapless, yet I can't get any other app to do the same as it, no matter what I do with the settings in J.river.


One other thing... When I start dark side of the moon with the mf app, only the track that's playing is shown in j.river, even though it plays gapless throughout the remaining album updating the track being played on j.river each time it changes, but still only showing one track, the track currently being played.
http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6142_zpsbe544cca.jpg

http://i877.photobucket.com/albums/ab332/gypsykirk/Albums/J%20River%20problems/IMG_6144_zpsf285094f.jpg

Also, the mf app is the only app that pauses the track properly and resumes playback from where it was paused. Even if I pause a track on J.river on the PC, it will re start the track from the beginning on the clic. (which can be frustrating!).

You may be thinking, the simple solution is just to use the mf app? I've an iphone 5 and i conducted an experiment the other day, admittedly with j.river 16, and it was to open each app and select the first track on dark side of the moon and to time how long it would take from a standing start to playing the track...the results?

MF app 87 seconds!!! (iphone5)
plugplayer 35 seconds, (iphone5)
Gizmo (from very basic low memory tablet) 20 seconds!!!!
BubbleUPNP (same tablet) 33 seconds.

Things aren't much better on J.river 19 although admittedly the mf app is slightly faster. The problem is the MF app is rubbish and I'm looking for a better interface for my control point. The idea of getting a streamer/renderer initially was for me to stream directly from a NAS, however, after my experiences with that since purchasing the clic and after reading the complete guide to DNLA playback on computer audiophile, I'm convinced that having JRiver running as a my music server is the best all round long term solution.

Incidentally Gizmo displays all the same characteristics as that of J.remote regarding buffering screens, gapless playback and tracks playing twice etc.

I'm bamboozled!!

Has anyone shared any similar experiences or understand what may be happening here? My renderer supports gapless playback, so Is it all to do with the push pull theories discussed above? Is the problem likely to be resolved through j.river or j.remote updates? Do you guys think I'm stuck with the MF app? I can't understand why if the MF app can control J.river in such a fashion that music plays gapless and all artwork and track data update at the same time and during each change of track, why J.Remote can't do the same.

My apologies if I'm off track and anyone feels this should be a new thread in itself or posted elsewhere. I'm happy to start a new thread if this is the case.

If you've read this far (and understood me), then hats off to you!!! and many thanks for reading.

Cheers.

[bob]

Ok gypsykirk, based on your description, here is what I think is going on.
Let's ignore the remotes for now and concentrate on what's going on in MC with your renderer.
First I assume just using MC gives the same behavior as with the remotes.
When setnext is supported, we get the metadata via the GetMediaInfo function (IIRC), since yours isn't changing when going to track 2 I'm thinking that function is broken on your renderer.
The zone display in MC has different behavior based on whether or not it's the controller. If you are just viewing what's going on with the renderer and didn't hit an action button (stop, play seek, etc) then MC is only viewing what the renderer tells it. It cannot show more than one song since the renderer doesn't store a playlist.
Disabling setnext works because MC's no longer calling the broken function. You lose gapless of course.

You can verify this by using device spy from the uPnP tools for developer package.
Just invoke the GetMediaInfo function for the renderer when it's playing each track and inspect the metadata.

[AndrewFG]

... we get the metadata via the GetMediaInfo function (IIRC), since yours isn't changing when going to track 2 I'm thinking that function is broken on your renderer.

Hi bob, I suppose that in a future version, you could program it more defensively, and addition to checking the actual CurrentUriMetaData argument, you could also check the CurrentUri argument too, and if CurrentUri turns out to be an Uri on MC's own server you could substitute MC's own metadata.

Of course this would not solve the problem in the case that MC were snooping passively on the renderer whilst it was playing something from another server.

EDIT: Indeed I think you could potentially program it even more defensively, since you are also calling GetPositionInfo; this means that you potentially have four argument values GetPositionInfo.TrackMetadata, GetPositionInfo.TrackUri, GetMediaInfo.CurrentUriMetaData, GetMediaInfo.CurrentUri that could all give clues to the metadata on the now playing track. I suppose you could devise a scheme to gently fallback from one to the other in order to improve MC's chances of displaying something useful...

[bob]

Hi bob, I suppose that in a future version, you could program it more defensively, and addition to checking the actual CurrentUriMetaData argument, you could also check the CurrentUri argument too, and if CurrentUri turns out to be an Uri on MC's own server you could substitute MC's own metadata.

Of course this would not solve the problem in the case that MC were snooping passively on the renderer whilst it was playing something from another server.

EDIT: Indeed I think you could potentially program it even more defensively, since you are also calling GetPositionInfo; this means that you potentially have four argument values GetPositionInfo.TrackMetadata, GetPositionInfo.TrackUri, GetMediaInfo.CurrentUriMetaData, GetMediaInfo.CurrentUri that could all give clues to the metadata on the now playing track. I suppose you could devise a scheme to gently fallback from one to the other in order to improve MC's chances of displaying something useful...

Thanks Andrew, those are excellent suggestions.

[AndrewFG]

Thanks Andrew, those are excellent suggestions.

Pleased to be of help.

[gypsykirk]

Hi Bob,

First I assume just using MC gives the same behavior as with the remotes.

Yes it does.

I think what you're saying, sounds to me like it makes sense Bob. I guess I'm out of luck for the time being then at least, which is a shame really.

You can verify this by using device spy from the uPnP tools for developer package.
Just invoke the GetMediaInfo function for the renderer when it's playing each track and inspect the metadata.

I'm not sure I'm able to do this with my version and I think it would confirm your hypothesis anyhow.

AndrewFG...... I'll take your word for it haha

Thanks guys. It would be great to be able to utilise JRiver some day...maybe by then I'll have a DAC again haha.

Cheers.