INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: 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?
-
I have the same problem playing to my Sony Blu-ray player as well. It only started after a recent update....
-
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 (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.
-
Can one of you install the developer tools for uPNP http://opentools.homeip.net/dev-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...
-
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.
-
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.
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 ?
-
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.
Don't you just love UPnP ?
Perhaps the least thought through protocol ever?
-
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...
-
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...)
-
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.
-
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.
-
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...
-
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...
-
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 !!
-
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
-
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
-
Please download the DMRA from my sig, and post the renderer report here.
-
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!
-
^
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.
-
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.
-
Well done, Harman/Kardon support. Thanks for reporting the solution.