MinimServer Forum

Full Version: A full function linux control point?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9
(07-10-2014 16:57)Pastim Wrote: [ -> ]A more difficult problem is one I've been trying to work out with simoncn. As I understand it minimsever presents 'containers' that contain potentially several ways to get at the same tracks (via different tags), and even links to whole albums containing other tracks as well. If I choose such a container in upplay I get loads of duplicate tracks and several I don't want. simoncn told me most control points do this but do not need to. I believe what they should do is just request the container once, rather than inspect its contents and send several separate requests.

The solution isn't quite a simple as this. The same track can show up in what appear to be different containers. It's possible to try to identify it as a duplicate using various criteria such as artist, album, title and duration, but this must be done at the per-track level rather than the per-container level.

A better solution is to send a single UPnP Search request for all audio items in the container and all its subcontainers. MinimServer will ensure that no duplicates are returned in the results of this search.

Please post any questions regarding this here rather than sending them by PM. Thanks!
Oops, sorry, but thanks for the clarification.
(07-10-2014 16:57)Pastim Wrote: [ -> ]Very good!

On one renderer (and I'll try the other later tonight):

- it starts even if the renderer is off and asks me which to use. I can cancel, wait for the renderer to start and then change device. Perfect.
- volume control works
- sequential tracks play
- windows can be resized (really useful!)
- but I can't change position within a track - I don't do this very often except when testing sequential tracks

Ok, needless to say, this is renderer-dependant, it now works will all I tried. I need to get an idea of what goes wrong with yours. Could you please run upplay as follows (from a terminal):

UPPLAY_LOGLEVEL=6 upplay > /tmp/upptrace 2>&1

Then play a track, try your position change, and quite or ^C the command, then send me the log: jf at dockes .org

You need to be relatively quick, the log grows quite fast...

(07-10-2014 16:57)Pastim Wrote: [ -> ]A more difficult problem is one I've been trying to work out with simoncn. As I understand it minimsever presents 'containers' that contain potentially several ways to get at the same tracks (via different tags), and even links to whole albums containing other tracks as well. If I choose such a container in upplay I get loads of duplicate tracks and several I don't want. simoncn told me most control points do this but do not need to. I believe what they should do is just request the container once, rather than inspect its contents and send several separate requests.

I don't know if the above makes sense, but maybe you could pm simoncn for details.

If this makes no sense (and I wouldn't be surprised since I've bashed my head against the wall about it for some time), ask, and I'll try to give a really clear example of what I mean.

It's very close to being very usable indeed for me on 14.04. Smile

Currently, upplay checks that it visits a container (identified by objid) at most once, to make sure that it's not walking a loop, but it does not try to de-dup the tracks.

I guess that it would be quite possible to eliminate the dups by objid or url at the end of the walk. Simoncn, any thought about this ? I saw the suggestion to use search, and why not, but this is really dependant on the type of Media Server (some don't support search at all or are horribly slow to the point of triggering timeouts).

jf
(07-10-2014 18:41)medoc92 Wrote: [ -> ]Currently, upplay checks that it visits a container (identified by objid) at most once, to make sure that it's not walking a loop, but it does not try to de-dup the tracks.

I guess that it would be quite possible to eliminate the dups by objid or url at the end of the walk. Simoncn, any thought about this ? I saw the suggestion to use search, and why not, but this is really dependant on the type of Media Server (some don't support search at all or are horribly slow to the point of triggering timeouts).

jf

MinimServer is very quick to respond to UPnP Search requests. This should be quicker than recursive browsing. Could this be enabled by a user option?

MinimServer uses different object IDs and container IDs when the same object or container is accessed using different browsing paths, so it isn't possible to use these to detect duplicates. The resource URI is always the same whatever path is used, so you could use this to detect and remove duplicate tracks.
(07-10-2014 19:32)simoncn Wrote: [ -> ]
(07-10-2014 18:41)medoc92 Wrote: [ -> ]Currently, upplay checks that it visits a container (identified by objid) at most once, to make sure that it's not walking a loop, but it does not try to de-dup the tracks.

I guess that it would be quite possible to eliminate the dups by objid or url at the end of the walk. Simoncn, any thought about this ? I saw the suggestion to use search, and why not, but this is really dependant on the type of Media Server (some don't support search at all or are horribly slow to the point of triggering timeouts).

jf

MinimServer is very quick to respond to UPnP Search requests. This should be quicker than recursive browsing. Could this be enabled by a user option?

MinimServer uses different object IDs and container IDs when the same object or container is accessed using different browsing paths, so it isn't possible to use these to detect duplicates. The resource URI is always the same whatever path is used, so you could use this to detect and remove duplicate tracks.

Yes, I can add an option to use search instead of a recursive walk, I am putting this on the todo.

This is actually the more complicated approach, because it needs to depend on the server type, I'm not even sure the current lib fully supports search, and there is not even an options panel at the moment ...

De-duplication by uri hash should hopefully be the quick and dirty solution.

But you got me a bit worried. Are the Minim Server trees always walkable ?
(07-10-2014 19:52)medoc92 Wrote: [ -> ]De-duplication by uri hash should hopefully be the quick and dirty solution.

This should be fine.

Quote:But you got me a bit worried. Are the Minim Server trees always walkable ?

They are always walkable but you are likely to get a huge number of duplicates depending on how high you are in the tree and the complexity of the user's tagging. Because of this, it would be better to check every track for a duplicate URI while you are doing the walk rather than doing this after the walk has finished.
(07-10-2014 20:00)simoncn Wrote: [ -> ]
(07-10-2014 19:52)medoc92 Wrote: [ -> ]De-duplication by uri hash should hopefully be the quick and dirty solution.

This should be fine.

Quote:But you got me a bit worried. Are the Minim Server trees always walkable ?

They are always walkable but you are likely to get a huge number of duplicates depending on how high you are in the tree and the complexity of the user's tagging. Because of this, it would be better to check every track for a duplicate URI while you are doing the walk rather than doing this after the walk has finished.

Ok. thanks.
(07-10-2014 18:41)medoc92 Wrote: [ -> ]Ok, needless to say, this is renderer-dependant, it now works will all I tried. I need to get an idea of what goes wrong with yours. Could you please run upplay as follows (from a terminal):

UPPLAY_LOGLEVEL=6 upplay > /tmp/upptrace 2>&1

Then play a track, try your position change, and quite or ^C the command, then send me the log: jf at dockes .org

You need to be relatively quick, the log grows quite fast...
Sent.
(07-10-2014 20:42)Pastim Wrote: [ -> ]
(07-10-2014 18:41)medoc92 Wrote: [ -> ]Ok, needless to say, this is renderer-dependant, it now works will all I tried. I need to get an idea of what goes wrong with yours. Could you please run upplay as follows (from a terminal):

UPPLAY_LOGLEVEL=6 upplay > /tmp/upptrace 2>&1

Then play a track, try your position change, and quite or ^C the command, then send me the log: jf at dockes .org

You need to be relatively quick, the log grows quite fast...
Sent.
And my other renderer has the same problem.
(07-10-2014 15:59)medoc92 Wrote: [ -> ]On the networking issue, (simoncn), unfortunately, and unexpectedly, I was unable to reproduce the problem. The message you see occurs when upplay tries to download the description document from the server or renderer, the first phase works normally (the devices are discovered), so this can't be a "stupid" networking issue.

The new version has improved error messages, at least printing the URL which we are trying to download, so this might help.

The message is:
libupnpp/control/discovery.cxx:228::discoExplorer:UpnpDownloadUrlItem :-204: UPNP_E_SOCKET_CONNECT trying to fetch http://192.168.0.14:9050/webdav/TwonkyWebdavServerDescription.xml

I don't think this is the reason why my Linn renderer and MinimServer servers can't be discovered.

Quote: Also it is possible to print a much more verbose log by starting it as:

UPPLAY_LOGLEVEL=5 upplay

If you could do this up to the point where it does not find the devices, then kill it and send the log to me (jf at dockes .org), maybe I'll be able to see something. This is really weird.

Cheers,

jf

Done.
Pages: 1 2 3 4 5 6 7 8 9
Reference URL's