Add Willow (1988) 4k UHD disc#216
Conversation
lfoust
left a comment
lfoust
left a comment
There was a problem hiding this comment.
Thank you for contributing! I am curious if why you chose not to contribute using the website (https://thediscdb.com/contribute). It is much easier for me to review and keep the data consistent via the website
Hi Luke! Coincidentally I just tried to connect with you on LinkedIn regarding this. I'm working on a tool (BluForge) which marries the ripping process to the playlist identification process using TheDiscDB data. The workflow is:
When there is no match I've developed a mechanism to submit the disc scan data and playlist/track/TMDB data back as a PR here to help build out TheDiscDB data. I want to make sure the data I submit is accurate, and not at all a headache for you to review. It looks like I have a couple things to tweak (ASIN, correct images, etc) but would love any other feedback on what I can change to make sure when these come in, they aren't a headache for you to review. |
…esubmit The add-type resubmit form and handler silently dropped ASIN, release date, and front image URL fields. The form lacked hidden inputs for these fields, and the handler never called parseAndSaveDraft() before invoking the service. This caused every resubmit to produce commits with only DateAdded changes — no ASIN, no release date, no front image. Also removes ImageUrl from generated release.json per TheDiscDB maintainer feedback (it is auto-filled during import). Addresses all 4 review comments on TheDiscDb/data#216. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
JohnPostlethwait
force-pushed
the
contribution/willow-1988/1988-4k
branch
from
567e5d6 to
c20b137
Compare
JohnPostlethwait
force-pushed
the
contribution/willow-1988/1988-4k
branch
from
c20b137 to
197f258
Compare
JohnPostlethwait
changed the title
|
Ok, I think I finally have this working correctly for new disc additions and up to spec. Please let me know if I missed anything. |
|
This looks good. Thanks for the fixes. Now I am noticing this is a 2 disc release - do you plan on including the blu-ray disc as well? |
| "Slug": "uhd", | ||
| "Name": "UHD", | ||
| "Format": "UHD", | ||
| "ContentHash": "", |
There was a problem hiding this comment.
Oh, I just realized there is no content hash. This is pretty important because that is how users know if a disc they are contributing is already in the database. We can discuss different ways to calculate this but it is a MD5 hash of some file system data on the disc. thediscdb.com has an api endpoint you can call if you don't want to implement the algorithm on you own
No – I wasn't planning on ripping it. Is that an issue for contributions? |
My strong preference is that if you have access to the disc, you contribute it as well. Does your process require you to actually rip the disc or can you just generate the logs and create the summary file? |
Yeah, it's heavily targeted towards ripping at the moment:
My thinking was if the app had just gathered data that could help contribute to TheDiscDB then make it easy to contribute, but it's all currently predicated on the ripping use-case. In my own case I only tend to rip the higher quality discs in sets. If that's an issue I could block submissions when they are multi-disc sets which only add one of the discs... |
|
I have been considering a feature for a while where contributions can be marked as "partial" so that it is clear where we don't have full data and also we can encourage people to contribute those items. I'll have to think about it and get back to you. In the case of multi disc sets where you have both discs but aren't going to rip both - it would still be immensely helpful if you were able to still include the makemkv logs and the disc hash so that all someone would need to do to finish contributing that disc would be to label what is on the disc |
|
Hi @lfoust - I respect that, and can personally commit to doing it that way, I'm just not sure how I can enforce it in my application. I don't have a datasource to programatically know if a disc scanned/ripped is part of a multi-disc set or not. TMDB doesn't seem to contain release-level info like that. So the question is, even if I personally commit to doing that with my own contributions, how can I enforce it at my application-layer so it's not opening PRs that don't meet your standards if someone besides me uses it? Totally open to ideas if you have them. Ultimately this is your database/project and I'll respect whatever decision you make, including "I'd prefer you did not have your application submit contributions". I was mostly trying to be helpful and build out theDiscDB dataset more with how I was ripping my collection and figured if anyone else ended up using my application they could likewise contribute their data. If I can't programatically enforce multi-disc data submissions, and it's therefore not a helpful feature, then I can totally turn the functionality off and just personally contribute via TheDiscDB.com. |
2 participants
No description provided.