Topic: Audio Files over DLNA play twice [Solved] (Read 12307 times)

GaryM44 · « **on:** March 16, 2012, 01:58:39 pm »

Why do files sent to a DLNA device (Sony blu-ray player) from a playlist play twice?

When playing starts, the first file in the list is highlighted. When it finishes the next file begins playing immediately, but the "Now Playing" pane at the top of the window continues to show the first file, which is still highlighted, even though it is counting down the file actually playing. When that second file finishes, the highlight moves down to the 2nd file and the title in the upper pane changes, and the second file plays again. When it finishes, the 3rd file starts, but as before, the 2nd file remains highlighted and the 2nd title remains in the "Now Playing" pane. Continues in that fashion 'til the end of the list, all files except the first playing twice.

There is also a loud POP after every file when playing to the blu-ray. Neither of these behaviors occurs when the files are sent with WMP instead.

Any ideas?

brossmac · « **Reply #1 on:** March 17, 2012, 05:27:11 pm »

I have the same problem playing to my Sony Blu-ray player as well. It only started after a recent update....

bob · « **Reply #2 on:** March 20, 2012, 09:56:33 am »

I assume you guys are pushing media to the Blu-Ray player? (BTW, what Models do you have).

Can one of you install the developer tools for uPNP http://opentools.homeip.net/dev-tools-for-upnp and see if your blu-ray player has the function SetNextAVTransportURI under AVTransport?

EDIT: I forgot to add that you need to run "device spy" from the tools to see the device characteristics.

AndrewFG · « **Reply #3 on:** March 21, 2012, 10:23:39 am »

Quote from: bob on March 20, 2012, 09:56:33 am

Can one of you install the developer tools for uPNP http://opentools.homeip.net/dev-tools-for-upnp and see if your blu-ray player has the function SetNextAVTransportURI under AVTransport?

Hi Bob,

It might not be the SetNextAVTransportURI function that is causing the problem (that was my first reaction too). Perhaps your new logic for playing the next track is getting its knickers in a twist (in some cases) even where SetNextAVTransportURI is not implemented.

The OP mentions something odd appearing on MC's "Now Playing" pane, so perhaps your new implementation of GetMediaInfo and/or GetPositionInfo, are no longer returnin the proper now playing information. Could it be that you call SetAVTransportURI to play the next track, check GetMediaInfo to confirm the now playing value, and if the answer is wrong, perhaps you call SetAVTransportURI again? Perhaps you need to wait a bit longer before calling GetMediaInfo. Just a thought...

bob · « **Reply #4 on:** March 22, 2012, 09:22:20 am »

Quote from: AndrewFG on March 21, 2012, 10:23:39 am

Hi Bob,

It might not be the SetNextAVTransportURI function that is causing the problem (that was my first reaction too). Perhaps your new logic for playing the next track is getting its knickers in a twist (in some cases) even where SetNextAVTransportURI is not implemented.

The OP mentions something odd appearing on MC's "Now Playing" pane, so perhaps your new implementation of GetMediaInfo and/or GetPositionInfo, are no longer returnin the proper now playing information. Could it be that you call SetAVTransportURI to play the next track, check GetMediaInfo to confirm the now playing value, and if the answer is wrong, perhaps you call SetAVTransportURI again? Perhaps you need to wait a bit longer before calling GetMediaInfo. Just a thought...

I haven't changed the next track logic except for the SetNextAV... call. If it fails, it's not called again. The GetMediaInfo is only used when the SetNextAV.. call is working.
We will be changing the conventional next track logic but I didn't want to break anything that was already working.

I did find a broken renderer implementation that causes behavior similar to what's described here. The Sony SNM-M100 media player we have here recently got a firmware update that enabled DMR (it was previously a DMP only). Unfortunately the SetNextAV.. logic is broken. Once you push a track to it with SetAV.. then push the next one with SetNextAV... GetMediaInfo looks fine but when it starts playing the second track, it doesn't update GetMediaInfo resulting in the second track playing twice.

I'm probably going to have to implement something to disable the use of SetNextAV... as an advanced option for broken renderers.

AndrewFG · « **Reply #5 on:** March 22, 2012, 09:59:41 am »

Quote from: bob on March 22, 2012, 09:22:20 am

Unfortunately the SetNextAV.. logic is broken. Once you push a track to it with SetAV.. then push the next one with SetNextAV... GetMediaInfo looks fine but when it starts playing the second track, it doesn't update GetMediaInfo resulting in the second track playing twice.

You say that GetMediaInfo does not update on the second track. Just a thought, (I did not think it completely through), but can't you use GetPositionInfo instead of GetMediaInfo to detect the track change? I assume that GetPositionInfo is more likely to be implemented properly, because this action is much more commonly used by CPs.

Quote from: bob on March 22, 2012, 09:22:20 am

I'm probably going to have to implement something to disable the use of SetNextAV... as an advanced option for broken renderers.

Don't you just love UPnP ?

bob · « **Reply #6 on:** March 22, 2012, 10:51:05 am »

Quote from: AndrewFG on March 22, 2012, 09:59:41 am

You say that GetMediaInfo does not update on the second track. Just a thought, (I did not think it completely through), but can't you use GetPositionInfo instead of GetMediaInfo to detect the track change? I assume that GetPositionInfo is more likely to be implemented properly, because this action is much more commonly used by CPs.

It gets pretty dicey at the end of track with some renderers, long transition states, inaccurate reporting of position info on VBR tracks, weirdness when seeking nearly to the end of a track, etc.
Probably more reliable overall to add a disable switch and when the renderers firmware is updated the user can try it again.

Quote

Don't you just love UPnP ?

Perhaps the least thought through protocol ever?

bob · « **Reply #7 on:** March 22, 2012, 04:52:03 pm »

I did re-work the logic today to eliminate the GetMediaInfo call and got the Sony working (it still works with Whitebear too). It'll be in the next build.
Also added a controller option to disable SetNext.... as well for real basket cases...

AndrewFG · « **Reply #8 on:** March 23, 2012, 08:40:45 am »

Quote from: bob on March 22, 2012, 04:52:03 pm

I did re-work the logic today to eliminate the GetMediaInfo call and got the Sony working (it still works with Whitebear too). It'll be in the next build.
Also added a controller option to disable SetNext.... as well for real basket cases...

Glad you fixed it. (I was beginning to feel bad that I was the one who got you into this trouble in the first place...)

bob · « **Reply #9 on:** March 23, 2012, 09:19:24 am »

Quote from: AndrewFG on March 23, 2012, 08:40:45 am

Glad you fixed it. (I was beginning to feel bad that I was the one who got you into this trouble in the first place...)

It's really OK, it was good having something to test against. The only renderers that work perfectly gaplessly are MC and Whitebear (ones that I have access to anyway). Seems like the hardware vendors still have some work to do. The Sony media player and TV we have do the logic properly but wait too long to request the next file and so there is still a small gap between the music.

AndrewFG · « **Reply #10 on:** March 23, 2012, 01:30:01 pm »

Quote from: bob on March 23, 2012, 09:19:24 am

The only renderers that work perfectly gaplessly are MC and Whitebear (ones that I have access to anyway). Seems like the hardware vendors still have some work to do. The Sony media player and TV we have do the logic properly but wait too long to request the next file and so there is still a small gap between the music.

To do gapless, obviously the player must start downloading the next track into cache whilst the current track is still playing. I suppose the hardware players are not running world class multi-thread o/s so cannot really do two things in parallel. And/or they don't have enough memory for caching tracks either.

bob · « **Reply #11 on:** March 23, 2012, 02:28:03 pm »

Quote from: AndrewFG on March 23, 2012, 01:30:01 pm

To do gapless, obviously the player must start downloading the next track into cache whilst the current track is still playing. I suppose the hardware players are not running world class multi-thread o/s so cannot really do two things in parallel. And/or they don't have enough memory for caching tracks either.

You mean those toothbrush class arm processors aren't enough

I'm pretty sure most of these things are running an embedded uclinux so you'd think they'd be able to handle it. It's interesting that the TV does a head request on the next file as soon as it gets the SetNext... and that looks good but it waits until the current track has ended before requesting the next. It's probably more difficult to pull a second file while the first is playing without closing the audio device. A lot of these devices appear to be using VLC or Mplayer to render the files...

bob · « **Reply #12 on:** March 23, 2012, 03:00:02 pm »

Hey Andrew,

I saw you posted about Kinsky in their forum and pointed out that it's not working with seek on Whitebear. I'm thinking this may be because they are passing the bitrate wrong. They are sending KILObytes/Sec instead of bytes/sec. (so for example, it says 192 for a bitrate). If you get a chance you might want to let them know...

AndrewFG · « **Reply #13 on:** March 25, 2012, 10:04:16 am »

Quote from: bob on March 23, 2012, 03:00:02 pm

Hey Andrew,

I saw you posted about Kinsky in their forum and pointed out that it's not working with seek on Whitebear. I'm thinking this may be because they are passing the bitrate wrong. They are sending KILObytes/Sec instead of bytes/sec. (so for example, it says 192 for a bitrate). If you get a chance you might want to let them know...

Actually, for some reason, the Seek() seems now to be working fine.

However I posted a bug report anyway concerning their bad res element parameters http://forums.linn.co.uk/bb/showthread.php?tid=16190

By the way, whilst playing with Kinsky, I found and fixed a couple more bugs in Whitebear's Play To functionality:

1) If one passed an albumArtURI containing URL escaped characters (as Kinsky does) the artwork would not appear on the Squeeze player UI. Now fixed.

2) If one passed an AVTransportURI where the url document name did not have a file tye extension (e.g. http://xyz/track), it would show as type "Unk" on the Squeeze player UI. Now Whitebear also checks the url query parameters for a file type extension (e.g. http://xyz/kinsky?file=track.mp3), and also guesses a file type if the server provides a Content-Type header.

3) In the DLNA eventing mechanism "LastChange", Whitebear was never sending name/value pairs in cases where the respective state variable's value was an empty string. Now fixed.

PS Whitebear still works fine with MC build 112 !!

AndrewFG · « **Reply #14 on:** March 28, 2012, 03:05:38 pm »

Quote from: bob on March 23, 2012, 03:00:02 pm

Hey Andrew,

I saw you posted about Kinsky in their forum and pointed out that it's not working with seek on Whitebear. I'm thinking this may be because they are passing the bitrate wrong. They are sending KILObytes/Sec instead of bytes/sec. (so for example, it says 192 for a bitrate). If you get a chance you might want to let them know...

Apparently this is fixed now. See http://forums.linn.co.uk/bb/showthread.php?tid=16190

adnut · « **Reply #15 on:** May 04, 2016, 04:58:33 pm »

I am having the same problem with audio files (both flac and mp3) playing twice as reported here years ago:

http://yabb.jriver.com/interact/index.php?topic=70889.0

I am using MC 21 to stream to a Harman/Kardon Onyx wireless speaker as my DLNA renderer device. In addition, the beginning of each track gets chopped off (about <1 second). It also causes random 2-5 seconds interruptions while a track is playing.

I followed instructions on the prior thread I linked above, and tried the "Disable SetNext" feature for this renderer. Although "disabling SetNext" fixes the playing twice issue, beginning of each track still skips, and random 2-5 seconds interruptions occur while a track is playing.

I downloaded and ran the UPnP dev tools from "http://opentools.homeip.net", and here is the output showing that SetNextAVTransportURI is implemented by Harman Kardon Onyx device.

Action name   SetNextAVTransportURI
Argument 1   (ui4) InstanceID
Argument 1 ASV   A_ARG_TYPE_InstanceID
Argument 2   (string) NextURI
Argument 2 ASV   NextAVTransportURI
Argument 3   (string) NextURIMetaData
Argument 3 ASV   NextAVTransportURIMetaData
Return argument   <none>

What do you recommend for fixing this problem? Any way I can gather some data for further troubleshooting?

Note: Using the Bluetooth works fine. But I'd rather use Wifi connection because my wireless network setup has wider reach than Bluetooth.

Thanks,
Max

AndrewFG · « **Reply #16 on:** May 09, 2016, 12:18:17 am »

Please download the DMRA from my sig, and post the renderer report here.

adnut · « **Reply #17 on:** May 12, 2016, 01:19:51 am »

Thanks. Here it is:

Device Description Url   http://192.168.1.45:8080/description.xml
Description   HK Onyx
Friendly Name   HK Onyx WF
Manufacturer Name   Harman Kardon
Manufacturer Url   http://www.harmankardon.com/
Model Name   HK Onyx
Model Number   03
Model Url   http://www.harmankardon.com/
Presentation Url   http://192.168.1.45
UPnP Device Type   urn:schemas-upnp-org:device:MediaRenderer:1
UPnP Media Renderer version   1
Unique Device Name   uuid:5f9ec1b3-ed59-1900-4530-e8c74f03c72a
Unique Product Code   123810928305
X_DLNADOC Element   DMR-1.50
Service Url for RenderingControl   http://192.168.1.45:8080/RenderingControl/desc.xml
Service Url for ConnectionManager   http://192.168.1.45:8080/ConnectionManager/desc.xml
Service Url for AVTransport   http://192.168.1.45:8080/AVTransport/desc.xml
AVT:GetDeviceCapabilities action   Supported
AVT:GetMediaInfo action   Supported
AVT:GetPositionInfo action   Supported
AVT:GetTransportInfo action   Supported
AVT:GetTransportSettings action   Supported
AVT:SetNextAVTransportURI (gapless play)   Supported
AVT:SyncPlay (synchronous play)   NOT Supported
RC:GetVolume action   Supported
RC:SetVolume action   Supported
AVT:Event Subscription   Succeeded
RC:Event Subscription   Succeeded
HTTP User Agent (client)   WinampMPEG/2.8
Play test file result   Play success => Start Ok / Stop Ok

---

Media types that renderer can play:

audio/L16   LPCM   Dlna   44100   1   16   Yes
audio/L16   LPCM   Dlna   44100   2   16   Yes
audio/L16   LPCM   Dlna   48000   1   16   Yes
audio/L16   LPCM   Dlna   48000   2   16   Yes
audio/mpeg   MP3   Dlna   *   2   *   No
audio/x-ms-wma   WMABASE   Dlna   *   2   *   No
audio/x-ms-wma   WMAFULL   Dlna   *   2   *   No
audio/vnd.dlna.adts   AAC_ADTS   Dlna   *   2   *   No
audio/vnd.dlna.adts   AAC_ADTS_320   Dlna   *   2   *   No
audio/mp4   AAC_ISO   Dlna   *   2   *   No
audio/3gpp   AAC_ISO   Dlna   *   2   *   No
audio/mp4   AAC_ISO_320   Dlna   *   2   *   No
audio/3gpp   AAC_ISO_320   Dlna   *   2   *   No

---

MC Server Settings:

DLNA Checked Checked
DLNAExtra Checked Checked
Enable bitrate Field Checked Checked
Filter international characters Off Off
Include session ID Off Off
Playstation 3 Compatible Off Off
Present Caption Resources Checked Off
Present Small Artwork Off Off
Present Subtitle Resources Checked Off
Skip Child Count Off Off
Use Flat URLs Off Off
Use Full URLs Off Off
WMC Compatible Off Off

Disable SetNext support Off Checked
Ignore DLNA Transport Events Off Off

Please let me know if I can provide any additional data.

Thanks!

AndrewFG · « **Reply #18 on:** May 12, 2016, 12:42:54 pm »

^

There are no errors to see in the report.

If disabling SetNext support in MC fixes the double playing issue, then so be it, I can't argue with that.

The dropouts are therefore either due to disk latency issues (possibly caused by a NAS, or by your AV software), or network bandwidth issues, or performance issues on the server running MC. What media format are you trying to play? Break down the testing by starting with a minimally complex play scenario, and then work up to more complex scenarios until the dropouts reappear. Start by setting MC to play in Original format, and push a simple low bandwidth MP3 track, and if that works you can progress to higher bandwidth formats, and/or adding transcoding, or DSP etc.

adnut · « **Reply #19 on:** May 12, 2016, 10:51:47 pm »

Meanwhile Harman/Kardon support suggested I also check into WiFi Channels, and the network traffic like you suggested.

Trying different WiFi channels worked! Now I have much more stable WiFi connectivity to H/K Onyx. It was surprising to find out that I have too many WiFi signals around the house, all from my neighbors. Also there are wireless phones that operate around the same frequency. I used an app to monitor various networks, signal strength and their channel use. I will keep this in mind if I have issues in the future.

What is puzzling is that I have an Oppo BDP105 player located at a longer distance, and separated by many more walls and a floor than where I use H/K Onyx, and Oppo works great. Not a single drop. Might be also the wireless hardware and SW stack on these devices that make a difference.

Thanks for checking into this issue, I think I am settled and solved it. I like your SW by the way; it gives lots of useful info for discovery and fine tuning with these devices.

JimH · « **Reply #20 on:** May 13, 2016, 07:23:04 am »

Well done, Harman/Kardon support. Thanks for reporting the solution.

INTERACT FORUM

Author Topic: Audio Files over DLNA play twice [Solved] (Read 12307 times)