[Proposal][Feature] Convert DMM's ContentID to standard ID

[seeyabye]

The current ID is rather inconsistent with all other web providers. For instance, DMM uses a format of ID##### where # represents some kind of numeric value while others like Javlibrary uses the standard ID-###. Additionally, there's also no way to customize which type of ID I would like to use.

This exhibits a problem because I would prefer to have it use ID-### rather than ID####, but there is no way to reflect this choice in the settings file.

In this PR, I would like to propose to standardize the ID format to ID-### and keep ID##### as a separate ID, called ContentID. This would also allow customization in sort.format.file and others to support both <ID> and <CONTID>.

There are two ways to go about this problem.

1. Include a new field in $Data to support ContentId and Id. Possibly, include another field that keeps the original scraped id, called ScrapeId
2. Keep the original data structure, but make modifications to Convert-JVString to support <CONTID>.

Each of the above choices has its own repercussions:

1. Requires refactoring all aggregators to include the additional field for support
2. It's more tricky to maintain the long run because it's the responsibility of Convert-JVString to cover all use cases, especially when new aggregators are added. At the moment, I don't see a large deviation in ID patterns.

Right now, I think either choice is fine, but I will leave the final decision to you.

What do you think?

Personally, I have gone with the first choice, but if need be, I can implement the second choice.

With that, I've only made changes to DMM as a prototype, but if this proposal is accepted, I will continue to make changes for the others depending on the choice.

Checklist:

• Implement Id and ContentId for DMM.
• Implement ContentId for all other aggregators

[jvlflame]

This is a good idea. How I originally envisioned users using Javinizer would be using scrapers in conjunction with each other to grab the necessary metadata fields (i.e. dmm for description, r18 for id, etc.). Because Dmm didn't natively support ID, I didn't include it and assumed a user would just use a different scraper to grab the ID. But you bring up a good point of standardizing the ID format to match the rest of the scrapers.

There are two ways to go about this problem.

1. Include a new field in $Data to support ContentId and Id. Possibly, include another field that keeps the original scraped id, called ScrapeId
2. Keep the original data structure, but make modifications to Convert-JVString to support .

Definitely option 1 like you already implemented. This is similar to how the R18 scraper is already working.

With that, I've only made changes to DMM as a prototype, but if this proposal is accepted, I will continue to make changes for the others depending on the choice.

While I think it's feasible to convert from ContentId => Id, I don't believe the other way around is possible, at least not in the original format that dmm uses with things like h_###aaa00123. I believe most people will stick with the standardized DVD Id for their naming, and if they do want to use ContentId, they would still be able to with the Dmm and R18 scrapers.

Let's just:

• Add the Id to the Dmm scraper without adding ContentId to the others (Done, pending review)
• Add setting to prefer the ID type
  • No fallback to the alternate ID type if the preferred is unavailable. I think people would prefer that their whole library follows a consistent schema in this case. If it automatically fell back to the alternative, it would break that consistency.
• Update Convert-JVString to support <CONTENTID> <- Let's use the full name for the tag rather than CONTID

[seeyabye]

I have presently made the following changes:

• Added Id Preference setting to the configuration file. Users can choose to have id or contentid for DMM and R18. By default, it is set to id which corresponds to the ID-### format.
• I have also included <CONTENTID>
• Made changes to DMM Scraper so that age_check_done is presented to both DMM-Ja and DMM-En. I found times when DMM-Ja is forcing me to do the age verification before this change.
• Fixed a bug related to label, maker, and series not returning any results for DMM-Ja

Remark
I've currently embedded the logic for choosing ID or ContentId in R18 and DMM's scraper. This means $movieDataObject.Id will return ID-### or ID##### depending on the preference setting configured.

If there's any other preferred way to do this, please let me know.

[jvlflame]

I did a bit of thinking about having the Id convert to ContentId directly on the scrapers themselves.

I think it would be better to change it only on the aggregated data object, since if people were using Javinizer solely for the scraper functions, they wouldn't want the original scraper output to be changed depending on an Id preference.

My approach would be to consolidate the settings into a single setting scraper.option.idpreference and set the Id during the foreach loop that assigns all the aggregated data fields.

foreach ($field in $metadataFields) {
    $metadataPriority = (Get-Variable -Name "$($field)Priority" -ValueOnly)
    foreach ($priority in $metadataPriority) {
        $sourceData = $Data | Where-Object { $_.Source -eq $priority }

        if ($null -eq $aggregatedDataObject.$field) {
            if ($field -eq 'AlternateTitle') {
                $aggregatedDataObject.$field = $sourceData.Title
            } elseif ($field -eq 'Id') {
                if ($IdPreference -eq 'contentid') {
                    $aggregatedDataObject.$field = $sourceData.ContentId
                } else {
                    $aggregatedDataObject.$field = $sourcedata.Id
                }
            } else {
                $aggregatedDataObject.$field = $sourceData.$field
            }
            Write-JVLog -Write:$script:JVLogWrite -LogPath $script:JVLogPath -WriteLevel $script:JVLogWriteLevel -Level Debug -Message "[$($Data[0].Id)] [$($MyInvocation.MyCommand.Name)] [$field - $priority] Set to [$($sourceData.$field | ConvertTo-Json -Compress)]"
        }
    }
}

What do you think of this approach?

[seeyabye]

I personally like this approach.

To be honest, I wasn't quite pleased with what I have done. I prefer not to have the logic encoded in the model (in this case $movieDataObject). I will include this in the changes. Thank you for the suggestion!

[jvlflame]

Looks good!