[libdmapsharing] Fix bug that caused two MLIT's to be sent when responding to "/1/items" Signed-off-by: W. Michael Pe



commit 84462a25fcabb96d0ce013b57f01cb05af09cd6a
Author: W. Michael Petullo <mike flyn org>
Date:   Mon Nov 22 23:32:26 2010 -0600

    Fix bug that caused two MLIT's to be sent when responding to "/1/items"
    Signed-off-by: W. Michael Petullo <mike flyn org>

 README-Memory               |   13 +++++++++++++
 libdmapsharing/dmap-share.c |   18 +++++++-----------
 2 files changed, 20 insertions(+), 11 deletions(-)
---
diff --git a/README-Memory b/README-Memory
index 2474eb8..6729e98 100644
--- a/README-Memory
+++ b/README-Memory
@@ -80,3 +80,16 @@ chunks, avoiding the need to build the entire response in memory.
 	that thumbnails are especially problematic). The GHashTable-based
 	database used 35,885,056 bytes of heap space. The disk-based
 	database used 4,763,648 bytes.
+
+8. Decompressing multiple scan JPEG's.
+
+	VIPS must decompress multiple scan JPEG's fully in memory due
+	to the way libjpeg works. Either 1) use embedded EXIF thumbnail
+	or 2) skip. Currently adding the following to VIPS im_jpeg2vips.c
+	to skip:
+
+	Right below jpeg_start_decompress:
+	if (jpeg_had_multiple_scans(cinfo)) {
+		printf ("MULTISCAN, SKIPPING\n");
+		return -1;
+	}
diff --git a/libdmapsharing/dmap-share.c b/libdmapsharing/dmap-share.c
index ed2842e..084af56 100644
--- a/libdmapsharing/dmap-share.c
+++ b/libdmapsharing/dmap-share.c
@@ -1728,13 +1728,6 @@ _dmap_share_databases (DMAPShare *share,
 		map = DMAP_SHARE_GET_CLASS (share)->get_meta_data_map (share);
 		mb.bits = _dmap_share_parse_meta (query, map);
 
-		adbs = dmap_structure_add (NULL, DMAP_CC_ADBS);
-		dmap_structure_add (adbs, DMAP_CC_MSTT, (gint32) DMAP_STATUS_OK);
-		dmap_structure_add (adbs, DMAP_CC_MUTY, 0);
-		dmap_structure_add (adbs, DMAP_CC_MTCO, (gint32) num_songs);
-		dmap_structure_add (adbs, DMAP_CC_MRCO, (gint32) num_songs);
-		mb.mlcl = dmap_structure_add (adbs, DMAP_CC_MLCL); // Was shared with else before
-
 		/* NOTE:
 		 * We previously simply called foreach...add_entry_to_mlcl and later serialized the entire
 		 * structure. This has the disadvantage that the entire response must be in memory before
@@ -1747,7 +1740,6 @@ _dmap_share_databases (DMAPShare *share,
 		 * 3. Setup libsoup response headers, etc.
 		 * 4. Setup callback to transmit DAAP preamble (write_dmap_preamble)
 		 * 5. Setup callback to transmit MLIT's (write_next_mlit)
-		 *    NOTE: write_next_mlit uses some tricks to iterate through all record ID's
 		 */
 
 		/* 1: */
@@ -1775,18 +1767,22 @@ _dmap_share_databases (DMAPShare *share,
 		}
 
 		/* 2: */
+		adbs = dmap_structure_add (NULL, DMAP_CC_ADBS);
+		dmap_structure_add (adbs, DMAP_CC_MSTT, (gint32) DMAP_STATUS_OK);
+		dmap_structure_add (adbs, DMAP_CC_MUTY, 0);
+		dmap_structure_add (adbs, DMAP_CC_MTCO, (gint32) num_songs);
+		dmap_structure_add (adbs, DMAP_CC_MRCO, (gint32) num_songs);
 		mb.mlcl = dmap_structure_add (adbs, DMAP_CC_MLCL);
 		dmap_structure_increase_by_predicted_size (adbs, size);
 		dmap_structure_increase_by_predicted_size (mb.mlcl, size);
 
 		/* 3: */
-		soup_message_set_status (message, SOUP_STATUS_OK);
-		soup_message_headers_set_content_length (message->response_headers, dmap_structure_get_size(adbs));
 		/* Free memory after each chunk sent out over network. */
 		soup_message_body_set_accumulate (message->response_body, FALSE);
-
 		soup_message_headers_append (message->response_headers, "Content-Type", "application/x-dmap-tagged");
 		DMAP_SHARE_GET_CLASS (share)->message_add_standard_headers (share, message);
+		soup_message_headers_set_content_length (message->response_headers, dmap_structure_get_size(adbs));
+		soup_message_set_status (message, SOUP_STATUS_OK);
 
 		/* 4: */
 		g_signal_connect (message, "wrote_headers", G_CALLBACK (write_dmap_preamble), adbs);



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]