Prowlarr /search Sonarr /release end points

[rraymondgh]

I can't see either of these end points in the API.

[davidnewhall]

Hello, I've added methods and structs for both of these api endpoints. Can you test the new code? Thanks!

[davidnewhall]

Thanks for responding to that feature request. There are a few reasons I switched from starr to resty

• end points that I'm using not being present, however this is not primary reason. Have also identified /indexer/bulk
• a very minor point, would need to use githash versioning as don't want to use latest
• taking IndexerResource as an example structure. I'm looking for a common definition across prowlarr, sonarr and radarr. I see the /indexer endpoint across the apps as being the same. The differences can be fully ignored (just not defined in the struct)

Taking third point - this then allows functional code that implements download capability that is 100% common across arrs. There is no need to do any type coalescence between radarr.IndexerOutput, sonarr.IndexerOutput and prowlarr.IndexerOutput. Plus no need to implement interfaces that use almost identical functions for each of the apps

I did experiment with generics before refactoring code to use resty I just could not get it to work. This reasoning is maybe flawed - I'm new to go, the type strict approach is great. Possibly I'm just not seeing how to deal with heterogeneous structs that have very large overlap in an effective way.
Yeah, dealing with structs that are similar but not identical is always a pain.

I could write a copy function that uses reflection to copy all values from one struct to another if the name and types match. So you'd do something like this:

p := prowlarr.New(&starr.Config{
	URL:    "http://192.168.3.2:9696/prowlarr/",
	APIKey: "abc",
})

s := sonarr.New(&starr.Config{
	URL:    "http://192.168.3.2:8989/sonarr/",
	APIKey: "xyz",
})

indexers, err := p.GetIndexers()
if err != nil {
	panic(err)
}

var indexer *sonarr.IndexerInput
starr.Copy(indexers[0], indexer)

_, err = s.AddIndexer(indexer)
if err != nil {
	panic(err)
}

As for points 1 and 2: The library is never finished. The starr apps are under constant development. I make releases along the way, but we're always adding new methods and structs, so yes, you'd have to use a hashref to keep the newest version. If we got all the feature you need in place, I'd be happy to cut a release you can lock yourself to.

Your thoughts are welcomed.

[rraymondgh]

Yeah, dealing with structs that are similar but not identical is always a pain.

I could write a copy function that uses reflection to copy all values from one struct to another if the name and types match. So you'd do something like this:

p := prowlarr.New(&starr.Config{
	URL:    "http://192.168.3.2:9696/prowlarr/",
	APIKey: "abc",
})

s := sonarr.New(&starr.Config{
	URL:    "http://192.168.3.2:8989/sonarr/",
	APIKey: "xyz",
})

indexers, err := p.GetIndexers()
if err != nil {
	panic(err)
}

My initial thought is GetIndexers() could be passed a pointer to a struct which is used by json.Unmarshall(). This way calling code can control struct types. This idea is a little unbaked....

var indexer *sonarr.IndexerInput
starr.Copy(indexers[0], indexer)

I've seen there are other libraries that do this. I think it could work.

_, err = s.AddIndexer(indexer)
if err != nil {
panic(err)
}

As for points 1 and 2: The library is never finished. The starr apps are under constant development. I make releases along the way, but we're always adding new methods and structs, so yes, you'd have to use a hashref to keep the newest version. If we got all the feature you need in place, I'd be happy to cut a release you can lock yourself to.

That's what I thought - hence why I see them as very minor challenges.

I'll branch my PR branch and try to refactor again to use starr That way I can be much more specific on what is preventing adopting starr. Using resty has been simple to integrate. A bit perverse, have created a jupyter notebook that does a pretty decent job of generating go struct definitions from the openapi JSON. I'll update on this refactoring - hopefully pretty quickly.

[davidnewhall]

being able to unmarshal into a custom struct is not straight forward with starr, but it's not impossible. Here's an example saving prowler indexers into the sonarr type:

func main() {
	p := prowlarr.New(&starr.Config{})
	var output sonarr.IndexerOutput

	req := starr.Request{URI: path.Join(prowlarr.APIver + "/indexer", fmt.Sprint(indexerID))}
	if err := s.GetInto(ctx, req, &output); err != nil {
		return nil, fmt.Errorf("api.Get(%s): %w", &req, err)
	}
}

Writing this example makes me want to expose all the bpConstants at the top of each method file.

---

I don't personally care for this, and think a copy method would be easier to maintain. I'm almost done writing something you can test.

[davidnewhall]

I spent much longer than I wanted to trying to figure out how to copy into an initialized []interface{} using reflection. Uhg.
This is probably more reliable anyway. Check it out?

• Copy Indexer structs example #164

I'll add that this still isn't perfect, and I'm willing to make more api-method-specific copy methods if you think it'd be useful. What I mean by that is a method named CopyIndexer that can take in any indexerInput or IndexerOutput type, and output it into a new IndexerInput type specific to the app.

Things this current implementation can't directly account for are "zeroing" the ID, possibly tags, and settings these:

EnableAutomaticSearch:   false,
EnableInteractiveSearch: false,
EnableRss:               false,
DownloadClientID:        0,

EDIT: It can account for these now ^ example in the linked pull request description.

[davidnewhall]

Created the CopyIndexer method to give some ideas. Looking forward to your feedback.

[rraymondgh]

Created the CopyIndexer method to give some ideas. Looking forward to your feedback.

Thanks, I've forked PR #163. It appears you have missed the prowlarr /search POST endpoint. The equivalent of the Grab() function on sonarr /release end point.

I will want the radarr /release end point as well. Plus /indexer/bulk on sonarr and radarr

To get me going with casting I've coded this:

func Recast(a, b interface{}) error {
	js, err := json.Marshal(a)
	if err != nil {
		return err
	}
	return json.Unmarshal(js, b)
}

func RecastSlice[
	S prowlarr.IndexerOutput | radarr.IndexerOutput,
	D sonarr.IndexerOutput](
	src []*S, dest []*D) error {
	for i, idx := range src {
		dest[i] = &D{}
		err := Recast(idx, dest[i])
		if err != nil {
			return err
		}
	}

	return nil
}

As I'm refactoring this I'm getting optimistic I can do away with casting and use generics.

[davidnewhall]

The contents of #164 and #166 are merged in the dn2_both branch. Hoping it has everything you could need. Lemme know!

[rraymondgh]

The contents of #164 and #166 are merged in the dn2_both branch. Hoping it has everything you could need. Lemme know!

I've just published this https://github.com/rraymondgh/starr/tree/dn2_both_local branch. Which has fixups to structures to resolve json marshalling errors

• indexerFlags is problematic as it has different data types across prowlarr / sonarr / radarr search & release enpoints. Have commented to prevent being able to convert between structures
• have redefined the structures using my code generator to make sure they are consistent.
• radarr Grab...() functions were not working. Have stripped back to just GUID and IndexerId. This is all that is needed and a couple of weeks ago I did find a reference to this in sonarr / radarr support or GitHub issues that these are the only two required attributes
• I did a timing test between resty implementation and starr implementation. Both are pretty much identical (being slower that I would hope)
• I'm not inclined to use orbit package. I think the recasting functions are best kept local to functional capability for now rather than being in an external dependency
• why have you got type Grab struct ? I think these should always be identical to output struct. This is how they are defined in json API
• the /indexer/bulk endpoints worked perfectly without me finding any issues :-)

Thoughts - happy to generate a PR to be able to merge these changes back into your branch

[davidnewhall]

Thanks for the follow-up! I have some questions :)

1. I'll look into the indexer flags more. We can't just remove outputs entirely. :( Can you tell me more about the problems?
2. Why do you need omitempty on random fields? That's only used when marshaling and these are outputs not inputs.
3. My Radarr would not work without all the inputs. It continually gave me errors until I had them all. How can I reproduce what you did?
4. I honestly have no idea why I made a Grab struct other than I thought they were different. I see now they're not.