uShare syslog priority

A standard uShare installation logs its 'business as usual' type messages to syslog with a facility of 'daemon' and a priority of 'notice'. My preference is for these type of messages to be logged with a priority of 'info', reserving priorities of 'notice' and above for logging out of the ordinary events.

Here's a simple patch for uShare 1.1a to fix this behaviour:

--- ushare-1.1a.orig/src/trace.c 2007-12-09 13:03:36.000000000 +0000
+++ ushare-1.1a/src/trace.c 2008-08-22 20:52:04.000000000 +0100
@@ -46,7 +46,7 @@
if (is_daemon)
{
int flags = LOG_DAEMON;
- flags |= level == ULOG_ERROR ? LOG_ERR : LOG_NOTICE;
+ flags |= level == ULOG_ERROR ? LOG_ERR : LOG_INFO;
vsyslog (flags, format, va);
}
else


LibUPnP-1.6.6 released

Version 1.6.6 of libupnp has been released. Here's my simultaneous streaming to multiple devices patch updated for this version:

--- libupnp-1.6.6.old/upnp/src/api/upnpapi.c    2007-11-27 04:56:02.000000000 +0000
+++ libupnp-1.6.6/upnp/src/api/upnpapi.c        2007-12-28 16:12:16.000000000 +0000
@@ -264,6 +264,8 @@
    return UPNP_E_INIT_FAILED;
}

+    TPAttrSetMinThreads( &attr, 4 );
+
if( ThreadPoolInit( &gMiniServerThreadPool, &attr ) != UPNP_E_SUCCESS ) {
    UpnpSdkInit = 0;
    UpnpFinish();

LibUPnP-1.6.5 released

Version 1.6.5 of libupnp has been released. Here's my simultaneous streaming to multiple devices patch updated for this version:

--- libupnp-1.6.5.old/upnp/src/api/upnpapi.c    2007-11-27 04:56:02.000000000 +0000
+++ libupnp-1.6.5/upnp/src/api/upnpapi.c        2007-12-28 16:12:16.000000000 +0000
@@ -264,6 +264,8 @@
    return UPNP_E_INIT_FAILED;
}

+    TPAttrSetMinThreads( &attr, 4 );
+
if( ThreadPoolInit( &gMiniServerThreadPool, &attr ) != UPNP_E_SUCCESS ) {
    UpnpSdkInit = 0;
    UpnpFinish();

Error in uShare 1.1 config file

uShare version 1.1 and above allows four new statements in the configuration file:

• USHARE_ENABLE_WEB
• USHARE_ENABLE_TELNET
• USHARE_ENABLE_DLNA
  
• USHARE_ENABLE_XBOX

However the "USHARE_" prefix of each of these is missing in the ushare.conf file contained in the tar.

Prefix these statements with "USHARE_" in your configuration file to get them to work correctly.

LibUPnP-1.6.4 released

Version 1.6.4 of libupnp has been released. Here's my simultaneous streaming to multiple devices patch updated for this version:

--- libupnp-1.6.4.old/upnp/src/api/upnpapi.c    2007-11-27 04:56:02.000000000 +0000
+++ libupnp-1.6.4/upnp/src/api/upnpapi.c        2007-12-28 16:12:16.000000000 +0000
@@ -264,6 +264,8 @@
        return UPNP_E_INIT_FAILED;
    }

+    TPAttrSetMinThreads( &attr, 4 );
+
    if( ThreadPoolInit( &gMiniServerThreadPool, &attr ) != UPNP_E_SUCCESS ) {
        UpnpSdkInit = 0;
        UpnpFinish();

Simultaneous streaming to multiple devices

I've been using uShare for some time now to stream audio and video content to a D-Link DSM-520. This setup has worked pretty well and so I decided to add a Pinnacle SoundBridge HomeMusic into the mix.

This introduced some problems. I couldn't stream to both the DSM-520 and the HomeMusic at the same time: whichever player began streaming first would work fine but the second player would be unable to see the uShare server. On top of this, I was unable to skip forward a track on the HomeMusic: it would just get stuck with the display showing 'buffering...', which seemed related to one problem I'd always had with the DSM-520 where I would be unable to navigate to a different branch of the content hierarchy while a file was already streaming.

After some trial and error I found that sending a SIGHUP to uShare somehow resolved all of these problems. Some further digging showed that the thread count for uShare increased from an inital seven to nine after the SIGHUP was processed. uShare makes extensive use of libupnp to provide the UPnP functionality so I compiled libupnp with the debug option enabled to try and establish what was happening after the SIGHUP that wasn't happening before.

The debug output showed that, after the SIGHUP and with a thread count of nine and a streaming request already in progress, the miniserver code within libupnp correctly executed the code to service a new request from a client device. With a streaming request in progress but with no SIGHUP and so a thread count of seven the libupnp miniserver failed to execute this code and so new requests were never serviced.

So I started to look at the libupnp code relating to threads. Three thread pools are initialised in the UpnpInit function, of which one is used by miniserver. Each thread pool has a minimum thread count of two, which correlated with the initial uShare thread count of seven: two for each pool plus one for uShare itself. A reasonable guess was that libupnp wasn't allocating sufficient threads in the miniserver thread pool to service new requests when a streaming request was in progress.

It was a simple matter to increase the minimum thread count for the miniserver pool in upnpinit from the initial two up to four. I then recompiled libupnp and the problems were all fixed: I could succesfully stream to two devices simultaneously and at the same time browse the content hierarchy.

Here is the patch for the UpnpInit code in libupnp-1.6.3:

--- libupnp-1.6.3.old/upnp/src/api/upnpapi.c    2007-11-27 04:56:02.000000000 +0000
+++ libupnp-1.6.3/upnp/src/api/upnpapi.c        2007-12-28 16:12:16.000000000 +0000
@@ -264,6 +264,8 @@
        return UPNP_E_INIT_FAILED;
    }

+    TPAttrSetMinThreads( &attr, 4 );
+
    if( ThreadPoolInit( &gMiniServerThreadPool, &attr ) != UPNP_E_SUCCESS ) {
        UpnpSdkInit = 0;
        UpnpFinish();