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 22:18)simoncn Wrote: [ -> ]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.

Apparently it was the reason. I stopped this Twonky service and discovery now works. It seems that a single bad UPnP device can block discovery for all other devices. This has never happened with any other UPnP control point that I've used.
I'm now seeing the following messages:

libupnpp/upnpplib.cxx:104::LibUPnP: Using IP 192.168.0.41 port 49152
connections done
libupnpp/control/mediarenderer.cxx:129::MediaRenderer::ohpl: OHPlaylist service not found
libupnpp/control/avtransport.cxx:199::AVTransport event: unknown variable: name [CurrentMediaCategory] value [NO_MEDIA
libupnpp/control/avtransport.cxx:199::AVTransport event: unknown variable: name [PossiblePlaybackStorageMedia] value [NETWORK
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:199::AVTransport event: unknown variable: name [PossibleRecordStorageMedia] value [NOT_IMPLEMENTED
CDBrowser::serversPage: waiting 3
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
....(repeats forever)
(07-10-2014 22:28)simoncn Wrote: [ -> ]
(07-10-2014 22:18)simoncn Wrote: [ -> ]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.

Apparently it was the reason. I stopped this Twonky service and discovery now works. It seems that a single bad UPnP device can block discovery for all other devices. This has never happened with any other UPnP control point that I've used.

Your previous post kind of made the assumption that the logic in my code was correct. This was rather bold Smile

There is obviously a bug in there, I think that I should have enough data now to fix it. Thanks !
(07-10-2014 22:31)simoncn Wrote: [ -> ]I'm now seeing the following messages:

These are mostly debug, I don't think that they have consequences

(07-10-2014 22:31)simoncn Wrote: [ -> ]libupnpp/upnpplib.cxx:104::LibUPnP: Using IP 192.168.0.41 port 49152
connections done
libupnpp/control/mediarenderer.cxx:129::MediaRenderer::ohpl: OHPlaylist service not found
Not an OpenHome renderer, not an error.

(07-10-2014 22:31)simoncn Wrote: [ -> ]libupnpp/control/avtransport.cxx:199::AVTransport event: unknown variable: name [CurrentMediaCategory] value [NO_MEDIA
libupnpp/control/avtransport.cxx:199::AVTransport event: unknown variable: name [PossiblePlaybackStorageMedia] value [NETWORK
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:199::AVTransport event: unknown variable: name [PossibleRecordStorageMedia] value [NOT_IMPLEMENTED
CDBrowser::serversPage: waiting 3
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
libupnpp/control/avtransport.cxx:69::AVTransport event: bad value for TransportState: NO_MEDIA_PRESENT
....(repeats forever)

These are due to typos in literal values in the code, I fixed them, thanks. I don't think that there are consequences (maybe the TransportState one could mess with the player controls).
(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.
Hi,

Did you receive the email? If not I could attach the trace here.
(08-10-2014 15:52)Pastim Wrote: [ -> ]
(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.
Hi,

Did you receive the email? If not I could attach the trace here.
Yes, thanks, I did receive the email, and got distracted by other things, and forgot to answer, my apologies.

The problem lines are here:

libupnpp/control/service.cxx:98::Service::runAction: rqst: [<?xml version="1.0"?>
<u:Seek xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<Unit>REL_TIME</Unit>
<Target>0:05:12</Target>
</u:Seek>
]
libupnpp/control/service.cxx:106::Service::runAction: UpnpSendAction failed: 501

Code 501 normally means "Action failed", but I think that we can trust the error code to be meaningless, the problem is probably with the command used (REL_TIME), or the time format itself.

It's going to be a bit difficult to debug remotely, but I'll try to see what my reference control point (bubble...) sends for this, and do the same. I'll get back when I have a new version ready for trying.

Edit: Bubble uses the exact same format. What control point are you normally using with your devices ?
OK - thanks. Let me know if there's any other data I can get for you.
(08-10-2014 18:10)Pastim Wrote: [ -> ]OK - thanks. Let me know if there's any other data I can get for you.

I just edited the post above:
Edit: Bubble uses the exact same format. What control point are you normally using with your devices ?
I'm not using any CP very often. None of them really fit the bill on linux, which is why I am keen on upplay. foobar2000 with upnp plugin has several problems, although it can play tracks. Trying it again just now I can't get it to reposition in a track.

So I tried bubbleupnp on my android smartphone. This returns 'seek mode not supported', code 710. It therefore appears that my renderers may not support this under upnp.

This has confused me somewhat because I have a totally different way of driving these renderers just sending a flac stream (rather than getting them to play individual tracks that they know about) and that does allow me to reposition. This is the mode I have been using most of the time since the linux control points have thus far been so poor. I suppose with the stream capture mode of operation the server is doing all the work, whereas playing a known track the renderer is more closely involved.

So it looks as if I may have wasted your time on this issue, for which many apologies.
(08-10-2014 20:34)Pastim Wrote: [ -> ]I'm not using any CP very often. None of them really fit the bill on linux, which is why I am keen on upplay. foobar2000 with upnp plugin has several problems, although it can play tracks. Trying it again just now I can't get it to reposition in a track.

So I tried bubbleupnp on my android smartphone. This returns 'seek mode not supported', code 710. It therefore appears that my renderers may not support this under upnp.

This has confused me somewhat because I have a totally different way of driving these renderers just sending a flac stream (rather than getting them to play individual tracks that they know about) and that does allow me to reposition. This is the mode I have been using most of the time since the linux control points have thus far been so poor. I suppose with the stream capture mode of operation the server is doing all the work, whereas playing a known track the renderer is more closely involved.

So it looks as if I may have wasted your time on this issue, for which many apologies.

No worries, thanks for looking into it. I'm left with this small mystery of why bubble gets a 710 (which is the correct error), and I get a 510...
Pages: 1 2 3 4 5 6 7 8 9
Reference URL's