INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Playback on the Id has slow track transitions  (Read 12899 times)

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Playback on the Id has slow track transitions
« on: September 06, 2016, 01:21:48 pm »

Some users are having problems with the track changing slowly on the Id.
This appears to be an issue with the spectrum analyzer that shows during playback.
If you have this issue, disabling the spectrum analyzer but right-clicking on the Media Center 20 title near the top of Media Center and unchecking Spectrum Analyzer has been reported by several people to fix the issue.

Since we haven't been able to reproduce this in house it would be useful for anyone having this issue to let us know what type of material you are playing when you see this.
Format, sample rate, bit depth, cover art size, etc.

Thanks.
Logged

imtrying2

  • Recent member
  • *
  • Posts: 26
Re: Playback on the Id has slow track transitions
« Reply #1 on: September 08, 2016, 04:37:42 pm »

Thanks for the info, it seems to have worked.
My Id is used mainly for music storage and playback, I rarely have an HDMI cable, mouse and keyboard hooked up to it but I wanted to organize some files. I use JRemote on my IPad to run it.
I was having no trouble at all with mine until I updated my Id to the latest version, option 12. After that I began having issues, it really didn't matter what format I was using. Some songs took two minutes to play.
Thanks for the fix, Steve
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #2 on: September 08, 2016, 05:36:11 pm »

Thanks for the info, it seems to have worked.
My Id is used mainly for music storage and playback, I rarely have an HDMI cable, mouse and keyboard hooked up to it but I wanted to organize some files. I use JRemote on my IPad to run it.
I was having no trouble at all with mine until I updated my Id to the latest version, option 12. After that I began having issues, it really didn't matter what format I was using. Some songs took two minutes to play.
Thanks for the fix, Steve
Thanks for letting us know it occurred with the update.
Do you know about when you previously updated it?
What's the format, sample rate, etc of the files you are playing?
I'd really like to be able to duplicate this...
Logged

imtrying2

  • Recent member
  • *
  • Posts: 26
Re: Playback on the Id has slow track transitions
« Reply #3 on: September 09, 2016, 12:08:01 pm »

 I think I updated it the weekend of August 27, that is the 1st and only time I did the update. Most all of my music is ripped from CD in either Apple lossless or Flac and up sampled at 96.
 
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #4 on: September 09, 2016, 05:56:06 pm »

I think I updated it the weekend of August 27, that is the 1st and only time I did the update. Most all of my music is ripped from CD in either Apple lossless or Flac and up sampled at 96.
That helps a lot, thanks!
When did you receive your Id?
Logged

imtrying2

  • Recent member
  • *
  • Posts: 26
Re: Playback on the Id has slow track transitions
« Reply #5 on: September 10, 2016, 05:19:59 pm »

I'm not 100% sure, it's been roughly 18 months.
When I disabled the spectrum analyzer, I noticed it changed my settings in DSP studio, that seemed odd to me. Why would that happen?
Logged

TrevorW

  • Junior Woodchuck
  • **
  • Posts: 54
Re: Playback on the Id has slow track transitions
« Reply #6 on: September 11, 2016, 02:17:37 pm »

Hi Bob and ImTrying,

I have an Id and running JRiver MC 20 (latest revision) as a renderer with Synology DS411 and DSM6 as my DLNA server. I too use both my iPhone 6S and Ipad (both iOS 9.3.5 recent updated)

I had the problem of track switching taking forever. If I started from a freshly booted Id (would normally keep on but wanted reference for testing) it would start the first track within 1 or 2 seconds (OK) but if I switched to another track even on the same album it would take increasingly longer to move tracks. What I did observe was that this only seemed to occur if I was playing music on the 'Player' (My hifi system) rather than either 'this device' respectively my iPad or iPhone depending which I was using at the time. I also noticed that I could switch tracks OK using interactive mode on the Id itself.

Simply disabling the 'Spectrum Analyser' display as you described solved the problem straight away. Can I be of any assistance in helping you replicate this?  I'm sure the problem started after I upgraded to the latest MC software just over a month ago.

Let me know.
Regards
Logged
Regards
Trevor McCarthy-White
Synology DS411 NAS server/JR ID24.0.17/MC26.0.107-5/Benchmark DAC1 USB/Rotel RC1590/RB1582Mk2/Bowers and Wilkins CM10S2/CM1S2/Ruark Dialogue/REL R205

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Playback on the Id has slow track transitions
« Reply #7 on: September 11, 2016, 03:17:15 pm »

Bob,

Since you're having trouble reproducing this, maybe it's related to the display.  What I mean, is, most ID customers seem to use them headless.  How are you guys doing it with your test systems?  Do you have real monitors attached?  What about remote control sessions like VNC or other?

But the real question is this:  How does MC display it's GUI on a truly headless Id?  Is there an X server running that it's sending it's display to?  Is there a built in VNC session with it's own X server?  I would guess there has to be *something* or MC wouldn't have a GUI at all.  Is MC on the Id running a server type version which does not use an interactive GUI?

Just thinking out loud because I don't have an Id, and don't know exactly how it works.

Brian.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient
Re: Playback on the Id has slow track transitions
« Reply #8 on: September 11, 2016, 03:29:24 pm »

I don't have an Id, but the spectrum analyzer has always caused really serious CPU usage on MC for Linux.  Like 15% or 20% cpu usage on an i7 type of CPU usage, and enough usage to make a raspberry pi grind to a halt.  So the first thing I do when starting MC for Linux (especially on Pis or low powered hardware) is to disable the spectrum analyzer. 

I don't see remotely similar CPU usage on the windows side in some cases on the exact same machine dual booting.  Is it possible that it's just adding enough CPU load to slow things down?  Performance monitoring with something like Munin might show some things too.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72438
  • Where did I put my teeth?
Re: Playback on the Id has slow track transitions
« Reply #9 on: September 11, 2016, 05:17:59 pm »

... most ID customers seem to use them headless.
I don't think that's accurate.  There are a very wide variety of use cases.

It's an Id, not an ID.  Rhymes with kid.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #10 on: September 13, 2016, 12:12:07 pm »

Bob,

Since you're having trouble reproducing this, maybe it's related to the display.  What I mean, is, most ID customers seem to use them headless.  How are you guys doing it with your test systems?  Do you have real monitors attached?  What about remote control sessions like VNC or other?

But the real question is this:  How does MC display it's GUI on a truly headless Id?  Is there an X server running that it's sending it's display to?  Is there a built in VNC session with it's own X server?  I would guess there has to be *something* or MC wouldn't have a GUI at all.  Is MC on the Id running a server type version which does not use an interactive GUI?

Just thinking out loud because I don't have an Id, and don't know exactly how it works.

Brian.

Brian,
I test them with a monitor attached and without.
The headless mode is still running X using the dummy xserver driver.
When MC starts in headless mode, it runs minimized. I don't know what the spectrum analyzer actually does then. I imagine it still runs but since it's not displaying on real hardware I wouldn't expect the CPU usage to increase.

I would expect the spectrum analyzer to run dismally when a remote connection is being used (either VNC or Remote Dekstop).
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #11 on: September 13, 2016, 12:13:39 pm »

I don't have an Id, but the spectrum analyzer has always caused really serious CPU usage on MC for Linux.  Like 15% or 20% cpu usage on an i7 type of CPU usage, and enough usage to make a raspberry pi grind to a halt.  So the first thing I do when starting MC for Linux (especially on Pis or low powered hardware) is to disable the spectrum analyzer. 

I don't see remotely similar CPU usage on the windows side in some cases on the exact same machine dual booting.  Is it possible that it's just adding enough CPU load to slow things down?  Performance monitoring with something like Munin might show some things too.

It seems to use a pretty small amount of CPU on mine. I wonder if this is video driver related?
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Playback on the Id has slow track transitions
« Reply #12 on: September 13, 2016, 03:01:17 pm »

The headless mode is still running X using the dummy xserver driver.

While I've spent a great deal of time with Linux in the past but I'm not all that informed or expert on current configuration, X servers, etc.  That being said, I wonder if the dummy X server has some performance limitations or strange interactions with real time processes like a spectrum analyzer.

I suppose that all of my speculation isn't terribly useful until you can reliably reproduce the problem.  Once you *can* reproduce the problem at will, it should be just a matter of changing one thing at a time until you (hopefully) find the part of the system causing the issue.

Are you using a dummy X server because modern video cards, like the one in the Id don't like having no monitor and won't start?  Older video cards with VGA ports didn't care at all and would be "headless" just by unplugging the monitor.  If this turns out to be the root cause of the issue, perhaps an HDMI dummy plug is the way to go.

Again, just thinking out loud.

Brian.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient
Re: Playback on the Id has slow track transitions
« Reply #13 on: September 13, 2016, 04:56:37 pm »

Are you using a dummy X server because modern video cards, like the one in the Id don't like having no monitor and won't start?  Older video cards with VGA ports didn't care at all and would be "headless" just by unplugging the monitor.  If this turns out to be the root cause of the issue, perhaps an HDMI dummy plug is the way to go.

In my experience you can typically force modern video hardware to initialize headless, but it can take a little fiddling.  The dummy xserver is dramatically easier to configure and doesn't require you to know anything about the hardware.  The only (usual) drawback is that you get zero hardware acceleration for graphics with the dummy xserver.  Come to think of it, that might actually be the issue if the analyzer expects hardware accel and is failing back to software acceleration.  That would cause pretty dramatic increases in CPU use. 

Something to investigate, I'd guess; almost all of the systems I've seen the issue on are either running a virtual xserver or using nvidia cards with the proprietary drivers which aren't always the best integrated into the linux userspace. 
Logged

patairmax

  • Recent member
  • *
  • Posts: 7
Re: Playback on the Id has slow track transitions
« Reply #14 on: September 27, 2016, 12:03:18 pm »

Don't know if this can bring some clues for this bug (playback has a slow track transition) resolution on the Id, but I experienced exactly this issue on a standard JRiver installation, Not Id one, a version 22 installed on a Windows 10 PC (Zotac Celeron 1,8Ghz Quad core + 4GB RAM). The Music files are all installed on a local USB 3 disk attached to the machine.
My whole LAN is Gigabit compliant.

For the story, I've never had any problem with this installation (whatever MC version since 20, then 21) when the Zotac was connected directly to my DAC. Before buying a JRiver Id on SD card for a RPI3, I wanted to improve the solution before. So I configured the Zotac server with MC as a DLNA server and controller (not renderer).
I installed Moodle, then Volumio on a RPI B+ (version 1), I've not yet a RPI3. In such configuration, whatever the buffer sizes tested, there's always a slow (and painful) track transitions. I believed it was the fault of the RPI, but no. I've also MinimServer installed on my QNap NAS and when the RPI is fed by MinimServer, I've no issue, the DLNA control and track transition are very very responsive. The problem is only when I use the MC server to feed the RPI or even a more powerful NUC i3 with Volumio (same observation) ^^

So I tested to disable the Spectrum Analyzer tip, but the problem remain the same.

So the fact is may be, this problem is not tied to the Id distribution but something to do when the DLNA server is used to serve the files to another upnp renderer. I configured my DLNA server for "Audiophile 24bits DAC". May be I could try a PCN on 16bits instead of 24... Does this make sense ?
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #15 on: September 27, 2016, 01:40:29 pm »

Don't know if this can bring some clues for this bug (playback has a slow track transition) resolution on the Id, but I experienced exactly this issue on a standard JRiver installation, Not Id one, a version 22 installed on a Windows 10 PC (Zotac Celeron 1,8Ghz Quad core + 4GB RAM). The Music files are all installed on a local USB 3 disk attached to the machine.
My whole LAN is Gigabit compliant.

For the story, I've never had any problem with this installation (whatever MC version since 20, then 21) when the Zotac was connected directly to my DAC. Before buying a JRiver Id on SD card for a RPI3, I wanted to improve the solution before. So I configured the Zotac server with MC as a DLNA server and controller (not renderer).
I installed Moodle, then Volumio on a RPI B+ (version 1), I've not yet a RPI3. In such configuration, whatever the buffer sizes tested, there's always a slow (and painful) track transitions. I believed it was the fault of the RPI, but no. I've also MinimServer installed on my QNap NAS and when the RPI is fed by MinimServer, I've no issue, the DLNA control and track transition are very very responsive. The problem is only when I use the MC server to feed the RPI or even a more powerful NUC i3 with Volumio (same observation) ^^

So I tested to disable the Spectrum Analyzer tip, but the problem remain the same.

So the fact is may be, this problem is not tied to the Id distribution but something to do when the DLNA server is used to serve the files to another upnp renderer. I configured my DLNA server for "Audiophile 24bits DAC". May be I could try a PCN on 16bits instead of 24... Does this make sense ?

Would you try an older version of MC 22 that is pushing the track to the renderer?
22.0.18 or older

And see if that makes a difference? There was a change to the DLNA renderer status detection that started after 22.0.18
Logged

patairmax

  • Recent member
  • *
  • Posts: 7
Re: Playback on the Id has slow track transitions
« Reply #16 on: September 28, 2016, 01:54:47 am »

Would you try an older version of MC 22 that is pushing the track to the renderer?
22.0.18 or older

And see if that makes a difference? There was a change to the DLNA renderer status detection that started after 22.0.18
Hi Bob, thank you for the answer. I would prefer to have someone else to do the test. I never succeed in a smooth version transition, each time its the mess with my music library when I change version with the backup/restore function, may be I do not manage well this process...
Something sure, JRemote (on iPad) has also a concern to switch and stick on the upnp renderer zone. It switches to then revert back to default player zone. I can't use it. EOS on Android works well, I've not tested Gizmo, but its another subject.
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Playback on the Id has slow track transitions
« Reply #17 on: September 28, 2016, 09:07:47 am »

Changes to MC's minor versions should have ZERO impact on your library.  I.E., switching from 22.0.1 to 22.0.256 and then to 22.0.52, and back to 22.0.1 should make no difference in the library.  No re-import, or backup/restore, or anything.  It will internally change the licensing, which takes about 20 seconds (on my system), but that's automatic.  So no extra effort is required.

Brian.
Logged

patairmax

  • Recent member
  • *
  • Posts: 7
Re: Playback on the Id has slow track transitions
« Reply #18 on: October 02, 2016, 05:01:38 am »

I agree to act as tester even if I would appreciate to have the JRiver team managing the issue, but ok, where can I download the release 22.0.18 ?
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #19 on: October 03, 2016, 10:10:56 am »

I agree to act as tester even if I would appreciate to have the JRiver team managing the issue, but ok, where can I download the release 22.0.18 ?
Thanks for the help, it's really impossible for us to test all possible combinations on with all of the hardware out there.

Is the PC you are running MC as a server on running Windows, Mac or Linux?
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #20 on: October 03, 2016, 03:27:07 pm »

Thanks for the help, it's really impossible for us to test all possible combinations on with all of the hardware out there.

Is the PC you are running MC as a server on running Windows, Mac or Linux?

Edit: NVM, from what I see the issue is more likely to be the MC configuration on the DLNA server.
Audiophile 24 bit DAC sends wave files to the renderer. It's possible the renderer can't deal with a wave file streamed to it without buffering the whole track.

Perhaps try Headerless 16 bit PCM (L16). I'd expect that to be streamable. Also, just for testing you could try mp3.
Logged

BradATIMA

  • Citizen of the Universe
  • *****
  • Posts: 1641
Re: Playback on the Id has slow track transitions
« Reply #21 on: October 03, 2016, 03:42:54 pm »

Hi Bob and ImTrying,

I have an Id and running JRiver MC 20 (latest revision) as a renderer with Synology DS411 and DSM6 as my DLNA server. I too use both my iPhone 6S and Ipad (both iOS 9.3.5 recent updated)

I had the problem of track switching taking forever. If I started from a freshly booted Id (would normally keep on but wanted reference for testing) it would start the first track within 1 or 2 seconds (OK) but if I switched to another track even on the same album it would take increasingly longer to move tracks. What I did observe was that this only seemed to occur if I was playing music on the 'Player' (My hifi system) rather than either 'this device' respectively my iPad or iPhone depending which I was using at the time. I also noticed that I could switch tracks OK using interactive mode on the Id itself.

Simply disabling the 'Spectrum Analyser' display as you described solved the problem straight away. Can I be of any assistance in helping you replicate this?  I'm sure the problem started after I upgraded to the latest MC software just over a month ago.

Let me know.
Regards

It would really help if you could give us more information about your setup so that we might be able to reproduce this problem. First of all, what options have you changed from the default on the Id itself? If you've made changes in DSP Studio, what are they? What types of files are you playing? What device are you playing to, and is it via HDMI, USB, et cetera? And, what DLNA server settings are you using?
Logged

patairmax

  • Recent member
  • *
  • Posts: 7
Re: Playback on the Id has slow track transitions
« Reply #22 on: October 15, 2016, 04:05:35 am »

Hi Bob, sorry for the late answer, but in the mean time I received a RPI3. I changed nothing on the JRiver server side but the streaming problem disappeared completely. As you said it's may be something to deal with the renderer ?
The RPI3 is using Moode and my server is a Windows10 (Zotac Celeron Quad Core) with MC 22.
Logged

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #23 on: November 06, 2016, 07:52:19 pm »

Hi Bob,

I am also experiencing slow track transitions using the Id as a rendering device.    I just put together my Id last week:   bought the USB kit and installed it on a NUC5CPYH with 4GB RAM and a 64GB Kingston SSD.   I believe that makes my setup very similar to the Id package from JRiver.   I have connected the optical output of the Id to an audio receiver with a 96kHz 24 bit DAC.   I spent some time this weekend collecting this information.

A little background on how I use MC.   I am running MC21 in MC Server mode on an old Microsoft WHS Home Server.  It uses a library of music on the same server, and I have been playing from the Server library on different client setups over the past couple years.   Most of my library is ripped ALAC 44 kHz/16 bit lossless files, with a handful of recently purchased HD Tracks hi-res albums, all of which are 96 kHz/24 bit, except one which is 192 kHz/24 bit.   For the audio receiver I have relied on Apple Airplay to stream to the receiver.  The main reason for purchasing the Id was to be able to play the newer hi-res files on the audio receiver, using JRemote as the controller.

Client 1:  Windows 10 machine running MC21 using server library described above over a Gigabit wired connection.  The performance on this machine is excellent.   Specifically when transitioning tracks randomly or next track etc, using JRemote, the response is so immediate that I cannot tell based on response, whether I am playing 44/16 files, 96/24 files or 192/24 files.

Client 2:  Windows 7 machine running MC20 using server library described above over a wireless N connection.   The performance on this machine is still very good.   No streaming issues and with JRemote, while there is perhaps some small delays when transitioning tracks, it would still be challenging to identify the different resolution tracks based on delay.

Audio Receiver with Id.   When playing 44/16 audio tracks, there is a 2-3 second delay in transitioning tracks.  I measure this delay after the current track has stopped playing until hearing the start of the transitioned track.   I discovered that as I play higher resolution (bigger) files, the delay increases accordingly.  So, for the 96/24 tracks the delay time is approx. 10 s, and for the 192/24 tracks, approximately 15 s.  I set this Id up as a wireless client, and my first thought was that the wireless connection was the limiting factor.  So, I connected the same setup to a Gbit LAN connection, only to discover that the track transition delays were still slow.   Then I tried connecting a monitor and keyboard to the Id and tried controlling directly from MC.  Same results - slow transition times. 

I should point out that the measurements I am observing above are with the spectrum analyzer on the Id MC turned off.   When I first noticed the slow times I checked on the forums and found the discussion here.   So I turned off the analyzer and then started measuring - so for me turning it off had no or little effect.  I also was concerned that I was running mc21 on the server, and 20 on the Id, but my Client 2 seems to work fine with this same version configuration.

Finally, one odd thing I did notice is that the stated bit rate and file format at the top banner of the Id MC doesn't make sense.   Even though I was streaming the files mentioned above, and even though JRemote indicated the proper bit rates etc, the Id MC banner was showing 320 kbs and MP3 format.  I believe this was true whether I was viewing with a monitor connected or by connecting remotely to the Id and running in GUI mode.   In all other ways the sound/experience on the Id is quite good.  Obviously though with 10-15 s delays, it becomes challenging to try different tracks.

-Ralph
Logged

imugli

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1598
Re: Playback on the Id has slow track transitions
« Reply #24 on: November 06, 2016, 08:13:14 pm »

Perhaps a silly question - are you sure you don't have the id set up to transpose tracks?

Tools > Options > Media Network > Client Options > Audio Conversion

Make sure it's set to "Don't Convert Audio"

If the id is trying to transpose, that may be causing a buffering delay.

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #25 on: November 06, 2016, 11:29:48 pm »

Perhaps a silly question - are you sure you don't have the id set up to transpose tracks?

Tools > Options > Media Network > Client Options > Audio Conversion

Make sure it's set to "Don't Convert Audio"

If the id is trying to transpose, that may be causing a buffering delay.

Interesting.  The Id is set to "Convert Audio if Necessary" and the Encoder is set to "MP3 High Bandwidth".   These would appear to be default settings, as I did not change them and furthermore, my other windows clients have the same settings.   Yet, when I simply change the encoder to "pcm 24 bit ", the id track transition performance improves and is comparable to my other clients (and the meta data shows correctly on the top banner).   But, my other clients don't exhibit the transcoding delays - does the Linux version behave differently?

I need to set the DSP - Output Format - instructing it to resample 192 kHz at 96 kHz, but this seems to be a different setting than the client options, which appear to be bit depth related.  Still leaves the question, why on my windows clients does the "convert audio if necessary" have no effect, but on the Id it seemingly causes mp3 conversion ... ?  Also, when I chose "Don't convert audio" on the Id, my 192 kHz tracks won't play - this also makes no sense:  if the client options are for bandwidth (bit depth), choosing "don't convert audio" shouldn't matter.  A bit confused ...  but thanks!  Things are looking up.

Update 11/7:  Looking at this again, it seems now when I choose "Don't convert audio", I am able to play all formats, including the 192 kHz tracks.   So, choosing this option appears to have resolved my issues.  And the behavior now is identical to that of my Windows clients (even though they still have the default Convert audio if necessary selected), including normal/fast track transitions.

-Ralph


Logged

imugli

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1598
Re: Playback on the Id has slow track transitions
« Reply #26 on: November 08, 2016, 06:26:16 pm »

Interesting.  The Id is set to "Convert Audio if Necessary" and the Encoder is set to "MP3 High Bandwidth".   These would appear to be default settings, as I did not change them and furthermore, my other windows clients have the same settings.   Yet, when I simply change the encoder to "pcm 24 bit ", the id track transition performance improves and is comparable to my other clients (and the meta data shows correctly on the top banner).   But, my other clients don't exhibit the transcoding delays - does the Linux version behave differently?

I need to set the DSP - Output Format - instructing it to resample 192 kHz at 96 kHz, but this seems to be a different setting than the client options, which appear to be bit depth related.  Still leaves the question, why on my windows clients does the "convert audio if necessary" have no effect, but on the Id it seemingly causes mp3 conversion ... ?  Also, when I chose "Don't convert audio" on the Id, my 192 kHz tracks won't play - this also makes no sense:  if the client options are for bandwidth (bit depth), choosing "don't convert audio" shouldn't matter.  A bit confused ...  but thanks!  Things are looking up.

Update 11/7:  Looking at this again, it seems now when I choose "Don't convert audio", I am able to play all formats, including the 192 kHz tracks.   So, choosing this option appears to have resolved my issues.  And the behavior now is identical to that of my Windows clients (even though they still have the default Convert audio if necessary selected), including normal/fast track transitions.

-Ralph

I'm not able to answer the question re why it's slow with conversion turned on - my gut feeling is it's simply a matter of processing power available - but glad you got it working.

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #27 on: November 09, 2016, 05:58:09 pm »

I'm not able to answer the question re why it's slow with conversion turned on - my gut feeling is it's simply a matter of processing power available - but glad you got it working.

It doesn't really surprise me that there are delays with conversion turned on, especially as by default it converts to MP3, and in my case I was streaming 96 kHz / 24 bit files.   The remaining question relates to "convert audio if necessary".  I couldn't find any description of this option.   Does necessary mean when the system is bandwidth limited?  Further, again because this appears to be the default setting, why, on my windows MC, does this never get invoked, i.e. convert audio seems to be unnecessary since I have it set to this default, but no audio conversion takes place.  The problem I experienced with the Id above is because it DID convert audio, i.e. it considered it necessary for some reason.  What is that reason, given the hi-res files play fine once I select don't convert audio?  Why is the behavior different on the Id than on Windows MC?

A general question:  is there any downside to leaving the Id in GUI mode and connecting occasionally by rdp?   My Id seems to run fine in GUI mode, headless.   If I go to headless mode, I have to change it to GUI and reboot to make a config change ...

-Ralph
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient
Re: Playback on the Id has slow track transitions
« Reply #28 on: November 09, 2016, 07:20:08 pm »

It doesn't really surprise me that there are delays with conversion turned on, especially as by default it converts to MP3, and in my case I was streaming 96 kHz / 24 bit files.   The remaining question relates to "convert audio if necessary".  I couldn't find any description of this option.   Does necessary mean when the system is bandwidth limited?  Further, again because this appears to be the default setting, why, on my windows MC, does this never get invoked, i.e. convert audio seems to be unnecessary since I have it set to this default, but no audio conversion takes place.  The problem I experienced with the Id above is because it DID convert audio, i.e. it considered it necessary for some reason.  What is that reason, given the hi-res files play fine once I select don't convert audio?  Why is the behavior different on the Id than on Windows MC?

A general question:  is there any downside to leaving the Id in GUI mode and connecting occasionally by rdp?   My Id seems to run fine in GUI mode, headless.   If I go to headless mode, I have to change it to GUI and reboot to make a config change ...

-Ralph

The "necessary" in convert if necessary is based on whether the file is already in the format you asked for.  So if you'd be converting to mp3, convert if necessary would convert FLACs, but not mp3s. It's not in any way resource based, it's just doesn't convert if the file you're sending is already in the specified format.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #29 on: November 10, 2016, 12:48:50 pm »

Also, there is no reason not to leave it in GUI mode if you have a HDMI device attached when you boot.
Logged

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #30 on: November 12, 2016, 06:52:52 pm »

Also, there is no reason not to leave it in GUI mode if you have a HDMI device attached when you boot.

Bob, as I stated, I am using the Id without any HDMI device/monitor attached, i.e. headless.  Is there a downside to leaving the Id in GUI mode, and remote connecting periodically? So far, I am not seeing that it causes any issue.
Logged

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #31 on: November 12, 2016, 07:57:02 pm »

The "necessary" in convert if necessary is based on whether the file is already in the format you asked for.  So if you'd be converting to mp3, convert if necessary would convert FLACs, but not mp3s. It's not in any way resource based, it's just doesn't convert if the file you're sending is already in the specified format.

I'm afraid I still don't see this completely.   If I am using MC in client library/server setup, I don't believe I am asking for the file to be in any particular format.  The client is connected to a Server and requests files from the Server - it is simply a player or renderer.  To my knowledge, there is no way (besides the option in question) to tell the server I want mp3 for example (and why would I).   From the various posts recently, I get it, I should select "don't convert audio".  However I still find this configuration item to be confusing.   By default, MC is set to "convert if necessary / encode to mp3".   I have been utilizing the client/server configuration for some time.  On my client PCs, I have always played ALAC .mp4 files successfully, yet upon recent review, it turns out that the Server all along has been firing up the lame.exe process, apparently in unnecessary anticipation of converting files to mp3, yet this in fact never happens - I still end up with ALAC on the client.   On the Id though, with the default convert if necessary / encode to mp3 setup, the files actually were getting converted, resulting in the huge track transition delays described above.   So, in summary, wouldn't it be better to have the default configuration for MC be "don't convert audio" and secondly, why is the behavior I describe different on the Id than on a stock MC client?   In searching to understand this, I came across several users, both PC and Id, who were confused by the exact same behavior.

-Ralph
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient
Re: Playback on the Id has slow track transitions
« Reply #32 on: November 12, 2016, 09:48:12 pm »

So, in summary, wouldn't it be better to have the default configuration for MC be "don't convert audio" and secondly, why is the behavior I describe different on the Id than on a stock MC client?   In searching to understand this, I came across several users, both PC and Id, who were confused by the exact same behavior.

-Ralph

To your first point (i.e. default settings) I don't work for JRiver, but for what it's worth I agree with you, I think don't convert would be a better default setting on the MC client side settings (as opposed to the server side settings).

To your second point (why does this happen with some clients and not others), there may be a configuration difference between the instances that's not obvious, but one potential explanation is the "use local files if available option."  If that setting is checked a client will see if it has access (via a NAS share) for example to a file at the path reported by the server.  If it can find a matching file at that location, the client just plays the file directly and skips the server/conversion entirely.  If the client can't find a file, the server serves it using whatever conversion settings.  The reason the Id may be different than a windows client is that Linux paths are basically different than windows paths, so even if the Id has access to the remote drives it won't see anything at the server's file locations because they use windows paths.  So the server has to serve the file and conversion kicks on.  That's my best theory as to why you might see different results with different clients.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #33 on: November 14, 2016, 11:30:37 am »

Bob, as I stated, I am using the Id without any HDMI device/monitor attached, i.e. headless.  Is there a downside to leaving the Id in GUI mode, and remote connecting periodically? So far, I am not seeing that it causes any issue.
If it works that's fine. The headless mode was so that the Id could boot without a monitor attached. The original NUC's wouldn't do that if HDMI initialization was being done by linux on boot.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13871
Re: Playback on the Id has slow track transitions
« Reply #34 on: November 14, 2016, 11:38:32 am »

I'm afraid I still don't see this completely.   If I am using MC in client library/server setup, I don't believe I am asking for the file to be in any particular format.  The client is connected to a Server and requests files from the Server - it is simply a player or renderer.  To my knowledge, there is no way (besides the option in question) to tell the server I want mp3 for example (and why would I).   From the various posts recently, I get it, I should select "don't convert audio".  However I still find this configuration item to be confusing.   By default, MC is set to "convert if necessary / encode to mp3".   I have been utilizing the client/server configuration for some time.  On my client PCs, I have always played ALAC .mp4 files successfully, yet upon recent review, it turns out that the Server all along has been firing up the lame.exe process, apparently in unnecessary anticipation of converting files to mp3, yet this in fact never happens - I still end up with ALAC on the client.   On the Id though, with the default convert if necessary / encode to mp3 setup, the files actually were getting converted, resulting in the huge track transition delays described above.   So, in summary, wouldn't it be better to have the default configuration for MC be "don't convert audio" and secondly, why is the behavior I describe different on the Id than on a stock MC client?   In searching to understand this, I came across several users, both PC and Id, who were confused by the exact same behavior.

-Ralph
The Id should act the same as any other MC client/server combination.

If you have a MC PC (linux, mac, or windows) connected to an MC server, the conversion decision is determined on the client in the Media Network Options->Client Options (when connected to a Library server).

If you are pushing tracks to a MC client as a DLNA renderer, the conversion decision is based on the MC servers DLNA settings for the server associated with the renderer zone (if you have more than one or the default if there is only one).
Logged

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #35 on: November 14, 2016, 04:41:43 pm »

If it works that's fine. The headless mode was so that the Id could boot without a monitor attached. The original NUC's wouldn't do that if HDMI initialization was being done by linux on boot.

It boots fine (no monitor connected).  I have been connecting remotely to check the track characteristics and/or to make config changes, and occasionally rebooting as well.

Thanks,
  Ralph
Logged

rknox

  • Recent member
  • *
  • Posts: 42
Re: Playback on the Id has slow track transitions
« Reply #36 on: November 14, 2016, 06:29:29 pm »

The Id should act the same as any other MC client/server combination.

If you have a MC PC (linux, mac, or windows) connected to an MC server, the conversion decision is determined on the client in the Media Network Options->Client Options (when connected to a Library server).

If you are pushing tracks to a MC client as a DLNA renderer, the conversion decision is based on the MC servers DLNA settings for the server associated with the renderer zone (if you have more than one or the default if there is only one).

It appears that mwillems correctly identified what was happening with my Library Server setup:  on my windows 10 client, with the default client settings (play local file if one that matches library server file is found, convert audio if necessary, mp3 high bandwidth encoding), the "play local file ..." was overriding the file conversion settings because I have a Server directory share on my client PC.  The result was that my lossless library files would play normally (unconverted) as I was expecting.   However, with the exact same MC (default) initial setup on my Id, where there in no Share setup, my lossless library files were being converted to mp3 files.  This resulted in the huge track transition times (described in earlier post), not to mention being served up mp3's  :-\

I am interested in your thoughts, but it seems to me that the current default client settings are confusing because of the potential different results, depending on whether you have a share (or other local file source) in place.  Frankly, I had interpreted "local" in "play local file" to mean a file on the client itself, and had not considered the MC definition which includes shared Server directories.   For these reasons, it would seem to make more sense that "don't convert audio" be the default setting, or perhaps at least not to have the "play local file" by default, and that the results would be more in line with the typical use case.

A final point, which I raised earlier, is that I find the "convert audio if necessary" description to be confusing as it is not clear what necessary means.  If I had a library of lossless and mp3 files, for example, and I wanted to play mp3 all the time, then I get it.  But in my case, where all my files are lossless, and the goal is to render with as high quality as possible, convert if necessary makes no sense, and as I've encountered, combined with the mp3 encode default, only results in an unexpected and unwitting inferior experience.

My 2 cents,
   Ralph
Logged
Pages: [1]   Go Up