Print

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

[Patrick8639]

Hello,
Still has problem listening to mp3 tracks.

Configuration:
- Windows 10 PC with JRiver MediaCenter.
- Gizmo on my Android phone as a Remote Control.
- Denon DNP-F109 Network Music Player.

I play an album will all mp3 tracks, by selecting them and dragging to the Denon player on my PC.
At the end of a track, it skips the next one or, sometimes, stops playing the remaining tracks.

[tonysawford]

I appear to have lost gapless playback in this version.

MC is running on 64 bit Windows, managing a large library of FLAC files on a local hard drive.
I use JRemote on iOS to control MC, streaming to a Cambridge Audio CXNv2 player.
I've used Whitebear Media Renderer Analyser to confirm that the CXNv2 supports SetNextAVTransportURI.
The DisableSetNextSupport option is not enabled.

I now get a small but very noticeable pause between every track on playback. For some albums / playlists this doesn't matter, but for others (live albums, for example), it definitely does.

Tony

[JimH]

Hello,
Still has problem listening to mp3 tracks.

Configuration:
- Windows 10 PC with JRiver MediaCenter.
- Gizmo on my Android phone as a Remote Control.
- Denon DNP-F109 Network Music Player.

I play an album will all mp3 tracks, by selecting them and dragging to the Denon player on my PC.
At the end of a track, it skips the next one or, sometimes, stops playing the remaining tracks.

Please start a new thread on this.  It appears to be a DLNA problem, probably a setting.  Try toggling SetNextAVTransport.

[bob]

I appear to have lost gapless playback in this version.

MC is running on 64 bit Windows, managing a large library of FLAC files on a local hard drive.
I use JRemote on iOS to control MC, streaming to a Cambridge Audio CXNv2 player.
I've used Whitebear Media Renderer Analyser to confirm that the CXNv2 supports SetNextAVTransportURI.
The DisableSetNextSupport option is not enabled.

I now get a small but very noticeable pause between every track on playback. For some albums / playlists this doesn't matter, but for others (live albums, for example), it definitely does.

Tony

See change #12 under 25.0.84. I'm wondering if this is your issue?
Can you verify with a previous build please?
There should be plenty of time given to the renderer for buffering the next track after that change but it would be good to verify that.
We have a NP30 here that I'll run a test on. What format is your source material and is it being transcoded?

[tonysawford]

See change #12 under 25.0.84. I'm wondering if this is your issue?
Can you verify with a previous build please?
There should be plenty of time given to the renderer for buffering the next track after that change but it would be good to verify that.
We have a NP30 here that I'll run a test on. What format is your source material and is it being transcoded?

@bob - I think you might be on the right track.

I reverted to 25.0.80 (the last stable release I could find before 25.0.84), and that behaved exactly as desired - no gaps during playback at all.
I then installed 25.0.89 (the first stable release I could find after 25.0.84) and that has the gappy behaviour that I reported, so it would seem that the problem did not appear in 25.0.92 - I just didn't notice it previously.

In answer to your question, all the source material is FLAC (a mixture of 16- and 24-bit, 44.1 & 96kHz) and it's not being transcoded.

[DocLotus]

I appear to have lost gapless playback in this version.

Same here. I have since manually reset all my gapless settings back to where I want them.

[bob]

Same here. I have since manually reset all my gapless settings back to where I want them.

Can you elaborate on this please?
It's not clear if you are still using 25.0.92 and just changed something in the settings. Thanks.

[DocLotus]

It's not clear if you are still using 25.0.92 and just changed something in the settings. Thanks.

Yes, 25.0.92.
I changed nothing after installing 25.0.92 but noticed right away there were very long gaps between songs. After several days I noticed that my gapless settings were gone. I then manually set them back to gapless & all is now right with the world.

[bob]

I split this into a Media Network topic.

Tested 25.0.92 gapless today with mp3's to a Cambridge NP30 and a Sonos Play:3 and both worked fine.

I thought 18 seconds would be enough (3 * the command timeout value) but it's possible that the interval before the end of the track when the next URL is sent is too short for some devices especially with slow processors.

[tonysawford]

I split this into a Media Network topic.

Tested 25.0.92 gapless today with mp3's to a Cambridge NP30 and a Sonos Play:3 and both worked fine.

I thought 18 seconds would be enough (3 * the command timeout value) but it's possible that the interval before the end of the track when the next URL is sent is too short for some devices especially with slow processors.

@bob
Have you tried with FLAC files?

Also, when you say “devices ... with slow processors” do you mean the renderer device or the MC host computer?

[bob]

@bob
Have you tried with FLAC files?

Also, when you say “devices ... with slow processors” do you mean the renderer device or the MC host computer?

The renderer, unless conversion is enabled on the MC side but in general that's really very fast even on slow processors.
Many renderers (especially but not limited to DVD/BD players) have pretty slow processors.
Flac (44.1k/16) worked fine for me to the Cambridge as well. I usually use Abbey Road for testing, driving everyone here nuts
Maybe yours is just on the edge. It probably won't hurt anything to bump the send next track info back another 6 seconds. I'll get that into the next build.

[tonysawford]

Great

One other possible approach would be to have a per-renderer flag that allowed you to choose between pre- and post-25.0.84 behaviour. That would (I believe) definitely work for me, as 25.0.80 played everything flawlessly when I tried it.

[bob]

Great

One other possible approach would be to have a per-renderer flag that allowed you to choose between pre- and post-25.0.84 behaviour. That would (I believe) definitely work for me, as 25.0.80 played everything flawlessly when I tried it.

I was considering that, it would be pretty simple to add a controller flag however I was hoping to not add more complexity if possible.

[tonysawford]

Fair enough 

[Scobie]

I think this affects me too using a Cambridge CXR120, which I believe uses the same streaming module as the CXN.

I reported this in a separate thread where I've noticed recently that I get a small blast of white noise in between tracks. I wasn't sure where this crept in but it could line up with the release dates referenced in this thread. I have not tested actual gapless recordings but it seems like it is almost forcing a gap in between tracks. Will have to listen to Abbey Rd tonight..!

I see Bob's change has been implemented in the .94 release (I am running .92) , will see if this sorts this issue.

Cheers

[bob]

I'll be interested in hearing back form you both.

[tonysawford]

Is the new build available yet, and if so where?

[Awesome Donkey]

The latest public build is 25.0.93, 25.0.94 is in beta testing. Once 25.0.94 or higher goes public, the place to look for it would be the top of this forum section in the release topic: https://yabb.jriver.com/interact/index.php/board,60.0.html

[tonysawford]

Right; I’ve been keeping an eye on that board. I’ll grab 25.0.94 (or greater) as soon as it’s available and give it a try.

[Awesome Donkey]

Well, you're in luck, it just went live!

https://yabb.jriver.com/interact/index.php/topic,121927.0.html

[tonysawford]

Huzzah! 

[tonysawford]

I'll be interested in hearing back form you both.

I've just installed 25.0.94, and I'm sorry to say that I'm still getting a pause of something like 0.25s between tracks.

[Matt]

I've just installed 25.0.94, and I'm sorry to say that I'm still getting a pause of something like 0.25s between tracks.

Could you send a log to bob at jriver?

Thanks!

[tonysawford]

@bob

Here's the log, but I'm not sure whether it will be much use because what I've discovered is that when logging is off, playback is gappy, but when logging is on, playback is gapless.

Is there possibly some code inside an "if (logging) { ... }" code block that should be outside it?

[bob]

@bob

Here's the log, but I'm not sure whether it will be much use because what I've discovered is that when logging is off, playback is gappy, but when logging is on, playback is gapless.

Is there possibly some code inside an "if (logging) { ... }" code block that should be outside it?

I'll look at the log to verify the track switch login in any case and let you know.

[Scobie]

Bob I now run MC on a Mac, so will need to wait for that release.

[bob]

Bob I now run MC on a Mac, so will need to wait for that release.

25.0.95 is up now.

[tonysawford]

I’ve just installed 25.0.95, and I’m delighted to report that I’m now getting gapless playback, even with logging turned off

[bob]

I’ve just installed 25.0.95, and I’m delighted to report that I’m now getting gapless playback, even with logging turned off

Yea!
Thanks for reporting back!

[Scobie]

Issue still present on my system with .95 and may even be a little worse - white noise blast a touch longer.

I’ll play with the controller settings and get some logs.

Thanks

[tonysawford]

I’ve just installed 25.0.95, and I’m delighted to report that I’m now getting gapless playback, even with logging turned off

Blast! It seems I spoke too soon...

I am still getting gaps in playback, but - unlike 25.0.94 - the logging setting doesn't make any difference.

I've attached a new log file to this post.

[bob]

Blast! It seems I spoke too soon...

I am still getting gaps in playback, but - unlike 25.0.94 - the logging setting doesn't make any difference.

I've attached a new log file to this post.

The first track is only 19 seconds long and the next track is sent 10 seconds into this track.
This gets into the noise of the buffer size and the time it takes for the renderer to respond to the next track sent and start buffering it up.
There will always be issues with short tracks and slow renderers or renderers that use large receive buffers, you can see that by the re-reading of the transport state at 19 seconds (19000 ms).
During the playback of the second track (307 seconds), the third track appears to have been sent properly at 287 seconds. I assume the 3rd track played back properly?

This is the pertinent info from your log:

Code: [Select]

68231906: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 4000, Duration 19000
68237875: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 10000, Duration 19000
68237906: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING, Sucessfully sent next track using SetNextAVTransportURI. Position 10000, Duration 19000
68243390: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 16000, Duration 19000
68243984: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 16000, Duration 19000
68244937: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 17000, Duration 19000
68245500: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 18000, Duration 19000
68246469: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 19000, Duration 19000
68246469: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING, we seem stuck, will refresh Transport State. Position 19000, Duration 19000
68247015: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Transport state appears stale, Refreshing DLNA device transport state
68247031: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is WAITING. Position 20531, Duration 19000
68248062: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING, We are controlling, there is an updated track, display it. Position 21563, Duration 19000
68252172: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 4000, Duration 307000
68258187: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 255000, Duration 307000
68263687: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 260000, Duration 307000
68269187: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 266000, Duration 307000
68274672: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 271000, Duration 307000
68280172: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 277000, Duration 307000
68285687: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 282000, Duration 307000
68291187: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 287000, Duration 307000
68291219: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING, Sucessfully sent next track using SetNextAVTransportURI. Position 287000, Duration 307000
68296703: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 293000, Duration 307000
68302187: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 298000, Duration 307000
68307734: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 304000, Duration 307000
68308281: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 305000, Duration 307000
68309250: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 306000, Duration 307000
68309812: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING Position 306000, Duration 307000
68310828: 772: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {CXNv2} Playback state is PLAYING, We are controlling, there is an updated track, display it. Position 307578, Duration 307000


[tonysawford]

OK, that probably wasn't the best example to use

However, having tried again with longer tracks (c. 5 min) I can confirm that I'm still getting the same effects that I reported earlier, namely that if logging is off, I get gaps in playback, but if logging is on, then playback is gapless.

I've attached another log file, but I doubt that it will tell you anything as, in this case, playback was gapless.

I have also tried reinstalling 25.0.80, and confirmed that I get gapless playback irrespective of the status of the logging flag.

[bob]

OK, that probably wasn't the best example to use

However, having tried again with longer tracks (c. 5 min) I can confirm that I'm still getting the same effects that I reported earlier, namely that if logging is off, I get gaps in playback, but if logging is on, then playback is gapless.

I've attached another log file, but I doubt that it will tell you anything as, in this case, playback was gapless.

I have also tried reinstalling 25.0.80, and confirmed that I get gapless playback irrespective of the status of the logging flag.

Seems pretty crazy that logging would have that affect but I'll look into it.

[tonysawford]

Indeed.

The only thing that I can think of is what I suggested earlier, namely that there's some code inside an "if (logging) { ... }" test that should be outside it. Or maybe the writing of log information has some effect on timing, but that seems unlikely.

[bob]

Indeed.

The only thing that I can think of is what I suggested earlier, namely that there's some code inside an "if (logging) { ... }" test that should be outside it. Or maybe the writing of log information has some effect on timing, but that seems unlikely.

Unfortunately the logging is basically atomic. There aren't any if (logging) { ... } tests.

[tonysawford]

In that case I'm all out of guesses

[bob]

One thing we thought of is that logging will keep your hard drive from sleeping/spinning down (if it's a spinner at any rate).
Is your drive a spinner? If so perhaps you can change the sleep time?

[tonysawford]

Yes, it is a spinning metal drive.

I've had a look at the settings, and the sleep time is set to 30 minutes, so I doubt that that's the problem.

[bob]

Yes, it is a spinning metal drive.

I've had a look at the settings, and the sleep time is set to 30 minutes, so I doubt that that's the problem.

I don't know if that means the drive will not spin down by itself though I suspect not.

[DJLegba]

Yes, it is a spinning metal drive.

I've had a look at the settings, and the sleep time is set to 30 minutes, so I doubt that that's the problem.

Easy enough to test. Turn off logging but do something to access the drive regularly while streaming to your DLNA device.

[tonysawford]

Indeed, I could do that, but it occurred to me after I wrote my previous reply that the drive that the log is written to is not the drive that holds the FLAC files.

[bob]

Indeed, I could do that, but it occurred to me after I wrote my previous reply that the drive that the log is written to is not the drive that holds the FLAC files.

That's quite interesting..

[tonysawford]

The FLAC drive is indeed spinning metal, but the log drive is an SSD.

[Matt]

The FLAC drive is indeed spinning metal, but the log drive is an SSD.

It would be interesting to put a few files on the SSD and see if you can still replicate the problem with that.

[tonysawford]

Ok, I’ll have a stab at doing that tomorrow.

[tonysawford]

OK, so I tried putting a few files on SSD, and when I did that playback was gapless, regardless of whether logging was on or not.

However, before anyone suggests it, moving all the files to SSD is not a viable option, since I currently have around 12TB of FLAC files in this particular library...

[AndrewFG]

Did you try setting your anti virus software to ignore files of type .FLAC?

[tonysawford]

Good suggestion, but doing that has had no effect - I’m still getting gaps between tracks.

[Matt]

What if you play from the spinner, but do something like save a file in Notepad every minute to keep it spinning?

It seems like it's just spinning down and is slow to get going again.