INTERACT FORUM
More => Old Versions => JRiver Media Center 24 for Windows => Topic started by: amsco15 on October 01, 2018, 10:58:31 am
-
I've been using JRiver and it's DLNA capability to run a PS Audio Bridge for several years and several major versions of MC. At first (several years ago), I had issues with songs not advancing properly. Whitebear in the DLNA thread helped and I got things working perfectly for a very long time. This weekend, after updating to 24.0.52 (from 24.0.50), I had several problems with tracks not advancing to the next track (gets stuck at the end of a previous track, usually stuck at the end of track 1)! Nothing changed in my set-up with the exception of 24.0.52. I have not troubleshot with the various settings like SetNext, etc. (All three are currently selected).
Is it possible that the change listed below had an impact on tracks not advancing?
NEW: DLNA: If MC is playing to (controlling) a renderer and the track playback stops before the end (granularity of 5 seconds) we assume another controller has been used to stop the playback and as such we will not continue a playlist and assume we are no longer the active controller.
Thanks!
-
Try toggling SetNext...
-
Didn’t fix it. Gets stuck only on the first song of a playlist. Repeatable every time....not just the first song. Don’t see a pattern at this point (thought I did).
-
Happened again this morning. Gets stuck after the first track in the playlist every time. If I pad the playlist with a random song and start playing music on track two of the playlist, the playlist doesn’t get stuck. The problem appeared after updating to 24.0.52.
-
Rolled back to 24.0.50 and the track advancing issue is gone.
-
I am currently streaming from MC to my renderer over DLNA with no problem. Perhaps the PS Audio Bridge is the problem. Have you tried the latest version 24.0.55?
-
Of course it’s possible the bridge is the problem; however, I’ve been successfully using MC with the Bridge since MC 19 or so (lost track of how long - I update with every major revision).
No I haven’t tried 24.0.55. Nothing in the updates list looks like it would impact DLNA functions from 24.0.52 to 24.0.55.
Can’t help but suspect this change from 24.0.51 (see below), but I don’t have the expertise to evaluate much deeper. Feels like I’m going to stay with 24.0.50 for some time.
NEW: DLNA: If MC is playing to (controlling) a renderer and the track playback stops before the end (granularity of 5 seconds) we assume another controller has been used to stop the playback and as such we will not continue a playlist and assume we are no longer the active controller.
-
NEW: DLNA: If MC is playing to (controlling) a renderer and the track playback stops before the end (granularity of 5 seconds) we assume another controller has been used to stop the playback and as such we will not continue a playlist and assume we are no longer the active controller.
Is there something in your system that could be activating this new DLNA condition - ie sending a stop playing signal? Does MC have exclusive use of the audio output?
-
Is there something in your system that could be activating this new DLNA condition - ie sending a stop playing signal? Does MC have exclusive use of the audio output?
Don’t know the answer to either question. I’m willing and capable of digging into things when I understand what to try.
-
I guess you have tried rebooting the bridge card?
-
Yup. Tried a couple versions of the card’s OS too. So far, the only fix has been 24.0.50.
-
OK, well can I plead that you try the 55 version and if that doesn't work we can keep bumping your post til Matt or one of the others takes an interest.
-
Of course. I'll try it now. Thanks for your help.
-
Just installed 24.0.55 64 bit. Selected an entire album to play (22 tracks). Playlist got stuck after the 1st track (like I've been describing). Going back to 24.0.50. Thanks again for your help.
BTW, toggling SetNext doesn't solve the problem like I mention above and the setting automatically gets re-selected to Disable SetNext. Think that was a feature added a while back to MC if a renderer (Bridge II in this case) acted up in a specific way.
-
Sorry for all the posts. Just wanted to complete the circle. Went back to 24.0.50 (after the 24.0.55 experiment above), selected the exact same playlist I chose a moment ago with 24.0.55 and it's playing exactly as it should. Thanks again!
-
Surely someone on the forum can offer some suggestions here?
-
Try toggling SetNext...
That was mine.
Power everything down and back up after the changes.
Antivirus software could also cause problems with one build of MC and not another.
-
How long is the first track?
Does the progress bar move past 5 seconds?
Would you post a log please? (start logging just before hitting play on the playlist then end logging several seconds after the track fails to advance).
-
Thanks for taking a look at this:
- First track is 3:03
- Progress bar moves normally until the end of the first track then stalls at -0:03
Log is attached. Please let me know if you’d like me to try anything else. This stall occurred with a playlist of 26 tracks. If I skip to track two, the playlist stall doesn't occur (the attached log does not reflect that: just selected an album of 26 tracks and let it play till it stalled). Other playlist stalls have occurred when data rates or file types change. Most of my tracks are 16/44.1 in FLAC but I do have some HD FLAC and DSF files.
I would like to address the anti-virus issue. I use only Windows Defender and have followed the recommendations in the thread "How to tame Windows Defender." I have followed those recommendations for several past versions including 24.
Thanks again!
-
I wonder what in your system is causing these lines in your log
0214813: 44484: Playback: CPlayerZone::DLNAProcessPlaybackState: Device stopped by another controller at: 177470 of 183000 MS
0214813: 44484: Playback: CPlayerZone::DLNAProcessPlaybackState: Finish (16 ms)
Perhaps Bob will have some idea?
What playback device are you using the bridge to connect to?
-
The PS Audio Directstream DAC with integral Bridge II card. Been using it for sometime now.
https://www.psaudio.com/products/directstream-dac/
-
That is a nice piece of kit. Would it be possible to try to play to it through the async usb connection, to take the BridgeII out of the equation?
-
If I really had to...but it would be a relatively big deal to accomplish. Not sure how that would help. I'm set up to stream from another room and have done so for years. Everything works fine under 24.0.50.
-
Best wait and see what bob comes up with then - I'm sure they will want MC to be able to play properly to one of the best dacs around!
-
I wonder what in your system is causing these lines in your log
0214813: 44484: Playback: CPlayerZone::DLNAProcessPlaybackState: Device stopped by another controller at: 177470 of 183000 MS
0214813: 44484: Playback: CPlayerZone::DLNAProcessPlaybackState: Finish (16 ms)
Perhaps Bob will have some idea?
What playback device are you using the bridge to connect to?
Thanks for slicing that out, it's exactly what I was looking for.
It's stopping 5.5 seconds before the calculated end of the track. We look for stops at a position >5.0 seconds from the end of a track indicating another controller is stopping the playback.
Either some other controller is sending a stop command or the renderers getPosition is returning a pretty sloppy or stale value.
I made a change for the trigger value from 5.0 seconds to 6.0. That will be enough I trust. It will be in the next build.
-
Thanks, I’ll look for that update. I don’t have any other controller on the network, just JRemote and MC, so I’ll blame the Renderer. It’s a Converse Digital product and I suspect they implement DLNA imprecisely.
-
Did you check all three DLNA options in JRiver? If I don't check all three options, I also encounter the problem you describe (with a DirectStream DAC with Bridge II).
-
Yep, know all about that. Thanks! All three are checked and tried checking and unchecking and all the combinations. That wasn’t the issue. See above.
-
It's stopping 5.5 seconds before the calculated end of the track. We look for stops at a position >5.0 seconds from the end of a track indicating another controller is stopping the playback.
Either some other controller is sending a stop command or the renderers getPosition is returning a pretty sloppy or stale value.
I made a change for the trigger value from 5.0 seconds to 6.0. That will be enough I trust. It will be in the next build.
Played my system all weekend (I'm on 24.0.60) and it looks like #5 the fix in 24.0.57 (10/11/2018) worked.
Thanks!!
-
From the 24.0.61 Release notes:
13. Fixed: DLNA: When we are trying to detect if another controller has taken over from us to stop our playback of a playlist, we weren't handling the case where a user seeks on a track during that playback.
14. Changed: DLNA: Don't post a WM_UPDATE_DLNA_PLAYBACK_STATE when receiving a transport event unless the state is actually changing. This can fix an issue where renderers that are very slow to respond to play state changes (>5 seconds) confuse logic to determine if we are the DLNA controller in charge (BubbleUPnP wrapping chromecast).
Sorry but I don't understand what this means. I assume these items are related to my original post? The 5 to 6 seconds change in 24.0.57 fixed this issued. Is this a further refinement of that fix?
Thanks!!
-
From the 24.0.61 Release notes:
13. Fixed: DLNA: When we are trying to detect if another controller has taken over from us to stop our playback of a playlist, we weren't handling the case where a user seeks on a track during that playback.
14. Changed: DLNA: Don't post a WM_UPDATE_DLNA_PLAYBACK_STATE when receiving a transport event unless the state is actually changing. This can fix an issue where renderers that are very slow to respond to play state changes (>5 seconds) confuse logic to determine if we are the DLNA controller in charge (BubbleUPnP wrapping chromecast).
Sorry but I don't understand what this means. I assume these items are related to my original post? The 5 to 6 seconds change in 24.0.57 fixed this issued. Is this a further refinement of that fix?
Thanks!!
Change 14 fixed your lack of track advance. Change 13 was a fix for track advance in case of a manual seek during playback.