Print

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

[Shike]

I posted here, except have significant updates.

Original summary - please read additional information

Effectively on some tracks on a Windows 10 x86 install they do not seek time properly to any remote (Gizmo, EOS, JRemote).  An example track is Shudder Before the Beautiful by Nightwish on album Endless forms most beautiful.  Some tracks do work on the x86.  All tracks work on the Windows x64 install I have (different machine).

The last known version of jriver I have that worked properly is 21.0.30.  On 21.0.34 it seems that had broke and has continued into the latest releases.  Reverting back to 21.0.30 restores the functionality.


Updated information:

This only happens when I'm playing a file from my main PC as a server to a second as a renderer.  If I turn it into a server and store a file locally on the PC that was acting as a renderer and have it play locally the seekbar and timestamps track appropriately.  Something seems to be bugging out on some tracks when UPNP/DLNA get involved. Equally, I turned my renderer to a server and tried playing to my main machine which is X64  to the exact same results.  This is not just a x86/x64 but seems intrinsic to MC.  In comparison FB2K works fine with the UPNP plug-in and a generic Android remote for tracking.

As a follow-up though a quick question: has this been added to a tracker or noted anywhere?  I haven't got a single response in relation to this?  I've posted this bug five times and want to confirm it's being seen and if it's being looked into or not.

[bob]

So, in summary, the i386 vs x64 difference was a red herring?

Are you using PC's on both ends?

Are they both windows 10?

[bob]

Also, what is the file type?

[Shike]

So, in summary, the i386 vs x64 difference was a red herring?

Yes, I originally thought that was the cause.  I went back to the drawing board on this and found it impacts both directions regardless of x86 v x64.

Are you using PC's on both ends?

Yes.

Are they both windows 10?

Also yes.

Also, what is the file type?

MP3, equally it's some albums/tracks and not others.  When reverting to 21.0.30 (yes, quite old) everything works fine, but something broke between it and 21.0.34 (don't have any of the installers for versions between to narrow it down further).

[bob]

On the PC that you are playing the music on, in the Media Network settings
Under "Client Options (When Connected to a library server)"
Audio Conversion
Set it to "Don't Convert Audio"
and try the test again please.

[blgentry]

MP3, equally it's some albums/tracks and not others.

Look at some of your "trouble" songs.  What is the bitrate?  Variable, or fixed?  Fixed bit rates would be something like 128, 160, 192, 320.  Variable would show up as unusual numbers:  232, 110, 153, etc.

Brian.

[bob]

You said in your PM that turning off audio conversion for the client PC connection to the server PC didn't work and the source files are mp3?
Something is off there. That's the most basic of functions.

We need to review your settings.
You have a server PC and a client PC running windows. The client PC is connecting to the server PC by loading it's library underneath the "Playing From" . You then connect to the client PC with gizmo to play a track?

[Shike]

Look at some of your "trouble" songs.  What is the bitrate?  Variable, or fixed?  Fixed bit rates would be something like 128, 160, 192, 320.  Variable would show up as unusual numbers:  232, 110, 153, etc.

Brian.

The files I'm having trouble with are CBR from the ones I've tried on a few albums.  My main test track is 320CBR as I know it works on older versions.

You said in your PM that turning off audio conversion for the client PC connection to the server PC didn't work and the source files are mp3?
Something is off there. That's the most basic of functions.

We need to review your settings.
You have a server PC and a client PC running windows. The client PC is connecting to the server PC by loading it's library underneath the "Playing From" . You then connect to the client PC with gizmo to play a track?

That is correct.  Both systems run Windows 10, I select to play to the client and choose the server to play from within Gizmo.  Equally when I reverse their positions (and adding the problem file to the former client made server) the issue is repeatable.

[bob]

The files I'm having trouble with are CBR from the ones I've tried on a few albums.  My main test track is 320CBR as I know it works on older versions.

That is correct.  Both systems run Windows 10, I select to play to the client and choose the server to play from within Gizmo.  Equally when I reverse their positions (and adding the problem file to the former client made server) the issue is repeatable.

Ok so you are connecting to the server PC from Gizmo and choosing the playback zone on Gizmo which is an output device on the client (playback) PC. All of the source files are stored on the server PC. Correct?

In this case you aren't using library server at all (you are using the client PC as a DLNA renderer). The client PC should not be setup to use a library from the server PC.

In this configuration, what determines the output format is the settings of the DLNA server on the server PC and the whatever DLNA server the client PC zone on the server PC's tree is set to.

If a file is already high bitrate MP3 it will not be converted if you are still using the Generic DLNA server template for the server PC.



Another way of doing this would be to have the client PC load the server PC library by default then use Gizmo to connect to the client PC. Then the Client PC options for Media Network on the Client PC would be used when pulling the file from the server PC.

[Shike]

Ok so you are connecting to the server PC from Gizmo and choosing the playback zone on Gizmo which is an output device on the client (playback) PC. All of the source files are stored on the server PC. Correct?

Correct.

In this case you aren't using library server at all (you are using the client PC as a DLNA renderer). The client PC should not be setup to use a library from the server PC.

In this configuration, what determines the output format is the settings of the DLNA server on the server PC and the whatever DLNA server the client PC zone on the server PC's tree is set to.

If a file is already high bitrate MP3 it will not be converted if you are still using the Generic DLNA server template for the server PC.

Checking the server I found that it's using the Generic DLNA Server template.

Another way of doing this would be to have the client PC load the server PC library by default then use Gizmo to connect to the client PC. Then the Client PC options for Media Network on the Client PC would be used when pulling the file from the server PC.

True, but I'd like to stick to DLNA if at all possible as I want it to be standardized as I get more enabled devices over time.

[bob]

What is the exact name of the zone on the server PC that represents the MC DLNA renderer on your client PC?

Also, can you email me one of your tracks that doesn't work so I can try to duplicate your setup precisely?
bob (at) jriver (dot) com.
 

[Shike]

What is the exact name of the zone on the server PC that represents the MC DLNA renderer on your client PC?

It's called "Bedroom" (no quotes)

Also, can you email me one of your tracks that doesn't work so I can try to duplicate your setup precisely?
bob (at) jriver (dot) com.

Track sent.

[bob]

Thanks for pinning it down.
it's a change between 21.0.30 and 31 regarding the playing of web radio stations.
It's a bit unclear as to how to solve it at this time but we are looking at it...