INTERACT FORUM
More => Old Versions => JRiver Media Center 32 for Windows => Topic started by: dtc on December 01, 2023, 01:33:43 pm
-
In this edition, it will create a new library and copy the media files.
Since it is moving more than just the library, the function probably needs a name that reflects that the media files are also being moved. Library has a very specific meaning and a library copy function that includes media files is confusing. Maybe Copy MC to This Computer or something like that.
-
Migrate Library and Media
-
Let's stick with Download Library from Server. We'll add a description once we know exactly what it is.
It's not "Copy MC" since MC needs to be installed first on the new machine.
It's not "Migrate" since it leaves everything intact on the server.
Library, in this instance, is both media and database.
-
Library, in this instance, is both media and database.
In MC lingo, Library does not include media files. This is a change to the long standing definition.
From the Wiki
"Media Center stores all of the information about the files you've Imported, the structure and design of your Media Views, and other information in its own internal database called a Library.
This concept is distinct from the locations where you store your actual media files on disk, or the media files themselves. Throughout this Wiki, and on the Interact forum, when you see a reference to your Library, we are referring to this database only, and not to your source files."
-
Library can be your library of media files.
Library can also mean MC's database of your files.
In JRiverville, it can be either.
-
I agree with dtc, Library (capital L) is a specific noun in this context, a library (lower case l) can mean a variety of things.
-
Library can be your library of media files.
Library can also mean MC's database of your files.
In JRiverville, it can be either.
With all due respect, that is not what the Wiki says and it is not how the word Library is normally used. In fact, people in this forum who think the media files are included in the Library are often corrected. Including media files in the term Library brings confusion to the term.
IMHO.
-
I agree with dtc. Since the birth of MC back in... 2002? the library and the media files have been explicitly two separate things.
If we have reached a point in time where the two become one, "library", then a lot of noise needs to be made about it, and, every page on the wiki that drives the point that these are separate things would need to be updated.
-
No, they aren't one. Library just has two different meanings in MC.
-
I've been wanting to make this topic for years so I'm glad that someone else already got the ball rolling.
Let's call a spade a space, MC is an amazing wrapper around an amazing database. In 2023 most people off the street have a rough idea of what a database is. I really don't think that these concepts need to be abstracted or skeuomorphised away any longer, it just adds complexity to existing jargon. Users on Interact frequently conflate the "Library" with the MC database and their on-disk files and it leads to more confusion that it solves at this point.
What is a library? In this context it's a collection of catalogued items (i.e. the items themselves). So the whole concept of the MC "library" has never made a whole lot of sense (making a library backup that doesn't include a backup of the actual files).
If it were up to me, I would completely redefine the existing nomenclature. What we are really talking about most of the time in reference to the MC library is not the library but the MC database. We are connecting to remote databases, loading alternate databases, backing up databases, etc.
The library should refer to the "file library" of actual files on disk (and it would be clearest to new users to refer to it as a "file library"). The database should refer to MC's internal catalog. So if we want to make a complete copy (as part of the new feature) we would be downloading both the file library and the database. Maybe there is a singular term that could combine these but that's not for me to decide. You could define the "MC Library" as files (or file library) + database as Jim alludes to, but that actually contradicts the existing nomenclature as was pointed out.
-
MLFDB. There you go...
-
I've been wanting to make this topic for years so I'm glad that someone else already got the ball rolling.
Let's call a spade a space, MC is an amazing wrapper around an amazing database. In 2023 most people off the street have a rough idea of what a database is. I really don't think that these concepts need to be abstracted or skeuomorphised away any longer, it just adds complexity to existing jargon. Users on Interact frequently conflate the "Library" with the MC database and their on-disk files and it leads to more confusion that it solves at this point.
What is a library? In this context it's a collection of catalogued items (i.e. the items themselves). So the whole concept of the MC "library" has never made a whole lot of sense (making a library backup that doesn't include a backup of the actual files).
If it were up to me, I would completely redefine the existing nomenclature. What we are really talking about most of the time in reference to the MC library is not the library but the MC database. We are connecting to remote databases, loading alternate databases, backing up databases, etc.
The library should refer to the "file library" of actual files on disk (and it would be clearest to new users to refer to it as a "file library"). The database should refer to MC's internal catalog. So if we want to make a complete copy (as part of the new feature) we would be downloading both the file library and the database. Maybe there is a singular term that could combine these but that's not for me to decide. You could define the "MC Library" as files (or file library) + database as Jim alludes to, but that actually contradicts the existing nomenclature as was pointed out.
I think I agree with this, and would like to see more consistent and clear usage. One thing I think folks may be missing is that the problem of inconsistent use of the word "library" is already present in JRiver's UI, and it frequently confuses folks (including me!).
As folks above have noted, most of the time when JRiver uses the word "library" it just means the database and not the files. E.g. the menu option called "backup library" backs up only the database and none of the media files. But that's not always true. There's also an option in File-->Library called "sync library" which copies actual *media files* from a library server to another computer, but not the database. To be clear the "sync library" command is not to be confused with "sync changes with library server" which only syncs database information and not media files, but has a very similar name. So the word is definitely already equivocal in the UI, and I think it's confusing that different functions are called by the same name: the first time I did a library backup, I was very confused that no media files came along for the ride; the first time I tried to sync client changes to the server, I tried the "sync library" command, which does something entirely different, etc.
I agree with the broader sentiment that it would be nicer if menu options that only act on the database and menu options that act on the files had distinct names, whatever those names are. Taking functions that act 1) only on the database, 2) only on the files, or 3) on both at once, and calling all three by the same name seems like a recipe for people thinking they have a backup and not actually having one.
As an example of the potential confusion, I'm a little confused about the scope of the new "download library" feature. It sounds very similar to what "sync library" already does. Will it effectively replace/expand "sync library"? Or will it coexist with that feature? In the other thread Jim describes it as:
"It would move all selected files (or all files) to the connected client. It would ask whether to include playlists, settings, etc. These could probably be moved as a backup file. MC would make an assumption about the default locations, but allow you to change them."
But that looks exactly like what the current Sync Library function does right down to customizable locations? I've attached a screen cap of the current Sync Library dialog for reference.
-
Conflating metadata with data is an error (if that's what you are doing)
Imv as it is is v simple, the library now is metadata, the media files are data.
MC needs to manage the former, it provides some convenience functions to interact with the latter when it impinges on the former. It should do a better job of those functions, it doesn't need to take control of the data to do so.
-
IMO dev would.be better spent on making MC better at handling files before trying to give it more responsibility
. It doesn't do the basics right now so trusting it to do more looks an error to me. For example, if you tell it to move a load of items, is it reliable? Does it inform on progress? Does it alert to errors? Does it tell you who did what and when?
The answer to all of these is no.
Put simply, mc managing metadata = good (except for particles maybe)
Managing data = not good
-
It doesn't do the basics right now so trusting it to do more looks an error to me. For example, if you tell it to move a load of items, is it reliable?
Yes.
Does it inform on progress? Does it alert to errors? Does it tell you who did what and when?
MC isn't Oracle but I'm not aware of errors moving files. Start a thread if you have specifics.
mc managing metadata = good (except for particles maybe)
Managing data = not good
I think you're wrong. But start a thread.
-
Yes.MC isn't Oracle but I'm not aware of errors moving files. Start a thread if you have specifics.I think you're wrong. But start a thread.
it leaves cruft behind on a regular basis using standard operations and provides no feedback ever on what it's done or hasn't done. It's not worth raising it as it's too expensive, in my time cost, to even to try to come up with something reproducible and the probability something happens as a result looks quite low (not unreasonable as you have to reproduce something to fix it but still the prevailing attitude is "it's your environment")
-
How about posting details the next time you find a problem?
-
Who wants my job?
-
Who wants my job?
JimLLM.
-
JimLLM.
Good idea. A Z80 should be able to handle it.
-
public string AskJimLLM(string prompt)
{
return "Check your antivirus.";
}
-
Language is important. It's a "thing" for me. My grandmother was an English teacher. My cousin is a linguist. Several people in my family are students of language in various ways. Several speak multiple languages. Some of the oldest are becoming fluent in Greek. I've always been around precise use of words. So language is "a thing" for me.
Library is an overloaded word in MC. It means several things. Ideally I'd like to see the word removed entirely from MC. But, after some thought, I think this would cause more problems than it would solve. I can't think of a clean set of words that express "metadata database" and "media files" in a way that non-technical people will immediately recognize. Probably the closest are:
Database
Files and Folders
But as soon as you say "database" a lot of people will be confused. Sadly "Library" as an overloaded term is probably just as good as anything else, because you pretty much have to explain the difference between the database and the media files to anyone who doesn't already know.
Brian.
-
I agree with BryanC: database + file library
Might reduce the confusion for new users who commonly don't grasp the basics.
-
Who wants my job?
You don't want me because I'd blow a gasket and you'd have to fire me.