chiark / gitweb /
Documentation + comments re recent disorder-playrtp changes.
[disorder] / server / state.c
index 1c1e2aa1f68ee06e45dab445e5e3edc334ae1bab..e10a2302044be5e6d88d443d7ed62549655f1f12 100644 (file)
@@ -159,10 +159,8 @@ int reconfigure(ev_source *ev, int reload) {
   }
   if(reload) {
     /* If there's a rescan in progress, cancel it but remember to start a fresh
-     * one after the reload */
+     * one after the reload. */
     need_another_rescan = trackdb_rescan_cancel();
-    /* Close the track database */
-    trackdb_close();
     /* (Re-)read the configuration */
     if(config_read(1/*server*/, config))
       ret = -1;
@@ -171,12 +169,7 @@ int reconfigure(ev_source *ev, int reload) {
       speaker_reload();
       info("%s: installed new configuration", configfile);
     }
-    /* Re-open track database.  We don't attempt to support database version
-     * upgrade at this point - the software hasn't changed, after all. */
-    trackdb_open(TRACKDB_NO_UPGRADE);
-  } else
-    /* We only allow for upgrade at startup */
-    trackdb_open(TRACKDB_CAN_UPGRADE);
+  }
   /* New audio API */
   api = uaudio_find(config->api);
   if(api->configure)
@@ -186,35 +179,10 @@ int reconfigure(ev_source *ev, int reload) {
   /* If we interrupted a rescan of all the tracks, start a new one */
   if(need_another_rescan)
     trackdb_rescan(ev, 1/*check*/, 0, 0);
-  /* Arrange timeouts for schedule actions */
-  schedule_init(ev);
-  /* TODO what about leftover callbacks from before the reload? */
   if(!ret) {
-    /* Read the queue back in */
-    queue_read();
-    recent_read();
     /* Reset sockets */
     reset_socket(ev);
   }
-  /* TODO we need a careful think about what you can and cannot change with a
-   * reload.
-   *
-   * For instance saving and restoring the queue limits what we can usefuly
-   * keep in the queue data structure.  As a general rule, long-term state
-   * ought to be off-limits.  So 'home directory' will have to stay where it
-   * is.  (This actually means the AF_UNIX socket will never be re-opened.)
-   *
-   * Players certainly ought to be reconfigurable but this raises the ugly
-   * question of what to do about already-started background decoders.
-   *
-   * The audio API is easy to do for the server but a pain for the speaker.
-   *
-   * These two points suggest a general approach: if things that affect the
-   * speaker change, we could just restart it and any extant background
-   * decoders, at the next track change.  This would generate a bit of a gap
-   * but presumably reconfiguration is a rare event so this might be
-   * acceptable.
-   */
   return ret;
 }