Print

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

[slessard]

Dear All,
I just found JRiver MC software and I am wondering if I could use it for my application. I read many threads on this forum and I can't find the answer to my questions!
I want to play music all over my house, in every room. I have en central media server in the basement and I want to put an Android tablet in some room with in wall amplifier.
I would like to be able to control music distribution from these tablets : choosing file/playlist to play in the current room and/or other rooms. For example, I would like to stop music from playing on the second floor with the Android device on the 1st floor, while the media center in running on the computer in the basement.
I installed Gizmo on my phone and ran some tests. I can play locally, on my phone, files on the server. I can also play on the server the same file. This part is OK.
But I also installed a second Gizmo app on another Android device. I cannot play music from the first Android device to the second Android device running Gizmo. Is that normal? Should I be able to do it? Also, I can't play music from the media cerver to any Android device! I thought that the zones in MC could be hardware devices (such as sound card's output channels) as well as DLNA renderers. Is the Gizmo apps make an Android device a DLNA renderer?

Thanks for your help!

[JimH]

Welcome to the forum.  You're close, but Gizmo isn't a DLNA Renderer.  Take a look at our Third Party board here for ideas.  BubbleUPnP, for example.

If you have a newer TV or Blu-ray player, they may also support UPnP or DLNA.

[slessard]

Thanks for your help!
I just tried BubbleUPnP, it is a great app! Now I understand the concept of renderers.
Now, how can I play to multiple renderers simultaneously? If I want to broadcast audio to the whole house (3-4 Android devices running BubbueUPnP)?
I heard that sync is often problematic with DLNA renderers (or UPnP, obviously...). Is there any way to do it?

[JimH]

Each DLNA Renderer is a zone.  Our wiki has a topic on "Zone Sync".

[csimon]

I heard that sync is often problematic with DLNA renderers (or UPnP, obviously...). Is there any way to do it?

Yes, and no. It's problematic!

DLNA doesn't support synchronised playing. So the answer is No.

However, you can send the same music to different DLNA devices at the same time.  But this doesn't equate to "synchronising" - there is no guarantee that the renderers will be in sync.

MC can link zones so that the same music is sent to different zones at the same time, and it has a "time adjust" feature where you can adjust the time delay.  So if you are willing to put a bit of effort into manually adjusting the timing so that the players are in sync then Yes, there is a way to do it.

[<°)))))><]

MC can link zones so that the same music is sent to different zones at the same time, and it has a "time adjust" feature where you can adjust the time delay.  So if you are willing to put a bit of effort into manually adjusting the timing so that the players are in sync then Yes, there is a way to do it.

If you're lucky, this will work for some time (maybe hours) - until you hit STOP... When starting playback again, you will also have to resync again. I would say it's not only problematic, it's unusable for most tasks. Unfortunately DLNA was not made for this purpose.

[bubbleguuum]

MC can link zones so that the same music is sent to different zones at the same time, and it has a "time adjust" feature where you can adjust the time delay.  So if you are willing to put a bit of effort into manually adjusting the timing so that the players are in sync then Yes, there is a way to do it.

That's not even worth it to setup a delay, because it is not a constant that never change once set, since buffering on renderers is unpredictable and variable.
UPnP just cannot be used for synchronized playback on many devices.  I guess it could with some non-trivial extension to the spec.

[AndrewFG]

UPnP just cannot be used for synchronized playback on many devices. I guess it could with some non-trivial extension to the spec.

Apropos extensions to the spec, did you look at the UPnP AV MediaServer specifications versions 2,3,4 and MediaRenderer specifications versions 2 & 3? See http://upnp.org/sdcps-and-certification/standards/sdcps/ (in particular AVTransport:3). These certainly are "non-trivial extensions", and many relate to synced playback functions. To me some of the sync actions seem to be so software heavy that one could not imagine an average consumer device being capable of handling it (e.g. syncing by connecting all devices to a remote master clock server). However the specs are written by people from companies like HP, Intel, LG, Microsoft, Toshiba, Sony, Panasonic, Samsung, Pioneer, Philips and Nokia, so presumably these guys know a thing or two about what future devices will be capable of doing.

Note that although the spec writers are already working on the next UPnP AV specifications above version 3/4, most actual devices are still only on version 1. But don't worry, as anyone can see, the technology of consumer devices is transforming amazingly fast, and I have no doubt that we will see UPnP AV version 3/4/5 devices rather soon...

[bubbleguuum]

Apropos extensions to the spec, did you look at the UPnP AV MediaServer specifications versions 2,3,4 and MediaRenderer specifications versions 2 & 3? See http://upnp.org/sdcps-and-certification/standards/sdcps/ (in particular AVTransport:3). These certainly are "non-trivial extensions", and many relate to synced playback functions. To me some of the sync actions seem to be so software heavy that one could not imagine an average consumer device being capable of handling it (e.g. syncing by connecting all devices to a remote master clock server).

Thanks for pointing that out. From a brief look, it seems complicated but synced playback protocol is not a simple thing to implement, whatever the protocol is.
Paragraphs starting with "This CONDITIONALLY REQUIRED action..." is a recipe for these actions to never be implemented, as we all know with the SetNextAVTransportURI example...

As an alternative spec for synced playback, there's Linn Songcast for which support can be added to any existing renderer. Not a piece of cake either .

However the specs are written by people from companies like HP, Intel, LG, Microsoft, Toshiba, Sony, Panasonic, Samsung, Pioneer, Philips and Nokia, so presumably these guys know a thing or two about what future devices will be capable of doing.

You mean the same people who gave us the awful LastChange eventing, and the overcomplicated DLNA protocol on top of an already complicated protocol (UPnP) ?
When reading those specs, it look like these people only ever wrote specs and never implemented software...

Note that although the spec writers are already working on the next UPnP AV specifications above version 3/4, most actual devices are still only on version 1. But don't worry, as anyone can see, the technology of consumer devices is transforming amazingly fast, and I have no doubt that we will see UPnP AV version 3/4/5 devices rather soon...

I'm not sure about that. Manufacturers most of the time go for the lowest common denominator and will take every shortcut possible to lower costs.

[AndrewFG]

I'm not sure about that. Manufacturers most of the time go for the lowest common denominator and will take every shortcut possible to lower costs.

In the interests of the consumer, it is probably a reasonable thing too. But in that case, I do wonder why they would bother to spend good money on sending people to work in the standardisation body and writing extended versions of the UPnP specifications. Life is a mystery sometimes...

PS I love the LastChange eventing too ;-)