| Message |
Details |
Quoting Magmadrag:
Quote:
Okay, to both of you:
Thanks for all the work and the time you invest in my project
And: Sorry if I come up with new wishes/requests. They're mostly caused by (bad) experiences with existing data or with the lack of functions on profiler itself. Sorry!
It's only the thought: When I am done correcting all the data, I try to avoid that any new profiles could deliver incorrect data, destroying the work of months
Well everything in this forum is a team effort. And we asked for your ideas. | Posted: Topic Replies: 168, Topic Views: 10773 |
 |
| I have been working on CCCreator since the start of this discussion. It is a lot of work because I am not smart and i have a lot of family things on my plate. I will be releasing a preview video soon. I am also happy to work with Gunnar to move some of my plugin internals to HTTPJolie in case he wants to make a "supertool" that blends both concepts into his tool. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
| I started down the path on my subplugin CCCreator, and it has been fun, but I wonder if too much overlap with BY Check. If I get it done, I will gladly retrofit any of the guts into HTTPJolie if you want to consolidate the UI into your tool. | Posted: Topic Replies: 66, Topic Views: 22078 |
|
| And the hits keep on coming! | Posted: Topic Replies: 66, Topic Views: 22078 |
|
| Nice update. | Posted: Topic Replies: 66, Topic Views: 22078 |
|
| Yes. Don't do anything until somebody who knows how, comes along and gives exact instructions. I am travelling and I don't want to risk making a mistake in my instructions. | Posted: Topic Replies: 3, Topic Views: 2751 |
|
Well, so far the RecordScanner app has failed to identify only a couple of the 300 or so albums I have done so far. So, no need to scan convers (other than a 2 sec cellphone scan to power the search) or do any typing. I usually have multiple cover images to pick from the Discogs library, and all the metadata comes over. Most of the folk, rock, jazz, blues, and R&B - i.e., non-classical albums are found directly on Spotify. No need even for digitizing, since the source material is identical.
In the case of classical, I very often get close cousins to my albums, but at this stage of my life, I am happy to just be able to listen to my favorites and recall my life and times when I first discovered that music and was listening to it more frequently.
My main goal is to sell as much of my collection as possible to get a few more retirement dollars to spend on golden years activities.  | Posted: Topic Replies: 6, Topic Views: 4735 |
|
| Good stuff. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
I also recently joined the party. Cleaned up and adjusted my Dual turntable and fitted a new cartridge. Volume was low, but my receiver had a setting to compensate. Next step was to prioritize my 600 disc collection for transfer to digital, using Audacity.
Then I discovered "RecordScanner" app for my iPhone. Amazing. It can scan by barcode, label ID, or cover image, or search by keyword or Discogs ID. So far, after about 400 discs, there has been only a couple I could not find.
It is the Profiler for analog media (Vinyl / Cassette). You get a mobile database and a website, and a Discogs estimate of the value of each disc and collection as a whole. Items are put onto shelves by category. Really cool app.
Bonus, there is a button in the app that links to playing the closest match on Spotify. Most albums that have been commercially digitized come up readily. Best for popular non-classical. For classical, you often get a close match to the track contents, albeit with different artists / album. Still super fun. I haven't touched the turntable since. What a trip back in time I have been having, listening to Spotify as I scan and catalog my collection.
See it here:
My Collection | Posted: Topic Replies: 6, Topic Views: 4735 |
|
Quoting Magmadrag:
Quote:
I can ensure you, as long as there is data in the dummy profile, it doesn't matter if it is owned, ordered or wishlist. There are a few profiles in my wishlist, and even they are part of the update process.
This way I'd like to say that for the program it doesn't matter where the cast & crew is to find in a profile. As soon as they are anywhere without a BY, they became part of the ACTORS/CREW files.
Not sure if this thought could be integrated in THIS tool or needs another one: You remember a few posts before I had the death date issue. Well, there's the same one with birthyears: I found actors with a BY listed in movies which were produced several years before they were born. But I think this check might need another tool, as I got no logically idea how this issue has any connection to the problem I started this thread for.
Not importand but anyhow confusing and funny: To find out if the actors listed in the profiles are the ones with the right BY, I have to check a lot at the IMDB. And today I reached an actress, allready passed away in 1998, and they list several movies "in planning" up to 2026. I can't imagine that she has been kind of mummified and now only plays dead corpse.
That's funny! 
Anyway, don't worry about what the original purpose, etc. I can make the tool do whatever I want. So, what check are you talking about for the hypothetical other tool? I already have in mind a cross reference that includes a column for both birth and death years. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Good news:
I think I solved the performance issue, without voiding the results.
My database is 1400 profiles. That resulted in over 47,000 unique credits. The dummy profile contains about 60 cast and 40 crew. The whole process took under 5 minutes.
Of course we will all be validating the results as soon as I get something that you can use. I will be working on that for the next few days. As I mentioned before, if you have any specific ideas other than those already presented, speak up, and I will try to get the easiest things done in the first release.
I'm not totally sure, but having the dummy profiles in the Wishlist might not result in the database being permanently updated. I need to do some more testing. It would make sense, as Wishlist profiles are not yet owned. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting Magmadrag:
Quote:
Well, as long as they are the ones with accepted/released Birthyears I think that's neccessary. Or what do we have the BYs for, if nobody cares about their use?
You didn't create BYs. Somebody else who cared about their use, did. And other people maintain a website supporting accepted ones. Get a grip on yourself. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting Magmadrag:
Quote:
Does this mean you don't cere if the data in your collection is correct? That's a shock!
Look don't try to start analyzing or judging me. Do your thing and I'll do mine. Of course I care whether the data is correct. Why do you think I have 20 years of plugin programming to help people who worry about the data. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting Magmadrag:
Quote:
If you would like to enhance your "imagination" how much profiles have to be corrected because of wronlgy used birthyears, just check all your profiles with any "version of "John Moore".
I'd like to say that I had to correct about 70 % of them (most times wrongly used the 1966 insted of the 1968 one).
I will take a look for education. But I am depending on you for the imagination. I have mostly no clue about this stuff. Writing code and solving problems for people is a hobby and I enjoy it. But I really don't care much about the actual problem in most cases. Of course I need to understand it, but the passion is not there. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting Magmadrag:
Quote:
Quoting Magmadrag:
Quote:
Not sure if I should post this here or create a new thread as this could be a new tool - if even possible.
The difficulty for the possibiliy is that we don't list the death dates anywhere. If available, Luigi lists them, but if not.....
And I got to this as I had to find out that "Peter Cook (1937 - 1995)" is credited in several profiles as an actor after his death (e. g. "Terra Nova")
So if we would have any list of death dates a tool would be interesting to check out cast & crew, if they are credited after their death. That's only possible for "archive footage". The only chance to question if the credits could be correct is "Production Year - 90 > Birthyear".
It's only a thought (for a future far far away^^) but another way to find out probably wrongly used cast & crew
Second recognition about this: Sometimes it's funny - because it can't be real - to have an actor, BY 1950+ credited in a movie before his birth. Another fact to be checked.... manually work is horrible. When I am done tonight, the BY-list is done for actors up to letter C - and I'd like to say that I had to change/correct more than 100 profiles....
What is in my mind is a tool that has the dummy profile entries, the full set of local cast/crew, the common names, and accepted birth years with the ability to interact and make changes to the database.
What functions could you imagine to be on the context menu (right click) when you select an item from one of those lists? I know it will be easier once you get the tool to play with, but in case you already thought of something. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
For whomever might be interested, here is the code so far:
(1) Create a master dictionary of cast and crew credits in the local database
The key is: "Cast_fn_mn_ln_{by}" or "Crew_fn_mn_ln_{by}"
The dictionary entry is an instantiation of the CastCrewEntry class:
class CastCrewEntry
{
private string _FirstName = "";
private string _MiddleName = "";
private string _LastName = "";
private string _Part = "";
private string _CreditedAs = "";
public string FirstName
{
get => _FirstName;
set => _FirstName = "" + value;
}
public string MiddleName
{
get => _MiddleName;
set => _MiddleName = "" + value;
}
public string LastName
{
get => _LastName;
set => _LastName = "" + value;
}
public string Part
{
get => _Part;
set => _Part = "" + value;
}
public string CreditedAs
{
get => _CreditedAs;
set => _CreditedAs = "" + value;
}
public int by = 0;
public bool Voice = false;
public bool UnCredited = false;
public bool Puppeteer = false;
public int CreditType = 0;
public int CreditSubType = 0;
}
(2) Create a dummy profile placeholder for the newly created credits
DateTime date = DateTime.Now;
string DummyTitle = "Cast and Crew Dummy Profile";
string dummyID = "M" + date.ToString("yyyyddMMHHmmss");
dVDInfo.SetTitle(DummyTitle);
dVDInfo.SetProfileID(dummyID);
dVDInfo.SetProfileTimestamp(date);
dVDInfo.SetDVDReleaseDate(date);
dVDInfo.SetCollectionType((int)PluginConstants.COLLTYPE_WishList);
DVDPFauxAPI.FauxAPI.DVDProfilerAPI.SaveDVDToCollection(dVDInfo);
(3) Now scan the master credits dictionary in a loop (this is what I will be trying to speed up)
When an entry has a by>0, then I synthesize a key, using "{0}" for by. If found, I move on.
If not found, I extract the CastCrewEntry object from the dictionary, set by=0, then add that credit (cast or crew) to the dummy profile and save it. Since there was no such credit in the database, this causes a new entry in the database table for cast or crew (at least I think it does).
Continue for all entries in the dictionary.
Final save of the profile.
Call for a database resync to update pointers.
Done. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting GSyren:
Quote:
Quoting mediadogg:
Quote:
And if that does happen, I can envision a fix. Costly in terms of time, but it will work. Once the profile is saved, I can reload it with a refreshed database pointer and compare, and simply re-write to the database with the BY reset back to zero.
I'm not sure that that is going to work. If the added profile contains a birth year, that would mean that Profiler used the existing cast (or crew) record. So changing that birth year would not create a new cast record, but either change the birth year for the existing record or fail, depending on how Profiler handles it internally. At least that's what I think will happen.
What might have a better chance of succeeding would be to assign a fake birth year (like 9999) instead of zero when adding the profile. This would force Profiler to create a new cast entry, which could possibly be changed afterwards to zero. Not sure though if such a change would change the actual database record, or just temporarily change a copy in memory.
The cast is not not actually stored in the profile, just pointers to the database table. Rest assured that there is way to make it happen, using the API, even if you have to use tricks.
I have working code by the way, for the originally proposed tool. No GUI yet, such as menus, progress bar, log, etc.
And with all the ideas, it will be awhile before the first release, but I think it will have some fun stuff.
Next task is to get the code I have working, running faster. It is painfully slow, but maybe not necessarily. Once I get that done, I should probably put a rudimentary GUI on it, so you guys can validate whether is is actually doing what I claim, and we can test any theories about what the API does or can be made to do, because we will have code. Which I am happy to share by the way. Nice thing about FauxAPI, is that you can change the code if you want, compile to dll and replace my version to test any idea you have. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting Magmadrag:
Quote:
Not sure if I should post this here or create a new thread as this could be a new tool - if even possible.
The difficulty for the possibiliy is that we don't list the death dates anywhere. If available, Luigi lists them, but if not.....
And I got to this as I had to find out that "Peter Cook (1937 - 1995)" is credited in several profiles as an actor after his death (e. g. "Terra Nova")
So if we would have any list of death dates a tool would be interesting to check out cast & crew, if they are credited after their death. That's only possible for "archive footage". The only chance to question if the credits could be correct is "Production Year - 90 > Birthyear".
It's only a thought (for a future far far away^^) but another way to find out probably wrongly used cast & crew
At this point, anything is on the table. It is a new tool so we can do whatever we want. I will be in London for a week with my Son and family, so I will enjoy having some kind of project to play with when the kids are asleep. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting DJ Doena:
Quote:
Quoting GSyren:
Quote:
Quoting mediadogg:
Quote:
So changing that birth year would not create a new cast record, but either change the birth year for the existing record.
In the API you don't really have access to the cast/crew as people. You just can tell a profile that it contains this first, last and middle name with that birth year. There is no way to edit an actual person.
That is not me you are quoting. You know that I know better. Editing the cast and crew comes pretty close to editing a person. You can even make new ones. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting GSyren:
Quote:
Just a thought:
When you download a profile and it has a person w/o birth year, and your local database has the same name with a birthyear, the person in the downloaded profile will get that birthyear. This is the problem that Magmadrag wants to avoid.
But ... what's to say that the exact same thing doesn't happen if you add a profile (without a birthyear) through the API? It might be a good idea to test this - if not already done - before investing a lot of time and effort. And if that does happen, I can envision a fix. Costly in terms of time, but it will work. Once the profile is saved, I can reload it with a refreshed database pointer and compare, and simply re-write to the database with the BY reset back to zero. It will work this time because the new cast/crew entry will now already be in the database. Actually I would save the entire credit entry and restore it, if I discover the BY is not still zero. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Sausage and peppers please!
(Well they are pretty standard, IMHO) | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Quoting GSyren:
Quote:
Just a thought:
When you download a profile and it has a person w/o birth year, and your local database has the same name with a birthyear, the person in the downloaded profile will get that birthyear. This is the problem that Magmadrag wants to avoid.
But ... what's to say that the exact same thing doesn't happen if you add a profile (without a birthyear) through the API? It might be a good idea to test this - if not already done - before investing a lot of time and effort.
A good idea, although much of the effort that part of has already been expended. The other ideas I have are related, but independent of how the data arrives.
I agree it would be interesting to know the answer. If you have a couple of profiles I could use to observe, it would help, since I am on a thin line of understanding this stuff. No rush. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
| Thanks. I have so many ideas now. You will be amazed. | Posted: Topic Replies: 168, Topic Views: 10773 |
|
I found it!!!
http://www.luigifilocamo.it/BY.html
What does it mean when an "accepted" By has "(19??)"? Does that mean BY=0 (no birth year)?
What does this mean: Robert Young (1935-2011)?
Why no middle names? | Posted: Topic Replies: 168, Topic Views: 10773 |
|
Also thinking about this:
"A tool which "knows" all the accepted/released BYs and checks all cast & crew in any profile I want it to check if there is any cast/crew WITHOUT a BY but is in the list WITH a BY. So then I know that I have to check this person if I allready have it in my database with one BY or another."
It was easy for me to get all the common names for CLTBoss (latest update I forgot to release). There doesn't seem to be as organized a list of accepted birth years. Am I wrong? Any developer that has code already that gets them?
As far as common names, do they automatically have accepted birth years? | Posted: Topic Replies: 168, Topic Views: 10773 |