|
a/src/upmpd.cxx |
|
b/src/upmpd.cxx |
|
... |
|
... |
| 52 |
using namespace std::placeholders;
|
52 |
using namespace std::placeholders;
|
| 53 |
using namespace UPnPP;
|
53 |
using namespace UPnPP;
|
| 54 |
|
54 |
|
| 55 |
// Note: if we ever need this to work without cxx11, there is this:
|
55 |
// Note: if we ever need this to work without cxx11, there is this:
|
| 56 |
// http://www.tutok.sk/fastgl/callback.html
|
56 |
// http://www.tutok.sk/fastgl/callback.html
|
| 57 |
//
|
|
|
| 58 |
// Note that there is a problem in the order in which we do things
|
|
|
| 59 |
// here: because the UpnpDevice() constructor starts the
|
|
|
| 60 |
// advertisements and publishes the description document before the
|
|
|
| 61 |
// services are actually initialized, it is possible that a fast
|
|
|
| 62 |
// client will fail in subscribing to events, which will manifest
|
|
|
| 63 |
// itself on the server side by error messages like the following in
|
|
|
| 64 |
// the log:
|
|
|
| 65 |
// libupnpp/device/device.cxx:183::UpnpDevice: Bad serviceID:
|
|
|
| 66 |
// urn:upnp-org:serviceId:ConnectionManager
|
|
|
| 67 |
// The solution would be to have a separate init call to start the
|
|
|
| 68 |
// device at the end of the constructor code.
|
|
|
| 69 |
UpMpd::UpMpd(const string& deviceid, const string& friendlyname,
|
57 |
UpMpd::UpMpd(const string& deviceid, const string& friendlyname,
|
| 70 |
const unordered_map<string, VDirContent>& files,
|
58 |
const unordered_map<string, VDirContent>& files,
|
| 71 |
MPDCli *mpdcli, Options opts)
|
59 |
MPDCli *mpdcli, Options opts)
|
| 72 |
: UpnpDevice(deviceid, files), m_mpdcli(mpdcli), m_mpds(0),
|
60 |
: UpnpDevice(deviceid, files), m_mpdcli(mpdcli), m_mpds(0),
|
| 73 |
m_options(opts.options),
|
61 |
m_options(opts.options),
|