Newbee questions about functionality and renderers
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Newbee questions about functionality and renderers
I installed UMS only a few days ago (under windows 10) and have some newbee questions.
Question 1: When browsing the server, I can only see my folder structure. I thought a mediaserver was supposed to additionally give me access through the metadata in the files, e.g. by 'album', 'artist', 'genre' etc. Am I missing something here? I tried this with various 'client' packages: WMP, VLC, MediaMonkey, BubbleUPnP.
Question 2: UMS readily recognises several 'renderers' on my network, among which the Chromecast Audio, my preferred renderer. But I have no idea how to use this feature: how can I get UMS to 'play to' a renderer when using the client software? Or is that maybe not the idea?
Thanks a lot for any help!
Mabel
Question 1: When browsing the server, I can only see my folder structure. I thought a mediaserver was supposed to additionally give me access through the metadata in the files, e.g. by 'album', 'artist', 'genre' etc. Am I missing something here? I tried this with various 'client' packages: WMP, VLC, MediaMonkey, BubbleUPnP.
Question 2: UMS readily recognises several 'renderers' on my network, among which the Chromecast Audio, my preferred renderer. But I have no idea how to use this feature: how can I get UMS to 'play to' a renderer when using the client software? Or is that maybe not the idea?
Thanks a lot for any help!
Mabel
Re: Newbee questions about functionality and renderers
UMS will show your folder structure by default. It also has the ability to show the "media library" which has for a reason unknown to me been renamed to "cache". For the "cache" folder to appear, make sure that you have enabled "Enable the cache" and disabled "Hide the cache folder" under "Navigation/Share settings". Be warned though that the media library functionality has been unmaintained for several years so not everything works that well in there. The 7.0.0 version of UMS tries to "revive" the media library functionality and addresses many issues around that. But, the version isn't yet stable and currently has a number of issues, so it might or might not work well for you.
When it comes to Chromecast our support is problematic. We've had a developer that made support for it which has since left the project. The implementation is unstable at best, and needs some work. None of the current developers own a Chromecast and we are thus unable to troubleshoot it. I've long been saying that we should disable Chromecast support until it has been fixed, but that isn't done. The reason the Chromecast is so problematic is that it doesn't support UPnP or DLNA, which are the protocols used by UMS (and all other renderers used with UMS). Google didn't want to use UPnP or DLNA (I don't know their reasons, but it's a sad choice) and invented its own standard instead. This standard isn't documented in public, so support is only based on trial and error. For Android and the Chrome browser (which is all Google want people to use), support is built in.
UPnP/DLNA is built around a concept where the renderer browse and request media. Since the Chromecast doesn't have an UPnP/DLNA browser this isn't possible. That leaves only "remote control" as defined by UPnP. Some renderers can "remote control" other renderers. I think the most used solution is to use BubbleUPnP on Android to "send" files from UMS to the Chromecast. It is also possible to do this directly from UMS (by clicking on the renderer icon and using the new "window" that pops up) or UMS's web interface (by using the "bump" feature) but neither of these solutions are working properly under all scenarios. I don't know if it will work with a Chromecast at all, so BubbleUPnP might be your best option. That is also more practical as you can control the playback from a phone or a tablet.
When it comes to Chromecast our support is problematic. We've had a developer that made support for it which has since left the project. The implementation is unstable at best, and needs some work. None of the current developers own a Chromecast and we are thus unable to troubleshoot it. I've long been saying that we should disable Chromecast support until it has been fixed, but that isn't done. The reason the Chromecast is so problematic is that it doesn't support UPnP or DLNA, which are the protocols used by UMS (and all other renderers used with UMS). Google didn't want to use UPnP or DLNA (I don't know their reasons, but it's a sad choice) and invented its own standard instead. This standard isn't documented in public, so support is only based on trial and error. For Android and the Chrome browser (which is all Google want people to use), support is built in.
UPnP/DLNA is built around a concept where the renderer browse and request media. Since the Chromecast doesn't have an UPnP/DLNA browser this isn't possible. That leaves only "remote control" as defined by UPnP. Some renderers can "remote control" other renderers. I think the most used solution is to use BubbleUPnP on Android to "send" files from UMS to the Chromecast. It is also possible to do this directly from UMS (by clicking on the renderer icon and using the new "window" that pops up) or UMS's web interface (by using the "bump" feature) but neither of these solutions are working properly under all scenarios. I don't know if it will work with a Chromecast at all, so BubbleUPnP might be your best option. That is also more practical as you can control the playback from a phone or a tablet.
Re: Newbee questions about functionality and renderers
@Nadahar: Thanks for your anwers! It is very rare to get such a clear and informed answer!
I had indeed view of the 'cache' disabled; now it works! (Odd name, 'cache'; odd to disable it by default.) I am somewhat disappointed, though, that I can't search for 'composer'.
I think the Chromecast is a very good idea and am sad to learn it is so difficult to support. Indeed BubbleUPnP is what I now use on Android; VLC for windows (latest beta version) works as well. But I find both programs inadequate for browsing music. MediaMonkey for windows does a better job, but cannot 'cast'. Which is why I had a faint hope UMS might help me out. I am still far from an ideal, or even acceptable, solution for searching and playing my digital music, it seems.
BTW: reason for my late answer is that starting UMS I got the splash screen with the word 'loading' and nothing more. Only much later did I realise that UMS was already running and I had to find it's icon the taskbar.
Mabel
I had indeed view of the 'cache' disabled; now it works! (Odd name, 'cache'; odd to disable it by default.) I am somewhat disappointed, though, that I can't search for 'composer'.
I think the Chromecast is a very good idea and am sad to learn it is so difficult to support. Indeed BubbleUPnP is what I now use on Android; VLC for windows (latest beta version) works as well. But I find both programs inadequate for browsing music. MediaMonkey for windows does a better job, but cannot 'cast'. Which is why I had a faint hope UMS might help me out. I am still far from an ideal, or even acceptable, solution for searching and playing my digital music, it seems.
BTW: reason for my late answer is that starting UMS I got the splash screen with the word 'loading' and nothing more. Only much later did I realise that UMS was already running and I had to find it's icon the taskbar.
Mabel
Re: Newbee questions about functionality and renderers
It should probably be intuitive, but using the "X" on the UMS window won't close it, just minimize it to the system tray. You need to click the "quit" button on the GUI itself to actually quit. It's not uncommon to "servers" to work this way though, as you generally won't them to be availabe (from renderers for UMS) even if you have closed the configuration GUI.
As with most open source projects, development takes the direction picket by whoever is doing the development. A unified, well thought-through direction is rare and difficult to do unless the developers are paid. If "someone" decides that this and this should be done a certain way, but nobody are willing to actually implement it, it simply won't happen. As a result, choices are often incoherent and somewhat random. There has been strong views from some developers that the media library is an unwanted feature and that using folders (where users can organize the media as they wish) is better. I've argumented against this for a couple of years, saying that in addition to including a lot of manual work (to make that ideal structure) it only allows you to organize your media in one way. If you want to look them up with different criteria at different times, the folder based structure will never fit the bill. This was the situation when I joined the project though, and a lot of things aimed to "marginalize" the media library had already been done.
Those with the strongest feeling against the media library have since left the project, and the importance of a proper media library is again rising on the agenda. I believe that an important reason by the "hate" for the media library was the fact that making things work there is often more complicated and time consuming. Thus, for those that want "quick results" with little effort, it's very appealing to simply disregard it. We're now in a situation where there's a lot of catching up to do, as it's not only about renaming it and changing defaults, but also to find and correct all the bugs that's been created over the years because the media library has been disregarded by the developers.
Regarding the Chromecast I think it's a good idea only on the surface. If it were an "open", well documented device that anyone could write extensions too, it would be a good way to make "dumb" devices "smart". Although the advertisement tries to pretend that's what it is, that's not really the case. It is instead a "clever" attempt from Google to trap users into their ecosystem by selling them a cheap device that will only work by using the rest of their ecosystem. If Google wanted to, they could easily do this, but they have an ulterior motive which is about them making money from luring people into spending their money on their services. That makes the Chromecast much less attractive to me, and is why I don't own one myself.
As with most open source projects, development takes the direction picket by whoever is doing the development. A unified, well thought-through direction is rare and difficult to do unless the developers are paid. If "someone" decides that this and this should be done a certain way, but nobody are willing to actually implement it, it simply won't happen. As a result, choices are often incoherent and somewhat random. There has been strong views from some developers that the media library is an unwanted feature and that using folders (where users can organize the media as they wish) is better. I've argumented against this for a couple of years, saying that in addition to including a lot of manual work (to make that ideal structure) it only allows you to organize your media in one way. If you want to look them up with different criteria at different times, the folder based structure will never fit the bill. This was the situation when I joined the project though, and a lot of things aimed to "marginalize" the media library had already been done.
Those with the strongest feeling against the media library have since left the project, and the importance of a proper media library is again rising on the agenda. I believe that an important reason by the "hate" for the media library was the fact that making things work there is often more complicated and time consuming. Thus, for those that want "quick results" with little effort, it's very appealing to simply disregard it. We're now in a situation where there's a lot of catching up to do, as it's not only about renaming it and changing defaults, but also to find and correct all the bugs that's been created over the years because the media library has been disregarded by the developers.
Regarding the Chromecast I think it's a good idea only on the surface. If it were an "open", well documented device that anyone could write extensions too, it would be a good way to make "dumb" devices "smart". Although the advertisement tries to pretend that's what it is, that's not really the case. It is instead a "clever" attempt from Google to trap users into their ecosystem by selling them a cheap device that will only work by using the rest of their ecosystem. If Google wanted to, they could easily do this, but they have an ulterior motive which is about them making money from luring people into spending their money on their services. That makes the Chromecast much less attractive to me, and is why I don't own one myself.