INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: Patrick8639 on August 19, 2019, 03:19:11 am
-
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.
-
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
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
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.
-
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.
-
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.
-
Fair enough :)
-
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
-
I'll be interested in hearing back form you both.
-
Is the new build available yet, and if so where?
-
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
-
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.
-
Well, you're in luck, it just went live!
https://yabb.jriver.com/interact/index.php/topic,121927.0.html
-
Huzzah! :)
-
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.
-
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!
-
@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
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.
-
Bob I now run MC on a Mac, so will need to wait for that release.
-
Bob I now run MC on a Mac, so will need to wait for that release.
25.0.95 is up now.
-
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 :)
-
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!
-
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
-
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.
-
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:
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
-
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.
-
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.
-
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.
-
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.
-
In that case I'm all out of guesses :)
-
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?
-
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.
-
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.
-
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.
-
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.
-
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..
-
The FLAC drive is indeed spinning metal, but the log drive is an SSD.
-
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.
-
Ok, I’ll have a stab at doing that tomorrow.
-
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... :)
-
Did you try setting your anti virus software to ignore files of type .FLAC?
-
Good suggestion, but doing that has had no effect - I’m still getting gaps between tracks.
-
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.
-
I'm really not convinced that that's the problem - the drive definitely does not spin down that quickly.
Also, remember that I don't get this behaviour with 25.0.80, which uses a different strategy for calling SetNextAVTransportURI
-
The SetNextAVTransportURI was changed again recently, so maybe try the latest build?
https://yabb.jriver.com/interact/index.php/topic,121944.0.html
-
Thanks Matt. Is there an ETA on the Linux build?
-
Thanks Matt. Is there an ETA on the Linux build?
We'll probably have one out today. Working on some cloudplay stuff.
Still I think it really is that the drive is spinning down. It makes sense since the old version sent the track right after the current one started playing.
-
I've been following this thread because I am having the same DLNA gapless problem that Tony has described. However my library resides on my laptop (Windows 10), along with JRiver. I use MC DLNA to send tracks from my laptop to my Yamaha AVR (RX-A3040), and gapless has worked great for the past 5 years until I upgraded to release 25.0.89. I mentioned my problems with that release in another thread https://yabb.jriver.com/interact/index.php/topic,121743.msg842392.html#msg842392
I didn't want to interfere with Tony's thread, since it looked like the problem was being addressed. However I believe the "spinning drive" theory is incorrect, since everything resides on my laptop, so my drive doesn't "spin down". I believe the problem must be elsewhere.
I've commented on this today only because I will be out of town the next 2 weeks and I'd hate to see this problem dropped while I'm gone because a spinning drive is the suspected culprit for the person reporting the problem.
Like Tony, I've installed 25.0.80 on my laptop until this issue is resolved.
-
The SetNextAVTransportURI was changed again recently, so maybe try the latest build?
https://yabb.jriver.com/interact/index.php/topic,121944.0.html
Sorry, @Matt - I didn't get a notification of your reply, so I've only just seen it.
I am already using the latest build (25.0.95).
-
I've been following this thread because I am having the same DLNA gapless problem that Tony has described. However my library resides on my laptop (Windows 10), along with JRiver. I use MC DLNA to send tracks from my laptop to my Yamaha AVR (RX-A3040), and gapless has worked great for the past 5 years until I upgraded to release 25.0.89. I mentioned my problems with that release in another thread https://yabb.jriver.com/interact/index.php/topic,121743.msg842392.html#msg842392
I didn't want to interfere with Tony's thread, since it looked like the problem was being addressed. However I believe the "spinning drive" theory is incorrect, since everything resides on my laptop, so my drive doesn't "spin down". I believe the problem must be elsewhere.
I've commented on this today only because I will be out of town the next 2 weeks and I'd hate to see this problem dropped while I'm gone because a spinning drive is the suspected culprit for the person reporting the problem.
Like Tony, I've installed 25.0.80 on my laptop until this issue is resolved.
You have tried 25.0.96 and still have the issue?
From the message you linked I see you disabled SetNext support. SetNext support is necessary for gapless playback.
If you are still having issues with version >=25.0.96 and SetNext enabled, please turn on logging (just before you start playback) and stop logging (just after an error) sending us the log. Thanks!
-
I just installed 25.0.96, and I don't get any playback.
When I try to play a track to the CXNv2, its display *briefly* (< 0.5s) shows the artwork and track details, and then it immediately goes to pause or stop mode. Moreover, the MC UI became completely unresponsive, and I had to kill it using task manager.
I've attached a log file, but I fear that it may have been truncated because I had to kill the MC process.
I've now reverted to 25.0.95
-
I just installed 25.0.96 ...
Strange.
It's not clear what's going on for you.
The Log only shows some USB storage devices being enumerated, nothing else.
-
I suspect that there should be much more in the log, but it got lost when I had to terminate the process with extreme prejudice - it probably didn’t get closed properly, which meant that buffers didn’t get flushed to disk.
-
Unlikely.
If you have USB devices attached, try unplugging them.
-
The drives with all the FLAC files on them are USB3 devices, so I can’t unplug them.
The MC host machine is an Intel NUC, so there’s nowhere to put internal drives other than the system boot SSD.
-
You have tried 25.0.96 and still have the issue?
From the message you linked I see you disabled SetNext support. SetNext support is necessary for gapless playback.
If you are still having issues with version >=25.0.96 and SetNext enabled, please turn on logging (just before you start playback) and stop logging (just after an error) sending us the log. Thanks!
Yes I understand that SetNext support is necessary for gapless playback. In that other thread, someone suggested disabling it to see if it fixed the track skipping problem in that release.
Since then, I've installed releases 92 through 95 (with SetNext enabled, ie unchecked) and have had the same problems Tony reported. Each time I reinstalled release 80, so that I can use the gapless function.
Tonight I installed release 96 and found that no tracks play at all. Instead I get 2 popups stating:
"There was a problem controlling the selected DLNA device. Double-check your device, server, and network settings."
"Something went wrong with playback."
Hopefully the problem was captured in the attached log file.
One other thing I've noticed is that the releases that I've been having problems with have a new DLNA Controller Option - Disable Other Controller Detection, which wasn't in release 80 (the last release that I've used that didn't have any gapless problems). Could it be that this new option is somehow causing the gapless problem?
As I mentioned in my previous post, starting tomorrow I will be out of town for 2 weeks and won't be able to do any installs or testing of new releases until I return.
-
I've just installed 25.0.98, and the (lack of) playback problem that I reported in 25.0.96 seems to be fixed.
Moreover, it also seems (fingers crossed!) that - with the exception of short tracks - I'm now getting gapless playback, irrespective of the logging state. I'll monitor the situation and report back if I notice any other odd behaviour.
-
Alas, it appears that I spoke too soon again...
I’m still getting gappy playback, albeit not as badly as with 25.0.95. It seems to be a bit random whether it happens or not; sometimes an album plays gaplessly, and other times not.
-
@bob
I returned from my trip today and installed 25.0.98 on my laptop. I played 2 albums that I've previously had gapless problems with.
First I listened to Pink Floyd's Dark Side of the Moon album with logging turned off. The first 7 tracks played fine, but then there was a pause and "static" between tracks 7 (Any Colour You Like) and 8 (Brain Damage). After the static, the beginning of Brain Damage was skipped and it started playing normally after that. After track 8, playback was stopped and track 9 (Eclipse) was never played.
Next I turned on logging and played the Beatles Abbey Road. This time tracks 1-12 played fine, then there was a pause and static between tracks 12 (Polythene Pam) and 13 (She Came in Through the Bathroom Window). Again the beginning of track 13 was skipped and playback continued. This happened again with tracks 14 (Golden Slumbers) and 15 (Carry That Weight). Playback stopped after track 15, and track 16 (The End) never started.
I'm guessing that the "static" is the AVR skipping over the beginning of the song.
I've attached the log file from the Abbey Road session. I hope you can find some clue in this file.
-
Are all the tracks within each album the same bitrate and sample rate? 44.1/16, for example?
-
The flac files are all 44.1/16. If it helps, I've attached a screenshot of the file attributes from MC.
-
After my last post, I noticed that the Last Played timestamp was out of order, even though the songs were displayed (and played) in track order. I've never noticed this before today. Maybe this is another clue to help find the issue. I've added the track # to the attached screenshot and also highlighted the Last Played timestamps that are out of order.
-
The first 7 tracks played fine, but then there was a pause and "static" between tracks 7 (Any Colour You Like) and 8 (Brain Damage). After the static, the beginning of Brain Damage was skipped and it started playing normally after that. After track 8, playback was stopped and track 9 (Eclipse) was never played.
This sounds a lot like an issue I have reported previously as well, a burst of static (I described it as White Noise) between tracks. Not all the time but sometimes, and sometimes gapless works sometimes not. It will also happen on non-gapless files.
Been in the last 3 months or so, and is specific to my Cambridge CXR120 that had previously worked without issue (and still does except for this problem).
Been meaning to get some logs, will try on the weekend.
Edit: Looks like the DLNA timing changes in .101 might have solved this. Early days but so far so good. Gapless certainly working much better too.
-
We've been supporting gapless playback to DLNA renderers that can handle it via SetNextAVTransportURI since before foobar existed.
It's not widely supported on renderers but the ones that do it properly work well.
-
Just an update. Since I installed release 101 (and later 102) I haven't noticed any of the problems that I reported earlier in this thread. Thanks for fix!
-
We've been supporting gapless playback to DLNA renderers that can handle it via SetNextAVTransportURI since before foobar existed.
What date are you claiming gapless dlna was supported in j river?
-
For an exact date.
February 2012
-
For an exact date.February 2012
That's interesting, but not useful. Useful is a list of devices known to - correctly, everytime, all-the-time - support gapless play over dlna. Do you have this?
-
No. You'd need to ask the manufacturer of the device. Many of them test with JRiver and we'll provide licenses to manufacturers who need them for testing.
-
That's interesting, but not useful. Useful is a list of devices known to - correctly, everytime, all-the-time - support gapless play over dlna. Do you have this?
No. ... Many of them test with JRiver and we'll provide licenses to manufacturers who need them for testing.
No you don't have a list? Do you have a list of manufacturers that test with jr? That should be yes, especially given
It's not widely supported on renderers but the ones that do it properly work well.
this would be useful.
...You'd need to ask the manufacturer of the device.
Oh, come on! This is nuts. Just say what devices are known to work. Why can't you do that? Why won't you do that? Here's hoping this won't get deleted before it gets into google.
-
I'm sorry, but we don't keep such a list.
Who is your manufacturer?
Model?
-
DSD files over a PSAudio Bridge and DS DAC also don't play gappless (3 seconds before the end of each track there's a gap), setnext etc. is selected.
It's a mess.
-
It's a mess.
Just for the record: the “mess”, if any, is certainly not the fault of MC..
In UPNP / DLNA the Control Point (e.g. MC) sends two messages to the renderer: namely
1) SetAVTransportURI tells the renderer the url (link) of the track to play first
2) SetNextAVTransportURI tells the renderer the url of the track to play next
If the renderer is not capable of playing two given urls sequentially, then that is solely the fault of the renderer.