INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Cover Art for documents  (Read 1303 times)

lise

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 946
Cover Art for documents
« on: May 14, 2012, 09:05:46 am »

At this point this discussion requires it's own thread.  The previous thread is here: http://yabb.jriver.com/interact/index.php?topic=70938.msg487259#msg487259


Honestly we haven't thought a lot about cover art for data files.

Sidecar images seem the better choice to me.

I suppose I could live with that, but could there be a way to count images that have the same name as a file as some type of special file that can be ignored during an import?

You can use an import rule to tag the cover art images as cover art, and then exclude them from your normal views.

Here's the problem with that solution.

My method with docs is to put all new docs into a ToImport folder.
Then when I have time, I import all those docs (right-click, MC, import) and do the tagging.

- If I add the cover art at this point, the jpg doesn't get tagged.  I certainly don't feel like repeating every step I just did and retagging yet again.

- If I add the cover art after the tagged files have been moved to their appropriate folders, then that's not so bad--I will just have a bunch of untagged jpgs in my folders. A noodle when viewing folders with Windows Explorer, but not the end of the world I suppose.

The major problem is when I do a major import of all docs which I do once in a while to see which files I may have missed.

At this point, I'm going to have a whole lot of jpegs being imported. Theoretically I could just select them all and remove them from my database. Except that I actually do have jpgs in my folders that are NOT cover art. How could I tell MC to make the distinction?  For this reason I cannot set up an import rule that tags jpgs as cover art.  And the result is I have to go through my entire database and compare the filenames of all those imported jpgs with filenames in my database. Not likely to happen as this is WAY too much work.

So the only way this could work is if MC's import function somehow ignored jpg files that were named the same as a doc file in the database. That is the only way for me to import actual jpgs that are not cover art.

If that could be done, then I would have no issue with jpgs being along side the docs (I think).

But for now the immediate problem is that those jpgs are not moved with the files.
I'm hoping this is a bug and not the way it's going to work in the future.


Logged
A wise man once said don't count your years, but make your years count. Or was it beers?

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42323
  • Shoes gone again!
Re: Cover Art for documents
« Reply #1 on: May 14, 2012, 11:16:55 am »

So the only way this could work is if MC's import function somehow ignored jpg files that were named the same as a doc file in the database. That is the only way for me to import actual jpgs that are not cover art.

If that could be done, then I would have no issue with jpgs being along side the docs (I think).

I think we need to do this for video and data.  When we first talked about this it got a little complicated because some users like to import those sidecar images.

Improving this is still on the list of good intentions.



Quote
But for now the immediate problem is that those jpgs are not moved with the files.
I'm hoping this is a bug and not the way it's going to work in the future.

It's an oversight.  I'll change it for next build:
Changed: When moving a data file with a sidecar image, the sidecar image will move along with the data file.
Logged
Matt Ashland, JRiver Media Center

lise

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 946
Re: Cover Art for documents
« Reply #2 on: May 14, 2012, 11:26:14 am »


It's an oversight.  I'll change it for next build:
Changed: When moving a data file with a sidecar image, the sidecar image will move along with the data file.

Great. Thanks Matt.
Logged
A wise man once said don't count your years, but make your years count. Or was it beers?

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Cover Art for documents
« Reply #3 on: May 14, 2012, 11:57:32 pm »

So the only way this could work is if MC's import function somehow ignored jpg files that were named the same as a doc file in the database. That is the only way for me to import actual jpgs that are not cover art.

You know MC well enough this must be a plea to be proven wrong. ;D

Here's a solution using global variables. I don't include documents with covers in my library, but it's not difficult to find an analogous situation. The following is my 'Library View' which includes all items in the library, regardless of the media type or database. In this view, I've selected a folder of movies for which there is cover art and some fan art in addition to the video files. The key elements of the view are...

  • The subject folder and media types are selected in the panes.

  • For video files, an expression column determines the standard cover art filename and saves it as a global variable for that filename root:
         If(IsEqual([Media Type], Video),
         Save(RemoveRight([Filename], 4).jpg, VideoCover-RemoveRight([Filename], 4), 1),
          )


  • Another expression column compares the saved cover art filename to [Filename] to determine if the file is cover art:
         If(IsEqual([Filename], Load(VideoCover-RemoveRight([Filename], 4))), Yes, )

  • A pane is added for selecting video, covers and/or fan art:
         IfElse(
         IsEqual([Media Type], Video), Video,
         IsEqual([Filename], Load(VideoCover-RemoveRight([Filename], 4))), Cover,
         1, Fan Art)

This is just an illustration. If used, it should probably treat filename extensions in a more robust fashion. And I find global variables a bit baffling, so I won't be surprised if someone says there's a better way, or that there would be performance problems doing this in a large library. :-\
Logged
Pages: [1]   Go Up