Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mark Stega]

If you are using the new file location option "Next to file (folder.jpg)" and use the library tool "Rename files from properties" in such a way that you are changing the directory structure, the folder.jpg is left behind in the original directory.  You can use the "Move cover art to ..." plugin, but you have the directories to manually clean up.

[Matt]

If you are using the new file location option "Next to file (folder.jpg)" and use the library tool "Rename files from properties" in such a way that you are changing the directory structure, the folder.jpg is left behind in the original directory.  You can use the "Move cover art to ..." plugin, but you have the directories to manually clean up.

No new file moving features will be added to MC 11.0.

[Mark Stega]

I would posit that this is a bug introduced by the new file location option, but since I have a workaround (in the "Move cover art" plugin,  I'll not squawk too loudly.  Perhaps a later fix in a point release?

[ADDiCT]

Hi!
As i wrote in another thread (thanks for the answers there, btw!), i also regard this as a problem. Why add new functions to MC, and then leave them half-ready? Forcing users to manually move the files is not a perfect solution.

I have learned that there may be a workaround by importing the "Folder.jpg" files into the database, and tagging them. I regard this as what it is - a workaround to fix a non-perfect functionality. Using this workaround means additional work for the user.

[KingSparta]

i did write a program that scans the complete hard drive and then tells you what folders you have that are empty, you can then check the box in the list and delete the folders you want.

i am going to put it on my server, maybe this weekend when i have time to build a install program.

[ADDiCT]

Hey KingSparta,
thanks for this nice idea, but the problem here is different. What we have is an non-empty folder, as it contains (only) "Folder.jpg". Your program could be useful for deleting the empty dirs MC very often leaves behind when moving / renaming "normal" files (without a "Folder.jpg" stored next to the files), though...

[risingdamp]

This site has a simple and very effective little app for finding and deleting empty folders:
http://www.hugginsfam.com/dd/apps/

[ADDiCT]

Another issue with the "Folder.jpg"-functionality is that the "Folder.jpg" files that are left behind when moving / renaming file are actually imported into MC's database when importing media into the database.

I have played around with "Folder.jpg" files, and did an import afterwards - now i have 25+ image files with the Name-Tag "Folder" and an Album Tag reflecting the files creation date.

A general note: i am aware there are ways to delete empty directories, using tools or "handcraft". I am also aware i could import all my cover art into the library, and "manage" the files via MC.

What really bugs me is that this very nice and useful function simply is not really useable in it's current form. It seems that the "Cover-Art-Near-Files"-function has been added in a hurry, without regarding all the issues that could arise. And then seeing statements like "No new file moving features will be added to MC 11.0." makes me want to bite into my keyboard... 

[Alex B]

I have never liked the folder.jpg idea. In my opinion it is one of those not so great MS innovations. ASFAIK it was introduced with some version of WMP. It is just stupid to have thousands of identically named files on the HD without even having metafile tags. It is against what have learned about keeping the HDs organized. That is why I have always used and will use descriptive names for my cover art files.

I don think other SW players are any better at handling this issue. (Or are they?)

Personally I don't see this as a big problem. I am not usually moving albums after I have placed them correctly. When I move an album I can move the cover art separately if needed.

If the folder.jpg moving is introduced in the future the "mover" should be able to handle situations like these: not all music tracks are moved, the destination folder has a folder.jpg already, the same folder.jpg is associated with other library tracks, etc.

Currently it is possible to move folders including non-imported folder.jpg files in MC Tree > Drives & Devices using the Move Disk File or Find and Replace tools. The Rename From Properties tool can be used if the image file has the needed tags. Also, it is possible to drag & move whole folders in there.

However, this new cover art system is an unexpected gift from JRiver just before the launch. They did not promise anything. The users are free to continue using cover art as before.

EDIT

I have a growing number of other album related files besides the music files in the album folders: reviews, rip logs, several CD cover images, artist's images and bios files, etc. I import them all to MC and use MC for keeping them organized. When I don't want to see the other files I use the Audio mode.

[hit_ny]

Another issue with the "Folder.jpg"-functionality is that the "Folder.jpg" files that are left behind when moving / renaming file are actually imported into MC's database when importing media into the database.

I have never come across this issue as i just drag & drop folders wherever i want in the tree. Just like you would in explorer, cept its integrated into MC so MC knows where things are and *everything* pertaining to that folder is updated.

Waaaaay more intuitive than using that rename & move dialog that leaves stuff behind.
Rename in place and then drag N drop.

[skidoo]

hit_ny: That's not really an applicable solution. What if you decide to change the artist name "The Clash" to "Clash, The?" What if you do this for 500 groups?

[StiX]

Furthermore...
Files like: folder.jpg, [back].jpg, [LP Front].jpg, album review.txt, etc. are ALBUM-related
Files like: bios.txt, [Artist Photos], Discography.html, Artist URL, etc. are ARTIST-related

Each ARTIST and ALBUM should be a Unit/Group/SeparateDatabase (call it as you wish) and there should be a way to easily attach ANY file to any item of this, currently non-existing, but a must-be-developed  Artist\Album tree-structure. By adding this separate Databases there will be never questions about file attendants. Waiting when JRiver will start working on MC12.

Currently there's 2 solutions:

1. Import, fill all Artist/Album-related tags and then use a Rename Files Template to move files to correct folder and then Artist/Album-related tags should be changed for all files of that particular Artist/Album.
    The advantage of importing files, is that you will see the quantity and contents of all Artist/Album-related attendant files inside Library.
    If you will want to view All files of that Artist/Album you should use Locate>Album (except if you are browsing by Albums).

2. Move files to the Album-folder and then if needed to rename Artist/Album-related folders, that should be done only in MediaCenter
    If you will want to view All files of that Artist/Album you should use Locate>OnDisk or SendTo>External>...