More > Media Center 14 (Development Ended)
Next -- Relational Database?
Matt:
If you create a field "Artist Biography" and put a long biography of Aerosmith into 1000 files, Media Center will only store the data on disk and in memory once.
So it seems like the only mechanism that's really needed is, per field, to be able to say:
[*] Store this field per file
[*] Store this field per artist
[*] Store this field per album
[*] Store this field per camera
[*] etc.
When a value is changed, it would be changed for all others in the relationship. This would be a relatively straight-forward addition to the database.
However, there are a few tricky issues.
We don't keep a name and a unique user-manageable ID for each field (which I would argue is right). But this means if you set a relationship of "Store per album" and had ten Greatest Hits albums, it could get a little messy on those ten albums. We already have a runtime album analyzer that generates album IDs by looking at file paths and artist names, so it would help in this case. I'm not sure if the same problem would apply to relationships of other fields.
Also, if you import a _new_ Aerosmith file with a different biography in the tag, should it inherit the existing data, overwrite the existing data for all the files in the relationship, or just be different?
Finally, what should happen if you edit an existing field to say 'Store per artist'? I suppose it might leave the data alone and only modify everything in a relationship at change time, but it's a gray area.
leezer3:
--- Quote from: Matt on June 12, 2009, 04:37:14 pm ---We don't keep a name and a unique user-manageable ID for each field (which I would argue is right). But this means if you set a relationship of "Store per album" and had ten Greatest Hits albums, it could get a little messy on those ten albums. We already have a runtime album analyzer that generates album IDs by looking at file paths and artist names, so it would help in this case. I'm not sure if the same problem would apply to relationships of other fields.
--- End quote ---
User managable I agree with (Plenty of potential for breakage, with little benefit), but can I ask why not an internal ID?
Personally here, I'd be generating any ID from an album hash similar to what YADB is using- This way the different greatest hits albums would be kept separate. I'd assume you could store this hash in a non-visible internal tag, and query it as necessary :)
As we've just proved, a file centric model whilst flexible and powerful has it's drawbacks!
--- Quote from: Matt on June 12, 2009, 04:37:14 pm ---Also, if you import a _new_ Aerosmith file with a different biography in the tag, should it inherit the existing data, overwrite the existing data for all the files in the relationship, or just be different?
--- End quote ---
This needs a small confirmation dialog- Simple and practical :) Either on import, or probably better on the first tag edit a small popup-
Biography for #File# conflicts with the already existing biography for Aerosmith. Would you like to 1. Inherit existing data? 2. Overwrite existing data? 3. Assign unique biography?
A checkbox to always do this should probably be provided, either somewhere in the options or the dialog itself.
--- Quote from: Matt on June 12, 2009, 04:37:14 pm ---Finally, what should happen if you edit an existing field to say 'Store per artist'? I suppose it might leave the data alone and only modify everything in a relationship at change time, but it's a gray area.
--- End quote ---
Again a small confirmation dialog- 1. Populate from existing data. 2. Create this as a blank field, leaving the original data intact.
Cheers
-Leezer-
rick.ca:
I may not understand exactly what you're getting at, Matt, but I wonder if the "tricky issues," at least in part, are not the result of looking at my suggestion from a media-centric point of view. While this is natural given the existing design, I don't believe it's the most intuitive way of looking at it. I'm quite sure I would normally look at it the other way around. I would want to create a separate record for Aerosmith (in which I would record the biography), and then associate that with the media record category Artist. This is important because I'm not likely to, and I don't want to "add" these fields to media records (i.e., as is implied by "Store this field per..."). I want to add them as if they were a separate table. For example, if I wanted to add a bunch of artist bios, it would be much more intuitive for me to ignore media tracks and enter such information to (what appears to be) an actor table.
Yes, I realize the need for the "index" field to be unique is a limitation. But the same limitation is inherent in the current design—it just doesn't matter. To be fair, it should be recognized one would have a choice in this circumstance: record information for these non-unique albums on a per file basis (i.e., as you would now), or make the album names unique (e.g., "Greatest Hits [Artist]") and use the new feature. BTW, just to be clear, the creation of a relation doesn't mean there would automatically be an "additional information record" for every value in the category. I imagine being able to create an Album relation, but that would include a record for "Greatest Hits" only if I created one. This issue would be greatly reduced if it were possible to define a relation with multiple categories. So, for example, it probably doesn't make sense to try to create an Album relation because Album is not unique—and duplications can be much less obvious than "Greatest Hits". But an Artist-Album relation would work fine.
--- Quote ---We already have a runtime album analyzer that generates album IDs by looking at file paths and artist names, so it would help in this case.
--- End quote ---
Perhaps that would be helpful if the objective were to provide some additional functionality that would be completely transparent to the user. I don't think that's necessary or desirable. Let the user define the relationship, and accept responsibly for the resulting behaviour and limitations. I think that would be easier for users to understand, and easier for you to make sure the basic functionality is efficient and consistent.
--- Quote ---Also, if you import a _new_ Aerosmith file with a different biography in the tag, should it inherit the existing data, overwrite the existing data for all the files in the relationship, or just be different?
--- End quote ---
Now that's a good question—I didn't consider the possibility. Maybe the only feasible solution, initially at least, is to simply not allow any possibility of saving these "additional information" fields in tags. If there were a bio tag in files which fills a bio library field, these would be completely separate from a user-created "additional information" bio. Since the answer to this question now is "they would just be different," the addition of the related bio field can only be an improvement. In any case, I think the sensible solution in most cases would be to maintain such information in the library, and forgo the tags.
--- Quote ---Finally, what should happen if you edit an existing field to say 'Store per artist'? I suppose it might leave the data alone and only modify everything in a relationship at change time, but it's a gray area.
--- End quote ---
Again, I'm not sure I understand your point of view, but I think this is why I'm wary of the media-centric view. I prefer to create a separate table item, say "Aerosmith" as Artist (plus the additional information—like a bio) which will be associated with all my Aerosmith tracks by virtue of the fact Artist = "Aerosmith." In other words, I would save the bio in the "additional information" view, and it would appear in the media view if there were an expression column for it. Rather than a 'Store per artist' command, I would appreciate a 'Create/change additional information for this artist' context command that would jump to that record in the "additional information" view.
Matt:
--- Quote from: rick.ca on June 12, 2009, 06:45:19 pm ---I would want to create a separate record for Aerosmith (in which I would record the biography), and then associate that with the media record category Artist. This is important because I'm not likely to, and I don't want to "add" these fields to media records (i.e., as is implied by "Store this field per..."). I want to add them as if they were a separate table. For example, if I wanted to add a bunch of artist bios, it would be much more intuitive for me to ignore media tracks and enter such information to (what appears to be) an actor table.
--- End quote ---
So in a way, you're saying you want to create a blob of information. Maybe that blob is a biography, maybe it's actor information.
Then you want to link that blob to files either manually or by some rule like "artist is aerosmith" or "actor contains billy bob thorton"?
leezer3:
Bingo, precisely ;D (Although I'm not the person you're quoting)
My twiddly diagrams were an attempt to visualise that, not sure how helpful they were though!
Just to re-emphasise, we really need a method of filtering what is displayed though. Bouncing back to my earlier example of Stephen Fry, where he is present in an actor role, there is various audiobook related information, which doesn't need to be displayed. Obviously, I could create a second 'blob', but I'd much rather be able to link 'blobs' to blobs, and filter etc. dynamically.
Cheers
-Leezer-
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version