View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010521 | MMW v4 | DLNA/UPnP | public | 2013-02-13 17:01 | 2013-03-09 23:51 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0010521: "Play to" should be able to show why the file cannot be played | ||||
| Description | Currently if anyone select an external player (right-click Player -> Choose Player) then if a file cannot be played, it is skipped without reporting the real reason. The main reasons that should be reported (if happens) are: 1. MM server is not running 2. MM is configured to not share content with this device 3. The player is no longer active (was turned off) | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=70055&sid=ce641863ae052d5f6b96337c549976ee YEU-321624 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1626 | ||||
|
|
Assigned to Rusty and set up priority to immediate because of introducing new strings. |
|
|
1) Can you clarify re. when this error can occur? Do you mean that if UPnP sharing is disabled that Play To functionality is disabled? If so, shouldn't MM either: a) instantiate a server if Play to is enabled? b) warn the user when disabling UPnP Sharing, if 'Play to' is enabled? 2) I'm not clear on this issue either. i.e. if the user has elected to play to 'Device A', then shouldn't the settings re. sharing/not sharing content with 'Device A' be ignored? i.e. afaik Sharing permissions shouldn't apply to 'play to'. 3) "The '<xxx>' player turned off or inaccessible." |
|
|
1) Play to is always enabled, whenever user configures an UPnP/DLNA renderer via Options|Player|Choose Player or via right-click on player -> Choose player then the selected player persists and whenever a song is played, it is played to the configured player. It is not a problem when a song is played from another server to the player (via Media Servers -> <Server> node), but if a library track is played to the remote player then MMW needs to create URI and serve the local library file as URI to the remote player. In this case MMW server needs to be running. 2) I agree that in case of Play to the security settings should be ignored for that particular device/player. It is problem though that we often cannot be sure that the URI request is request based on the "play to". Therefore I would suggest to accept all requests from particular MAC address of the device to which a file is about to be played. |
|
|
1) I guess that I'm assuming that in most cases, at least some of the content _will_ be local, and so it's safe to assume that the UPnP server should be activated. Possible approach discussed, is to prompt the user when activating Play to: Playing local content to '<player>' requires a UPnP/DLNA server to be active. Enable UPnP/DLNA Server: '<server name>' ? [Options] [Yes] [No] This dialog can be used upon configuration of Play to, AND, when a local track is attempted to be played remotely but the UPnP/DLNA server is inactive. 2) TBD--I'm not sure if you're suggesting that permissions for access to the entire library be granted to the destination Play to device. That would almost certainly not be expected by the user. It would be more reasonable that the destination player is able to _Play_ any content from the local player, but permissions to browse/access content that isn't initiated from the local player shouldn't be granted (i.e. permissions on the UPnP/DLNA dialog shouldn't change). |
|
|
Re: 1) As discussed over IM, alternative (and preferable) approach (without user interaction) would be to use the default server when is running, but if no server is running, then run a hidden server just for the "Play to" purpose. 2) Agreed |
|
|
Fixed in build 1626. |
|
|
1) 'Play to' when MM UPnP servers are all disabled works when initiated after restarting mm. But if MM is configured with one UPnP server, and a config change is make, then 'Play to' doesn't work unless MM is restarted. Test methodology: 1 clean install of MM with default server enabled 2 play to Bubble UPnP renderer 3 disable default server 4 play to Bubble UPnP renderer --> playback doesn't work 5 switch default server back on 6 play to Bubble UPnP renderer --> playback doesn't work 7 Restart MM 8 play to Bubble UPnP render --> playback works 2) I'm not sure if this is fixed--I suspect that 0010584 is related to this. 3) At step 3 above, if I initiate playback on MMW, no error message appear in MMW re. unavailability of the renderer. 4) Play to functionality |
|
|
1) I cannot replicate, tested with clean 1626 portable install. I cannot test with Bubble UPnP renderer, because it acts very unstable on my network, it is not visible as renderer most of the time and often just play one song and then is no longer responding (the same experience with WMP's "Play to" feature - so it is not MM issue). But with all others tested renderers (WMP, XBMC, foobar) it works fine. i.e. Once I disable the default server in Options and then double-click a song, the hidden server is created and song is successfuly played. Could you re-test also with another renderer (e.g. WMP, XBMC, foobar) to see if you can still replicate or it is related only to Bubble UPnP renderer? If you can repro, generate debug log please. 2) Will be fixed in 1627, details here: 0010584:0035204 3) It is not about server unavailability, but about renderer unavailability. Server is supposed to be always running, but if you turn off the renderer, then MMW shows that it has turned off or inaccessible, there is 10 seconds timeout before showing the error message. 4) What do you mean by this? |
|
|
1) I can't seem to replicate this, but I wonder if it might be related to 0010591. Consider this fixed and I'll reverify once 0010591 is fixed. 3) Sorry--my explanation was incorrect; I meant turn off the renderer at step 3. Regardless--the problem was that I didn't wait long enough for the error message. i.e. there's no functional bug. BUT, the string doesn't display correctly: It should show: "The '<xxx>' player is turned off or inaccessible." instead of: "The <xxx> player turned off or inaccessible." i.e. single quotes around the renderer name, + the addition of _is_ |
|
|
1) OK 2) is fixed as 0010584 in 1627 3) the wording corrected in 1627 |
|
|
Verified 1627 |
