Print

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

[Shike]

Same problem as outlined here, here, here, and finally here

This issue has persisted since the last attempt to address it in 22.0.33 (10/11/2016)

When starting a track, it may start playing without the duration.  Giving it time may allow it to finally load (sometimes it will resolve fast, sometimes it takes a while, and sometimes it simply doesn't).  Sometimes the duration between remote and jriver itself is out of sync.  A good example is during a track change in which the client PC has progressed playback for roughly ~10 seconds.  By the time a remote (EOS, Gizmo, or JRemote) recognizes a new track is being played back the time will be ~10 seconds on the client and 1 on the remote meaning it can't track duration properly.  This can result in odd behavior based on remotes used, it's prone to causing issues with Gizmo for example (playback jumping).

Have the devs been able to replicate it or is additional information needed?

[JimH]

If you've started a thread, please continue to use it.  Don't post in the build thread.  It is probably specific to your device or network.  It isn't a common problem.

Did you try powering everything (computers, network, and playback device) down and back up?

Details would help.

[Shike]

It is probably specific to your device or network.  It isn't a common problem.

I disagree, this happened in relation to the "fix" of a bug that I identified and had verified by bob with attempted resolution in 22.0.32 and 33 - the behavior changed from flat out broken to broken but trying.

The initial bug I discovered had propagated from 21.0.34 till ~22.0.32 before being discovered and replicated.  It appears that the larger user base doesn't use multi-zone functionality or didn't have a large enough collection to trigger and notice the issue.

Did you try powering everything (computers, network, and playback device) down and back up?

Yes, I have power cycled multiple times. I do this any time there's an update hoping that something may have been fixed, even by accident.  This involved cycling my laptop (client running jriver), desktop (server running jriver), and phone (gizmo and EOS remote).

Details would help.

I've provided screenshots and information in multiple threads.  The OP has links to the multiple reports I've submitted.

See here for example.

Quoting:

Same issue that I reported here and the update thread before that - it's persisted in every version since 22.0.33.

"Playing to a different zone may prevent it from receiving information such as album artwork and MCWS track duration.  See attached screenshot.

If I let it sit for an extended period of time it may finally pull the artwork and time, but it takes over a minute to do so on longer tracks."

You can view the screenshot of that post - it seems that when it plays live it gives an estimate of track duration, and if I force it to the end and it's longer it will play.  Sometimes it entirely bombs track duration too though.  See new screenshot attached - it renders the artwork and song information but below 0:13 you can see track duration is not populated.  I'm using EOS because it displays this information appropriately (Gizmo makes it hard to show the issue).

Effectively, a few things happen:

There are times when starting a track on the client that the duration will not be found.  In these cases one of two things happen.  Either part of the track data will show and the end time on it won't, or it will be wrongly identified as a stream.

If enough time passes, it may finally resolve it

When it resolves, it's intermittent.  There are times when it resolves incorrectly, typically of a shorter length than the track's actual duration.

When the track changes, the remote will be out of sync with the stream on the client.  In EOS it just seems to continue out of sync, in Gizmo the behavior appears to result in jumping of location on the track on the client to "fix" the gap.

[Shike]

If you've started a thread, please continue to use it.  Don't post this in the build thread.  It is probably specific to your device or network.  It isn't a common problem.

Did you try powering everything (computers, network, and playback device) down and back up?

Details would help.

Jim, it's been a while since I answered your questions.  Please provide a response as to the intended actions of either jriver or requested actions of myself.  This has been going on for roughly three months and I believe I have been fairly patient and reasonable during the time. 

Thank you.

[Shike]

Could I have one of the team respond?  What is needed from me to prove this is a bug and have it reviewed? 

[JimH]

We will take a look when we have time.  You could help your case by sticking to details and skipping the complaining.  I removed some of the complaints above, in the interest of readability.

[bob]

Fixed in the next build >= 22.0.63

Fixed: DLNA device renderer returned 0 for current file duration in both the getPosition and getMediaInfo calls.
Fixed: MCWS returned 0 for position much longer than desirable causing the playback bar on JRemote and Gizmo to bounce back and forth until a valid position was received.

This was a difficult pair to track down. The earlier fix caught part of the problem but not all of it.

[Shike]

Fixed in the next build >= 22.0.63

Fixed: DLNA device renderer returned 0 for current file duration in both the getPosition and getMediaInfo calls.
Fixed: MCWS returned 0 for position much longer than desirable causing the playback bar on JRemote and Gizmo to bounce back and forth until a valid position was received.

This was a difficult pair to track down. The earlier fix caught part of the problem but not all of it.

Thank you!  You have no clue how much this means to me, it is very much appreciated.

[Shike]

I hate to revive this thread, but I've found the update only fixed progress on Gizmo.  I thought it was a bug with EOS maybe as it would finally fix duration after a refresh, so coughed up the money for JRemote and it has problems with the progress bar too (which only started after the latest fix to the bug in 63/65).  See the attached image of the progress bar showing the duration completed with a negative count that correlates to the play time.

It seems I'm not the only one that's encountered this:

Here an additional three people are noting it.

It seems this started around the fix from 65.  I'm currently running 22.0.77.

EDIT:

This is only happening on the local system (server/player) and not on the remote client, which seems to be working properly now.  EOS/JRemote requires a refresh to get the end time while Gizmo works properly.

[bob]

I hate to revive this thread, but I've found the update only fixed progress on Gizmo.  I thought it was a bug with EOS maybe as it would finally fix duration after a refresh, so coughed up the money for JRemote and it has problems with the progress bar too (which only started after the latest fix to the bug in 63/65).  See the attached image of the progress bar showing the duration completed with a negative count that correlates to the play time.

It seems I'm not the only one that's encountered this:

Here an additional three people are noting it.

It seems this started around the fix from 65.  I'm currently running 22.0.77.

EDIT:

This is only happening on the local system (server/player) and not on the remote client, which seems to be working properly now.  EOS requires a refresh to get the end time while Gizmo and JRemote work properly.

I want to verify the exact nature of this with you to try to see if we can reproduce it.

You are playing a track on MC22 Windows using JRemote (Android??) connected directly to the Windows PC and the file is a local file on the Windows PC which then demonstrates the bug?
Filetype of what you are trying to play??

[Shike]

You are playing a track on MC22 Windows using JRemote (Android??) connected directly to the Windows PC and the file is a local file on the Windows PC which then demonstrates the bug?

That is correct.  I'm using JRemote for Android, version is MC 22.0.77 for Windows.

The file type was MP3, I believe 320CBR though can double check when I get home if it helps.

[Shike]

I want to verify the exact nature of this with you to try to see if we can reproduce it.

You are playing a track on MC22 Windows using JRemote (Android??) connected directly to the Windows PC and the file is a local file on the Windows PC which then demonstrates the bug?
Filetype of what you are trying to play??

Bob, were you able to replicate the issue?  Do you need more info or logs?

[bob]

Bob, were you able to replicate the issue?  Do you need more info or logs?

Just got to this.
I'm using the latest build of MC 22.
I can't reproduce it. I can play a CBR mp3 on my android tablet with the latest JRemote and the progress bar is working fine.
Are you using "native" playback in your settings?

[Shike]

Just got to this.
I'm using the latest build of MC 22.
I can't reproduce it. I can play a CBR mp3 on my android tablet with the latest JRemote and the progress bar is working fine.
Are you using "native" playback in your settings?

Can you confirm where I would find native?  Is it a jremote setting or a jriver setting?

[bob]

Can you confirm where I would find native?  Is it a jremote setting or a jriver setting?

It's in the JRemote Settings.

[Shike]

Just looked, native is checked in jremote.

[bob]

Just looked, native is checked in jremote.

Interesting.
Maybe it's something odd about your particular android device playback.
Can you try unchecking native?

[Shike]

Interesting.
Maybe it's something odd about your particular android device playback.
Can you try unchecking native?

Turned off native, did not fix the issue.  I tried two tablets (Android 4.2 and 4.4) and my phone (Android 6.0) - all repeated the issue.

Bob, to confirm the testing:

Start a track on an album towards the beginning.  After it's played for a little while click next.  Not pause/stop.  That seems to be what triggers it.  If one uses stop, then changes tracks, the issue doesn't seem to persist - so it's like some condition that jremote is expecting isn't being met.

[bob]

Turned off native, did not fix the issue.  I tried two tablets (Android 4.2 and 4.4) and my phone (Android 6.0) - all repeated the issue.

Bob, to confirm the testing:

Start a track on an album towards the beginning.  After it's played for a little while click next.  Not pause/stop.  That seems to be what triggers it.  If one uses stop, then changes tracks, the issue doesn't seem to persist - so it's like some condition that jremote is expecting isn't being met.

Ok, I still can't make this happen following your process above. I'm testing on a amazon fire with 5.3.
Maybe try going into Settings->Manage all applications->JRemote and clear the cache, try again.
Then if that doesn't work, clear the data and try again??

[Shike]

Ok, I still can't make this happen following your process above. I'm testing on a amazon fire with 5.3.
Maybe try going into Settings->Manage all applications->JRemote and clear the cache, try again.
Then if that doesn't work, clear the data and try again??

Odd, I don't think clearling cache/data will do anything as it was a new install on the tablets but will try it when I get home.  To confirm on the Fire is jremote the same version currently in the Play Store or is there a different one on Amazon's marketplace?

The other thing I'm wondering is what version of Windows you're on.  I might be able to spring up a VM to test and see if the problem persists on a similar Windows config.  I'm using Win 10 Pro for my main system.

Since others have hit the bug I know it's not just me, so there's got to be a common factor somewhere to trigger it.

EDIT:

If needed I could do a clean Windows install on another partition rather than a VM with a clean jriver install as well.  Let me know if you think this would be better.

[bob]

Odd, I don't think clearling cache/data will do anything as it was a new install on the tablets but will try it when I get home.  To confirm on the Fire is jremote the same version currently in the Play Store or is there a different one on Amazon's marketplace?

The other thing I'm wondering is what version of Windows you're on.  I might be able to spring up a VM to test and see if the problem persists on a similar Windows config.  I'm using Win 10 Pro for my main system.

Since others have hit the bug I know it's not just me, so there's got to be a common factor somewhere to trigger it.

EDIT:

If needed I could do a clean Windows install on another partition rather than a VM with a clean jriver install as well.  Let me know if you think this would be better.

It's the Play Store version on the Fire (It's got play store installed).
I'll try the test myself on Win10 and post back...

[Shike]

Just a heads up, did a VM test myself on Windows 7.  It sometimes triggered the issue, and other times didn't.  Not sure if this could be a race condition?  If I exit the now playing screen and re-enter, the progress bar corrects (similar to the EOS "refresh").

I may try it at my parents' place to remove my network and systems as a variable, I should be able to do a clean install there as well.  Should offer a fair testbed.

[Shike]

Did a test on a clean Windows 7 install, mostly the same issues.  The majority of tracks encounter the duration issue when clicking next or on start.  Sometimes it will resolve duration properly at start on some tracks.  The test machine is a laptop with a slower HDD, I'm wondering if I/O speed might be playing into this some.  Using a VM would clearly slow it down on my main PC, and the laptop has a slower HDD than my main PC.  Either that or the Windows 7 created the "sometimes" working scenario.

Another user encountering this popped up in the .88 release/bug thread so that makes five users including myself that have encountered/reported it.

[ti_dust]

I'm the one that reported it in the .88 thread.  I have exactly the same problem as the OP.  It seems that JRemote (or eos) is not getting the current track duration value from MC correctly - it then calculates a negative time remaining, which puts the progress slider all the way to the right.  This causes a problem because if I want to seek to a certain position by tapping on the progress slider, the track simply starts from the beginning, then the slider goes to the right.  Rinse and repeat.  I've attached the same screenshot I showed in the 88 thread showing a negative time remaining value, which is what is causing the problem.

I am running Windows 10 Home x64 with all the latest updates.  I've encountered the same problem with build 81 and 88.  I am running a Samsung Galaxy S7 edge on verizon's network with android v7.0.  I am simply using the remote (JRemote or eos) as a remote - meaning that my library exists on the PC and MC, and MC is rendering the audio on my PC - the android remote software is simply being used as a "remote" to control playback.

I have tried uninstalling and reinstalling the android remote apps, clearing all data and cache for the apps within android.  Nothing fixes it.  The exact same thing happens with both eos and JRemote, which leads me to think it is a bug with MC.

For me, the slider issue is almost persistent and exists a majority of the time I try to play back files, making seeking an impossibility most of the time.  For me, this is a big issue because I frequently find myself wanting to replay a part of a song that I particularly liked, and I am simply unable to do so currently.

I have all the time in the world, so if anyone at JRiver would like help/assistance to replicate this problem and find a solution, please do contact me at the email address I registered with, or even here in the forums (I will try to frequent this forum for the near future).  I will be more than happy to try anything, and I am a savvy computer and android user.

Thank you!

Edit: I also attached my System Info from the MC software.
Edit2: I'm sorry for the edit, but I wanted to clear up how/when this happens.  If I just press play and let things go and don't touch anything, the problem doesn't show up much, if any.  The problem constantly shows up when I start manually changing tracks.
Edit3: Holy crap I am bad at this!  Some more info... if I use the BubbleUPNP DLNA app and set both the library and renderer to MC, it effectively acts as a remote only, since I have MC set up to play local files if found, which is what I play 100% of the time.  In this setup, the problem does not happen - progress slider always works perfectly.  I assume the app is communicating with MC purely with the DLNA protocol, which probably differs from how JRemote and eos communicate with it.  This is a solution, though I have other, unrelated issues with the app and still highly prefer JRemote, or even eos.

[bob]

I'm the one that reported it in the .88 thread.  I have exactly the same problem as the OP. ...

It your library mostly m4a?
Can you reproduce it with other formats?

[bob]

Hmmm, I see it now that I switched to windows 10. Interesting...

[ti_dust]

Woohoo!  Anyways, my library is all m4a and mp3, but I just tried flac files with no luck.  I also tried a bunch of different settings in playback options, including: changing output device, memory playback, prebuffering, play silence, track change type (gapless/etc), stop seek & skip options, as well as turning off all DSPs in the studio.  I also tried many different options in the media server area, though some of those were DLNA-related and perhaps not applicable.  I unfortunately wasn't able to find anything that fixed it.   

[bob]

Ok, now that we can make it happen it should be pretty easy to find...

[bob]

Finally found it.
Fixed in the next build.

[ti_dust]

Thank you bob (and anyone else responsible at JRiver) !!