Media Browser Integration

[mvallevand]

I'll step through the code and see what happens... to confirm

In manageservice when not request recurring you are still getting recurring?
For a manual recording one-off you do not get anything because there is no EPG and no recurring?

Yes it .produced a recurr+rtn record like before my first patch. The attached patch does it they it should (IMO) ie an EPGEvent+schd+rtn

Martin

[UncleJohnsBand]

Yes it .produced a recurr+rtn record like before my first patch. The attached patch does it they it should (IMO) ie an EPGEvent+schd+rtn

Martin

Thanks 20131218-2 on the FTP server has this patch applied.

[lukemb3]

No it works fine here, even with the Chrome addon UJB suggested. What C# parser are you using? My test is with Newtonsoft.

Martin

That came straight from fiddler. I've barely done anything with next pvr as i don't use it personally. i setup a few manual recordings just so i could see some data, so maybe it's related to that since they're pretty uncommon. Anyway it's fine. I can filter out the bad records if i have to, just reporting what i'm seeing.

[lukemb3]

20131218-1 on server now uses channelId qyerstrng to take in the OID of the channel

Thank you.

[lukemb3]

Just one more minor point of feedback, although sometimes it can be a little more than minor. It would be nice if all of these Get calls that require a json body could use the query string instead (or accept either). I think a typical practice that developers are going to do when debugging issues is look at their application logs to see what url's were requested, and then put that url into a browser just to get a quick look at the response.

And that's what I keep running into. When i see a discrepancy that I want to research, my first instinct is to look at my log and grab the url, but unfortunately it's not always something I can use to debug with.

[mvallevand]

Just one more minor point of feedback, although sometimes it can be a little more than minor. It would be nice if all of these Get calls that require a json body could use the query string instead (or accept either).

Do you mean POST

Martin

[lukemb3]

Well for right now i"m just talking about ManageService/Get/SortedFilteredList, which technically is a POST but to the consumer it is conceptually a Get.

[UncleJohnsBand]

Just one more minor point of feedback, although sometimes it can be a little more than minor. It would be nice if all of these Get calls that require a json body could use the query string instead (or accept either). I think a typical practice that developers are going to do when debugging issues is look at their application logs to see what url's were requested, and then put that url into a browser just to get a quick look at the response.

And that's what I keep running into. When i see a discrepancy that I want to research, my first instinct is to look at my log and grab the url, but unfortunately it's not always something I can use to debug with.

Lots of discussions on this topic... general consensus (at least on the .Net side of the house) is that query strings are acceptable with RESTful services. But best practices is to use direct url's when the function is for a single purpose with a single value (i.e. delete key =, add key=, get key =) and use querystrings as refiners and objects when it makes sense.

I thought that I was following that practice.

The posts (the ones with the JSON body) make the most sense (at least to me) since you are bringing in a lot of configuration pieces all at once.... and on the server side these objects are passed around through the layers used to produce the results.

If I built querystrings I think it would be a lot of extra management work on the server side to read, validate and construct into a usable object.... when that can be done from the client and passing of objects is part of the REST architecture.

[UncleJohnsBand]

Well for right now i"m just talking about ManageService/Get/SortedFilteredList, which technically is a POST but to the consumer it is conceptually a Get.

yea... I am sure that is what was meant as they are the only ones that use the objects.

[lukemb3]

I don't really pay attention to .net flavors of Rest. To be honest I really have no idea what that means. I know that a major principle is that each interesting resource is available using a unique identifier, which in an http-based api means the Uri. Whether that's /Movies/Unwatched, or /Movies?IsWatched=false is largely a matter of taste. Either way you're pulling down a resource which is unwatched movies.

In any event, it's fine, I can work around it. But my own advice is that it sounds like you're exposing your domain implementation beyond your interface (the api). At least I get that impression based on you're saying that you built it so that clients construct the same objects as you do in your own domain. It just means you're going to feel some pain if you ever have to change anything.