GNOME Bugzilla – Bug 743812
CDDB result from FreeDB is cropped
Last modified: 2015-02-11 11:57:58 UTC
Created attachment 295893 [details] Screenshot showing cropped output for track 10 When obtaining CDDB results from FreeDB using the "search by selected songs" feature it happens very often that 1 or 2 lines are cropped. I have verified this by visting the FreeDB homepage and searching for the same entry on there and it is correct in the database. This happens with a lot of discs, I would say about 30-60%. One disc I had this happen with is "No.1 Hits (disc 1)". See the attached screenshot for what EasyTag outputs. Have a look at the entry for track 10. Now compare with the raw output from FreeDB: http://www.freedb.org/freedb/newage/0c0e3612 The EasyTag version used to create the screenshot was compiled from git, revision 2703196a5c7446c0873aa71bdd3d26428ed53296. Please let me know if you need additional information.
After a bit of investigation, it seems that this is because freeDB returns the HTTP result with "Transfer-Encoding: chunked", which EasyTAG does not know how to handle. https://en.wikipedia.org/wiki/Chunked_transfer_encoding For longer results, more than one chunk is used, and the chunk length for the second chunk (which often falls in the middle of a result line) confuses the result parser and leads to the truncated result. Rather than constructing the HTTP requests and processing the raw responses, as EasyTAG does right now, it should use a library such as libsoup, which has the added benefit of a GObject API (and asynchronous methods). I do not have much time to work on this at the moment, as the CDDB code is rather fragile.
Created attachment 296576 [details] [review] use HTTP/1.0 to avoid chunked transfer encoding How about we simply use HTTP/1.0 to retrieve the track list? This older HTTP version does not have chunked transfer encoding. My tests have shown no problems so far. However, just to be sure, I avoided changing all the other requests to HTTP/1.0 in case there are some HTTP/1.1 features they rely on.
Review of attachment 296576 [details] [review]: The patch did not apply, so I rewrote it as pushed it to master and easytag-2-2 branches as e3f197aae814354925b3528260efbdb4115e657e and 9aca7e1609e055aa787558b32f2ab1586535d53b. Thanks!