Support for Folder.jpg

Anonymous
2010-02-17
2013-05-30

  • Anonymous
    2010-02-17

    I don't like adding album art to individual files mostly because it's redundant to have the cover stored in every single track belonging to an album.  Instead I prefer to have a Folder.jpg in each directory containing an album.  This has many benefits: it's not redundant, I can edit the image without extracting it, it doesn't depend on the format of the tracks (wma, mp3/4, flac), I don't need specialized software, etc.

    Yesterday, I implemented Folder.jpg support for mediatomb.  Right now it works but it's a nasty hack: I modified the Taglib handler to look for an Folder.jpg if no embedded album art is present.  For me this works because I have only mp3s and flacs.  But in the correct solution Folder.jpg logic should be independent of the various metadata handlers it should rather be a metadata handler of its own.  The current code runs only one of the available handlers on each file on import.  Would it make sense to have chains of handlers that are applied to files one after another?

    This would also solve another problem that I have:  Since the taglib handler extracts only basic information from flacs but not composer, conductor, or compilation tags, I use the shell_based_extractor.patch to get this extra information.  Ideally I'd like to run a chain, where first taglib extracts basic metadata and media attributes (sample rate, bits, length, …), then the shell_extractor retrieves additional metadata, and finally a Folder.jpg handler adds album art if available.

    I think I have a rough idea how to do this for importing files.  But what about the situation when a renderer requests the album art?  How can we decide which resource is delivered (serveContent()) by which handler?

    Any thoughts about how to do this properly?

      Titus

     
  • Jin
    Jin
    2010-02-17

    Well, I do plan to rewrite the metadata handling part to allow chaining metadata handlers, those chains would be defined in config.xml

    This should also allow to compile MediaTomb with all libraries at once, even being redundant (i.e. id3lib and taglib) and decide what handler will be taken on runtime.

    Adding additional "plugin handler" or some "shell/script" handler interface should not be too difficult once I have that.

    Regarding your question:
    the content handler types are defined in metadata_handler.h
    #define CH_DEFAULT   0
    #define CH_LIBEXIF   1
    #define CH_ID3       2
    #define CH_TRANSCODE 3
    #define CH_EXTURL    4
    #define CH_MP4       5
    #define CH_FFTH      6

    The file request handler calls the createHandler method of the metadata class in order to get the correct sreveContent instance. The createHandler method identifies the handler by the above number which is added to the URL in the UPnP browse XML.

    So, request comes in, you check if it is for the original resource or not, if not, you check the handler type, if you can identify it - you serve the appropriate content.

    Kind regards,
    Jin

     

  • Anonymous
    2010-02-17

    Re chains: This sounds great!  And thanks for your explanation!

    Thanks for your work on Mediatomb!

    Best,
      Titus