Topic: SOLVED: Controlling MC16 client from Gizmo - audio NOT BITPERFECT [Solved] (Read 7413 times)

dmm · « **on:** August 15, 2011, 03:55:38 pm »

I have MC16 clients and a server on a LAN. I can play .dts and .wav files with DTS audio just fine on my clients when I am sitting at the keyboard of my client and controlling the MC16 locally.

However, when I run the GIZMO and use the "what do you want to do?" config screen on my android tablet to select "choose where to play" to direct the sound to that very same client. The audio stream comes out to my receiver as white noise (Not bitperfect anymore).

Why is playback different depending if I control the client locally or via the GIZMO?

UPDATE: This issue has been solved and was caused by end user (me) error/misunderstanding. See the end of this thread for the solution.

JimH · « **Reply #1 on:** August 15, 2011, 05:11:45 pm »

Maybe conversion is on at the server. Make sure you have the latest build. It's currently 16.0.149.

dmm · « **Reply #2 on:** August 15, 2011, 07:00:57 pm »

Quote from: JimH on August 15, 2011, 05:11:45 pm

Maybe conversion is on at the server. Make sure you have the latest build. It's currently 16.0.149.

The conversion issue was what got me originally hung up just getting dts to work at all previously.

see here:
http://yabb.jriver.com/interact/index.php?topic=64707.msg436090#msg436090

However, all of the conversions are turned off now and that is not the particular problem with the gizmo setup. And yes I have the latest .149 build loaded.

Any other ideas? Can you describe the processing and control logic with MC in a client-server vs gizmo-client-server architecture?

Some other interesting info:

attempting to use the gizmo to control a client to playback .dts and .wav files with dts ripped from CD's crashes the client.

attempting to use the gizmo to control a client to playback .dts and .wav files with dts ripped from DVD's causes the following error message on the MC16 library SERVER:
"Playback Problem" "Something went wrong with playback."

Directly using the keyboard on the client to play the same files works fine bitperfect. Only with the gizmo in the controlling path do I have problems.

dmm · « **Reply #3 on:** August 16, 2011, 04:24:38 pm »

One more interesting behavior.

If I am on the client machine I can add a DTS CD ripped file to the "Playing Now: Here" zone and play the file bit perfect no problem.

On the same client machine if I add the same DTS CD ripped file to the "Playing Now: There: Here" zone, the client MC16 hangs.

Both of these experiments are directly on the client without the Gizmo in the puzzle.

What is the difference between Here and There:Here zones?

Ideas?

EDIT: ok after further testing I guess "Playing Now: There: Here" actually plays on the server itself. The server has no sound card so I guess that is what caused the client hang. There: Here is somewhat a confusing name.

dmm · « **Reply #4 on:** August 18, 2011, 05:52:46 am »

Quote from: JimH on August 15, 2011, 05:11:45 pm

Maybe conversion is on at the server. Make sure you have the latest build. It's currently 16.0.149.

Any other help?

dmm · « **Reply #5 on:** August 22, 2011, 04:30:57 pm »

Looks like I am the only one posting to this. Any additional help would be appreciated.

I have updated to version .156. Still no joy.

I have also tried mapping a network drive on the client to match the local drive letter for my music files on the server (M: drive). I then selected on the client the option to "play local file if one that matches the server..." if possible. No joy there either.

Bueller?... Bueller?... Bueller?

dmm · « **Reply #6 on:** August 25, 2011, 11:01:48 am »

Am I posting in the wrong forum for attention to this problem?

JimH · « **Reply #7 on:** August 25, 2011, 11:13:51 am »

If nobody replies, it often means that nobody knows the answer. DTS support is new. It wouldn't be surprising if conversion didn't work.

dmm · « **Reply #8 on:** August 25, 2011, 11:24:50 am »

But I am not looking for conversion, only bitperfect. Also all my files play fine when controlled locally on the client, it is only when one controls the client from the gizmo app that bitperfect breaks.

Also, given that this forum is the only support for paying customers. This is my only option to get help from jriver.

Can you at least describe how playback differs when controlled locally at the client vs controlling the client via the GIZMO app? Something is getting broken with bitperfect playback and it would help me to understand this better so I have a shot at fixing it myself since it appears the issue is not getting much attention here.

Specifically, when using the gizmo app does that mean that the audio is "processed" and possibly bitpefect corrupted on the server and then sent to the client for playback? In my case, the server has no SPDIF or HDMI out so the server is not capable of streaming the DTS, AC3 or digitial stream out. But of course my client does have full sound bitperfect capabilities.

MC16 is great software with many high end audiophile features which attracts high end demanding customers. I get that and stand ready to actively work thru this problem with you.

Matt · « **Reply #9 on:** August 30, 2011, 03:59:42 pm »

Audio-only DTS should be decoded, never bitstreamed, meaning hearing static should not happen.

Make sure you have all playback types set to 'Automatic' in Options > File Types.

Matt · « **Reply #10 on:** August 30, 2011, 04:13:50 pm »

I might add that Gizmo playback should be identical to local playback, because Gizmo basically just says "play this file key".

You might double-check that Gizmo is targeting the same zone you're testing on the client, and that you're definitely playing the same file and not one with the same name that's different. Maybe make a playlist to be sure.

mojave · « **Reply #11 on:** August 30, 2011, 04:17:48 pm »

dmm has mentioned several times that he is using the Gizmo as a remote control for the client. Playing at the client using the client's keyboard works fine. Playing at the client using Gizmo as a remote does not work. I can't see how he has a setup issue wrong on the client.

I'm going to download a dts wav file to test.

mojave · « **Reply #12 on:** August 30, 2011, 04:59:53 pm »

I now have a file, but my coworker with Gizmo on his Android phone just left for the day. I'll try it tomorrow.

dmm · « **Reply #13 on:** August 31, 2011, 02:14:42 pm »

Quote from: mojave on August 30, 2011, 04:17:48 pm

dmm has mentioned several times that he is using the Gizmo as a remote control for the client. Playing at the client using the client's keyboard works fine. Playing at the client using Gizmo as a remote does not work. I can't see how he has a setup issue wrong on the client.

I'm going to download a dts wav file to test.

thank you for jumping in to my rescue. I look forward to the results of your testing and recommendations. I have run out of ideas on my end.

Matt · « **Reply #14 on:** September 01, 2011, 03:59:43 pm »

I can't reproduce this. Both .DTS and .WAV (with DTS inside them) play fine when started locally or with Gizmo.

Could you describe in more detail what you're doing, and the results you are getting?

Thanks.

dmm · « **Reply #15 on:** September 02, 2011, 11:21:06 am »

Thanks all for jumping in on this discussion. Here are some more details about my setup:

Library Server:
Windows 7 64bit
MC16 16.0.168 version running as server with autostart on boot.
initially with no sound card enabled at all. I later enabled the onboard analog out sound just as a test. No digital SPDIF or HDMI output.

MC16 Options -> File Location
Conversion cache all set to "do not create cache".

MC16 Options -> File Types
all file types set to automatic

MC16 Options-> Media Network
Use Media Network to share this library and enable DLNA set to YES
Access key used
Authentication set to YES
-> Add or Configure DLNA Servers.....
Audio Conversion set to NEVER CONVERT

Library Client
Windows 7 32 bit
MC 16.0.168 version
AMD 5450 HDMI video card (HDMI audio drivers loaded, but HDMI not used for music listening)
Firestone Audio Bravo Transport (SPDIF reclocker and/or USB to SPDIF low jitter output). the Bravo is my main audio out. SPDIF feeding my panasonic receiver.

MC16-> Options -> Audio
Output Mode WASAPI Event Style
Output Mode Settings MB Realtek Digital out (which then feeds the Bravo Transport reclocker above)
Output Mode Settings Open Device for Exclusive Access check YES
Settings DSP... all DSP functions OFF
Settings Prebuffer 6 secs
Settings play silence at start 1 sec
Play files from memory YES
Track Change switch tracks .5s gapped, do not play silence unchecked, use gapless unchecked
Stop, Seek, Skip- seek standard, stop immediate

MC16-> Options -> file location
Conversion Cache all set to "do not create cache"

MC16->Options-> File Types
All set to automatic

MC16->Options-> Media Network
Use Media Network to share this library and enable DLNA YES
MC16->Options-> Media Network ->Advanced
DLNA Renderer checked YES
MC16->Options-> Media Network -> Client Options
Audio Conversion "Don't Convert Audio"
Play local file if on that matches...OFF (I have tried turning this on and mapping the network drive to the media library so that the file could be played local. this did not help)

MC16->Options-> Video
Directshow selection method: advanced red oct HQ w additional filters
Bitstreaming YES (SPDIF)

GIZMO: latest version

I have many test files. I usually play Diana Krall Love Scenes CD DTS as a test. I have 44.1khz .wav and .dts versions of these DTS files. I also use Peter Gabriel PLAY which is 24/96 encoded 48khz .dts files. All of these .wav and .dts files play perfect when MC16 is controlled locally on the client with a local keyboard and mouse. However when the same client is controlled with GIZMO. Bitperfect is broken and static is played instead.

dmm · « **Reply #16 on:** September 06, 2011, 01:33:19 pm »

And here is even more info and definitive pointers to where the problem exists. I turned on logging on the client and notice some very significant differences between playback directly on the client and when the client is controlled via the gizmo.

Note the interesting differences highlighted in RED (some of the highlights are not working, but look at how via the gizmo the file is ID'ed as a mp3 file not a DTS file.

LOG file from regular locally controlled client of a .DTS file. This works great:

Media Center; Version: 16.0.168; Types: 96
0019078: 4368: Playback: CPlayerZone::Play: Start
0019078: 4368: Playback: CPlayerZone::Play: Handling exclusive playback zones
0019078: 4368: Playback: CPlayerZone::Play: Getting actual playback track
0019078: 4368: Playback: CPlayerZone::Play: Processing play for 'm01p://192.168.x.x:52199/MCWS/v1/File/GetFile?File=1351503'
0019078: 4368: Playback: CPlayerZone::Play: Updating internal track info
0019078: 4368: Playback: CPlayerZone::Play: Playing: <XMLFN version="1.0"><Item Name="Filename">m01p://192.168.x.x:52199/MCWS/v1/File/GetFile?File=1351503</Item><Item Name="ReplayGainAlbum">-5027</Item><Item Name="SampleRate"></Item><Item Name="ReplayGainTrackAutoPreamp">5027</Item><Item Name="AlbumSequentialWithLastTrack">0</Item><Item Name="PlaylistIndex">13</Item><Item Name="DatabaseKey">1351503</Item><Item Name="BitDepth"></Item><Item Name="ReplayGainTrack">-5027</Item><Item Name="FileType">dts</Item><Item Name="ReplayGainAlbumAutoPreamp">5027</Item><Item Name="Channels"></Item><Item Name="ErrorFreeMode">0</Item><Item Name="MediaType">Audio</Item><Item Name="Bookmark"></Item></XMLFN>
0019078: 4368: Playback: CJRPlaybackEngine::Play: Start
0019078: 4368: Playback: CJRPlaybackEngine::Play: Playing: http://192.168.x.x:52199/MCWS/v1/File/GetFile?File=1351503
0019078: 4368: Playback: CJRPlaybackEngine::Play: Filetype: dts; Type: 2; Can play: 1; Playback object: 0x5f4b858
0019078: 4368: Playback: CJRPlaybackEngine::StartPlayFile: Start
0019078: 4368: Playback: CMJPlaybackType::Play: Start
0019078: 4368: Playback: CMJPlayerCore::Play: Start
0019078: 4368: Playback: CMJPlayerCore::Play: Created feeder helper for type dts (native: 1)
0019078: 4368: Playback: DShowVideoGraph::Render: Start
0019078: 4368: Playback: DShowVideoGraph::ConnectSourceAndSplitter: Start
0019078: 4368: Playback: JRURLStream::Open: Start
0019078: 4368: Playback: BufferedInternetReader::Open: Start

LOG file from GIZMO controlled client of a .DTS file. Bitperfect Playback FAILS:

Media Center; Version: 16.0.168; Types: 96
0039703: 4368: Playback: CPlayerZone::Play: Start
0039703: 4368: Playback: CPlayerZone::Play: Handling exclusive playback zones
0039703: 4368: Playback: CPlayerZone::Play: Getting actual playback track
0039703: 4368: Playback: CPlayerZone::Play: Processing play for 'http://192.168.x.x:52100/Music/F1351503.0.mp3'
0039703: 4368: Playback: CPlayerZone::Play: Updating internal track info
0039703: 4368: Playback: CPlayerZone::Play: Playing: <XMLFN version="1.0"><Item Name="Filename">http://192.168.x.x:52100/Music/F1351503.0.mp3</Item><Item Name="ReplayGainAlbum">0</Item><Item Name="SampleRate"></Item><Item Name="ReplayGainTrackAutoPreamp">0</Item><Item Name="AlbumSequentialWithLastTrack">0</Item><Item Name="PlaylistIndex">0</Item><Item Name="DatabaseKey">1409976</Item><Item Name="BitDepth"></Item><Item Name="ReplayGainTrack">0</Item><Item Name="FileType">mp3</Item><Item Name="ReplayGainAlbumAutoPreamp">0</Item><Item Name="Channels"></Item><Item Name="ErrorFreeMode">0</Item><Item Name="MediaType">Audio</Item><Item Name="Bookmark"></Item></XMLFN>
0039703: 4368: Playback: CJRPlaybackEngine::Play: Start
0039703: 4368: Playback: CJRPlaybackEngine::Play: Playing: http://192.168.x.x:52100/Music/F1351503.0.mp3
0039703: 4368: Playback: CJRPlaybackEngine::Play: Filetype: mp3; Type: 1; Can play: 1; Playback object: 0x5f4b8d0
0039703: 4368: Playback: CJRPlaybackEngine::StartPlayFile: Start
0039703: 4368: Playback: CMJPlaybackType::Play: Start
0039703: 4368: Playback: CMJPlayerCore::Play: Start
0039703: 4368: Playback: CMJPlayerCore::Play: Created feeder helper for type mp3 (native: 1)
0039703: 4368: Playback: CMJWaveFeeder::Play: Start
0039718: 4368: Playback: CMJWaveFeeder::Play: Finish (15 ms)
0039718: 4368: Playback: CMJPlayerCore::Play: Play succeeded
0039718: 4368: Playback: CMJPlayerCore::Play: Result: 1
0039718: 4368: Playback: CMJPlayerCore::Play: Finish (15 ms)
0039718: 4368: Playback: CMJPlaybackType::Play: Play result: 1
0039718: 4368: Playback: CMJPlaybackType::Play: Finish (15 ms)
0039718: 4368: Playback: CJRPlaybackEngine::StartPlayFile: Play returned: 1
0039718: 4368: Playback: CJRPlaybackEngine::StartPlayFile: Finish (15 ms)
0039718: 4368: Playback: CJRPlaybackEngine::Play: StartPlayFile returned 1
0039718: 4368: Playback: CDisplayPlugin::LoadPlugin: Start
0039718: 2064: Playback: CMJWaveFeeder::Thread: Start

dmm · « **Reply #17 on:** September 09, 2011, 04:47:47 pm »

Quote from: Matt on September 01, 2011, 03:59:43 pm

I can't reproduce this. Both .DTS and .WAV (with DTS inside them) play fine when started locally or with Gizmo.

Could you describe in more detail what you're doing, and the results you are getting?

Thanks.

Is there any other info I can provide to help?

mojave · « **Reply #18 on:** September 09, 2011, 05:34:22 pm »

Matt has been on vacation this week.

I thought I posted in this thread earlier in the week, but I don't see it here now. I also tried with Gizmo and had no problems. However, I was only using analog outputs and don't have any digital output method to test.

I wonder if this has anything to do with the Android device's volume control. Could it be that the volume control on the Android device is lowering the volume on the client making it no longer bit perfect?

dmm · « **Reply #19 on:** September 09, 2011, 07:24:26 pm »

I am glad to hear that Matt is getting a well deserved vacation.

I think the key issue is what is highlighted in the log files above. For some reason when the file is queued up from the gizmo, MC treats it as a MP3 file, and thus it gets corrupted. When queued up on the local client it is properly treated as a .dts file and sent bitperfect.

dmm · « **Reply #20 on:** September 15, 2011, 03:14:42 pm »

I realize I may be the only one reading this.....but I continue to try and fix this bug on my own.

For kicks I just tried controlling my client using a web browser and MC Webremote. That works fine, bitperfect in all of it's glory.

So in summary:

Play .dts file off of the server with a client controlled locally: BITPERFECT works
Play .dts file off of the server with a client controlled via webremote: BITPERFECT works
Play .dts file off of the server with a client controlled via the GIZMO: BITPERFECT fails

Hopefully this helps and draws some interest from folks smarter than I.

Matt · « **Reply #21 on:** September 15, 2011, 03:21:30 pm »

The log is certainly a smoking gun. I don't think I had gathered this was a Library Server client issue, so I'll test that specifically tomorrow.

Is it easy to test a local library on your end instead of a Library Server client library to see if it is related to Library Server client?

Thanks for all your detective work.

Matt · « **Reply #22 on:** September 16, 2011, 10:24:04 am »

I still can't reproduce this, even when starting DTS playback on a Library Server client using Gizmo.

Gizmo should cause lines like this in the log:
Playback: CPlayerZone::Play: Processing play for 'm01p://199.242.131.44:52199/MCWS/v1/File/GetFile?File=1'

I can't understand why you see this instead, which is a DLNA filename:
Playback: Processing play for 'http://192.168.x.x:52100/Music/F1351503.0.mp3'

Could you double-check the conversion settings on the client in Options > Media Network > Client Options? Could you uninstall and reinstall the latest Gizmo?

What does the client show in Media Network when Gizmo issues the play command? I'd expect something like:
/MCWS/v1/Browse/Files?ID=1000&ActiveFile=1&Action=Play

Thanks.

dmm · « **Reply #23 on:** September 16, 2011, 10:41:58 am »

Thank you for giving me some things to try and data to collect.

I will do some tests and post my results.

As far as the client options settings. I re verified and it is still set to "Don't convert audio".

dmm · « **Reply #24 on:** September 16, 2011, 11:21:16 am »

One other item of possible interest.

On the client, the .dts file plays bitperfect just fine. However, if I right click on the file name and select LOCATE-> On disk.....I get the following error:

FILE MISSING: The file 'm01p://192.168.x.x:52199/MCWS/v1/File/GetFile?File=1351504' does not exist.

The error message pops up on all files, not just .dts files. Of course all of those same "missing" files play just fine on the client when not controlled from the GIZMO.

dmm · « **Reply #25 on:** September 19, 2011, 08:58:35 am »

Ok I reloaded the gizmo app from the market to get the latest version. (I did have update ok checked previously, so I think I already had the latest version anyway).

How can I send you the log files? They are too large to post here. email me at dumpingground att mailworks dot org with instructions.

Same results. BITPERFECT playback is still corrupted. Here is a portion of the log file:

Media Center; Version: 16.0.176; Types: 224
0012963: 5892: Playback: CPlayerZone::Play: Start
0012963: 5892: Playback: CPlayerZone::Play: Handling exclusive playback zones
0012963: 5892: Playback: CPlayerZone::Play: Getting actual playback track
0012963: 5892: Playback: CPlayerZone::Play: Processing play for 'http://192.168.x.x:52100/Music/F1352994.mp3'
0012963: 5892: Playback: CPlayerZone::Play: Updating internal track info
0012963: 5892: Playback: CPlayerZone::Play: Playing: <XMLFN version="1.0"><Item Name="Filename">http://192.168.x.x:52100/Music/F1352994.mp3</Item><Item Name="ReplayGainAlbum">0</Item><Item Name="SampleRate"></Item><Item Name="ReplayGainTrackAutoPreamp">0</Item><Item Name="AlbumSequentialWithLastTrack">0</Item><Item Name="PlaylistIndex">0</Item><Item Name="DatabaseKey">1409996</Item><Item Name="BitDepth"></Item><Item Name="ReplayGainTrack">0</Item><Item Name="FileType">mp3</Item><Item Name="ReplayGainAlbumAutoPreamp">0</Item><Item Name="Channels"></Item><Item Name="ErrorFreeMode">0</Item><Item Name="MediaType">Audio</Item><Item Name="Bookmark"></Item></XMLFN>
0012963: 5892: Playback: CJRPlaybackEngine::Play: Start
0012963: 5892: Playback: CJRPlaybackEngine::Play: Playing: http://192.168.x.x:52100/Music/F1352994.mp3
0012963: 5892: Playback: CJRPlaybackEngine::Play: Filetype: mp3; Type: 1; Can play: 1; Playback object: 0x673b870
0012963: 5892: Playback: CJRPlaybackEngine::StartPlayFile: Start
0012963: 5892: Playback: CMJPlaybackType::Play: Start
0012963: 5892: Playback: CMJPlayerCore::Play: Start
0012963: 5892: Playback: CMJPlayerCore::Play: Created feeder helper for type mp3 (native: 1)
0012963: 5892: Playback: CMJWaveFeeder::Play: Start
0012963: 5892: Playback: CMJWaveFeeder::Play: Finish (0 ms)

Matt · « **Reply #26 on:** September 19, 2011, 09:07:56 am »

Bump on this (Services & Plug-ins > Media Network):

Quote from: Matt on September 16, 2011, 10:24:04 am

What does the client show in Media Network when Gizmo issues the play command? I'd expect something like:
/MCWS/v1/Browse/Files?ID=1000&ActiveFile=1&Action=Play

Thanks.

dmm · « **Reply #27 on:** September 19, 2011, 09:50:46 am »

Quote from: Matt on September 19, 2011, 09:07:56 am

Bump on this (Services & Plug-ins > Media Network):

I was not aware of this feature of MC to get these status messages. Sorry, I was looking in the log file.

Following your bump directions I went in and tried to find the play command. I do not see it there. I have three servers I can monitor:

Device Discovery Server (SSDP)
DLNA Media Renderer (htpc)
htpc (Library Server)

None of those servers are spitting out a "play" command that I can see in the status window when I launch the .dts file from my gizmo.

The most useful server for status messages is the DLNA Media Renderer which is spitting out messages like this:

POST: http://192.168.x.x:52100/AVTransport/control
POST: http://192.168.x.x:52100/RenderingControl/control
GET: http://192.168.x.x:52100/DeviceDescription.xml
SUBSCRIBE: ......

There are many POST/GET/SUBSCRIBE etc messages....But no play.

Matt · « **Reply #28 on:** September 19, 2011, 10:00:06 am »

Quote from: dmm on September 19, 2011, 09:50:46 am

I was not aware of this feature of MC to get these status messages. Sorry, I was looking in the log file.

Following your bump directions I went in and tried to find the play command. I do not see it there. I have three servers I can monitor:

Device Discovery Server (SSDP)
DLNA Media Renderer (htpc)
htpc (Library Server)

None of those servers are spitting out a "play" command that I can see in the status window when I launch the .dts file from my gizmo.

The most useful server for status messages is the DLNA Media Renderer which is spitting out messages like this:

POST: http://192.168.x.x:52100/AVTransport/control
POST: http://192.168.x.x:52100/RenderingControl/control
GET: http://192.168.x.x:52100/DeviceDescription.xml
SUBSCRIBE: ......

There are many POST/GET/SUBSCRIBE etc messages....But no play.

When Gizmo browses or plays, it will add entries to the Library Server selection (htpc (Library Server) in your case).

If using Gizmo doesn't do this, it means Gizmo is not connected to that machine. Is it possible you're connecting to a different machine on the network? This could explain the issue.

dmm · « **Reply #29 on:** September 19, 2011, 10:05:16 am »

Well now this is getting interesting...

When I bring up the gizmo, I have made the following choices:

Choose Where to Play:

selected HTPC <----- this is the machine connected to my home LAN and hometheater stereo equipment

Choose A server to Play From:
Fileserver (access key xcxxxxx) <------ this is the media server on my home LAN that is running MC16 and has all of the music files.

Then on the gizmo I get the Home Playing to htpc (tap to change) screen. From there on the gizmo I can search for songs and play from play lists.

Matt · « **Reply #30 on:** September 19, 2011, 10:43:10 am »

Quote from: dmm on September 19, 2011, 10:05:16 am

Well now this is getting interesting...

When I bring up the gizmo, I have made the following choices:

Choose Where to Play:

selected HTPC <----- this is the machine connected to my home LAN and hometheater stereo equipment

Choose A server to Play From:
Fileserver (access key xcxxxxx) <------ this is the media server on my home LAN that is running MC16 and has all of the music files.

Then on the gizmo I get the Home Playing to htpc (tap to change) screen. From there on the gizmo I can search for songs and play from play lists.

It all makes sense now.

You're pushing content from the server to the HTPC using DLNA. DLNA will convert to MP3.

Instead, connect directly to the HTPC using Gizmo.

dmm · « **Reply #31 on:** September 19, 2011, 11:01:47 am »

Quote from: Matt on September 19, 2011, 10:43:10 am

It all makes sense now.

You're pushing content from the server to the HTPC using DLNA. DLNA will convert to MP3.

Instead, connect directly to the HTPC using Gizmo.

Well eureka! I am now working.....BITPERFECT!

It was very confusing to select the client machine as the "server" to play from.

But I wish to thank the jriver staff for staying with me throughout this troubleshooting or better described as end user training thread.

thank you all

JimH · « **Reply #32 on:** September 19, 2011, 11:05:56 am »

You're welcome. Good news.

csimon · « **Reply #33 on:** September 22, 2011, 07:40:50 am »

Sorry to bring this up, but I don't understand the solution!

What configuration have you changed in Gizmo to make it work? Originally, you had Play To = HTPC and Play From = MC16 Server. I would have thought this was correct.

Also, it was mentioned above that DLNA will convert to MP3. This implies that streaming via DLNA is always compressed and not bit-perfect. But surely if you choose Never Convert in tthe DLNA options then it wouldn't conbvert to MP3?

dmm · « **Reply #34 on:** September 22, 2011, 10:55:54 am »

The key change was to from the GIZMO to select the client (HTPC in my case) as the server to play from. This does seem counter intuitive since in my case the HTPC has NO MUSIC files locally.

So the logical relationship looks like this:

The GIZMO is the client to the HTPC server which is the client to fileserver server.

or

GIZMO -> HTPC (MC16 client on my LAN) -> fileserver (MC16 server on my LAN)

As far as you comment about DLNA MP3 and bit perfect, I agree it is concerning. However using the above connecting stream results in GIZMO CONTROL of the HTPC client MC16 and BITPERFECT playback path from the fileserver to the HTPC audio renderer.

csimon · « **Reply #35 on:** September 22, 2011, 11:34:04 am »

Does your HTPC client have a library that points to the MC16 server, so you can in fact go onto the client and browse the libary as though it was local? If so, then I guess that explains why Gizmo can see the HTPC client ALSO as a server! You are playing both from and to the same machine, and under those circumstances I guess MC is intelligent enough not to go through the network to pass media files to itself.

But that still doesn't explain why bitperfect was not working in the first place under DLNA. Are you sure you had conversion turned off in the MC16 server DLNA options specifically, as opposed to its own playback options?

dmm · « **Reply #36 on:** September 22, 2011, 12:08:31 pm »

Yes, my HTPC has a library that points to the fileserver (MC16 server) on my local LAN.

Yes, over the 5 weeks of troubleshooting I checked many times all of the various places where conversion might occur and verified my settings. Some of the settings are unfortunately well hidden the vary capable but also complex MC16 menu and options structure. See reply#15 of this thread for a summary.

See my feature request here asking for a way to simplify BITPERFECT settings:

http://yabb.jriver.com/interact/index.php?topic=66224.msg444375#msg444375

INTERACT FORUM

Author Topic: SOLVED: Controlling MC16 client from Gizmo - audio NOT BITPERFECT [Solved] (Read 7413 times)