STV UI Feedback 9.0.0.x

[Tiki]

Originally Posted by BobPhoenix

What I was saying just not as well done.

Yeah - I think we were typing our posts at the same time (I didn't see yours).

[Monedeath]

Originally Posted by Fuzzy

That's not as big an issue as you might think, and frankly, if it was normally set in the UI, then ultimately none WOULD have the same merit. Even now, if two devices have the same merit, one will still always be used first, due to how the list is generated in the core.

I suspect that will likely result in a change that nullifies a current behaviour/assumption being made by the scheduler. Changing the behavior of the scheduler to reverse that nullification may in turn cause less than desirable outcomes for some Sage users.(who would have rather been prompted at that point) Edit to add: I guess you call this a "snowball change" or a "cascading change" scenario. Changing it in such a manner can result in a chain of changes becoming necessary rather than optional. /end edit

Just because it behaves a particular way currently doesn't mean the behavior needs to formalized in the code. I've seen that behaviour on the Ceton tuner, tuner #'s 2 and 3 seem to be Sage's last resort for that merit level, while tuner 5 seems to be its favorite one to use, so it isn't news to me.

Other aspects of this is issues that ensue regarding efforts to incorporate the "tuner pools" concept into the mix, although I guess in that case if they're ever implemented the entire "pool" can be represented by a single entry in such an interface. How the underlying logic handles things from there may be another matter.

[Opus4]

*If* I were the one working on it, I'm not sure that I would force every tuner to have a different merit the first time one gets modified. Having equal merits isn't a problem and higher merit isn't even always the determining factor for which tuner gets selected to record something; the old terminology was along the lines if "if all else is equal, then pick the higher merit." If the merits are equal, then it tries to determine which might be the better tuner according to input type or recording quality choices. I don't remember what else might be taken into account elsewhere.

Andy

[Monedeath]

Originally Posted by Opus4

*If* I were the one working on it, I'm not sure that I would force every tuner to have a different merit the first time one gets modified. Having equal merits isn't a problem and higher merit isn't even always the determining factor for which tuner gets selected to record something; the old terminology was along the lines if "if all else is equal, then pick the higher merit." If the merits are equal, then it tries to determine which might be the better tuner according to input type or recording quality choices. I don't remember what else might be taken into account elsewhere.

Andy

That would explain some occasions where I was certain Sage appeared to be ignoring my tuner merit settings.

[BobPhoenix]

Originally Posted by Tiki

Yeah - I think we were typing our posts at the same time (I didn't see yours).

Probably. I would remove mine as I think yours explains it better but I guess I'll leave it.

[tmiranda]

I started working on a plugin to dynamically change the tuner merits but gave up on it once Andy told me the changes would not be saved. As part of that I already wrote the code to determine the tuner merit and sort the tuners by merit in the STV. I can easily make that code available. (I hate to see somebody else reinvent the wheel.)

What's the easiest way to get this incorporated into the STV?

[Opus4]

Originally Posted by tmiranda

I started working on a plugin to dynamically change the tuner merits but gave up on it once Andy told me the changes would not be saved. As part of that I already wrote the code to determine the tuner merit and sort the tuners by merit in the STV. I can easily make that code available. (I hate to see somebody else reinvent the wheel.)

What's the easiest way to get this incorporated into the STV?

Thanks, but I don't think it will be needed... I'm already making some changes and it will be based on API calls, not the properties. Remember: I already have STV code to do this too, based on the property... but they (the merit values) just don't get re-read at all after startup.

Andy

[rickgillyon]

Where are these updated STV files? Can't find them anywhere!

[Monedeath]

Originally Posted by rickgillyon

Where are these updated STV files? Can't find them anywhere!

https://github.com/google/sagetv/tree/master/stvs

The updated files go into the relevant directory in the STVs folder that Sage runs in. If you have plugins, beware some of them have files in there too, so make sure you're able to restore files they'll need before simply blowing away the old folders.

edit to add: If you are not setup to easily access/download files from the repo, someone around here will probably make a zip file available sooner or later. (people able to compile their own jar files should have the files in their computer's "workspace" depending on how recently they synced with the repo)

Edit 2: As of October 13th changes were made to the sage.jar file in order to implement some of the changes discussed here. Unless you are running a sage.jar built after the 13th of October, it is not advised to update the SageTV7.xml file, as it uses api calls your sage.jar doesn't support.

[rickgillyon]

Thanks!

[Monedeath]

Originally Posted by Monedeath

Tested the already implemented changes, it is working. Currently seeing a double helping of slightly different cast lists on the extenders(strongly suggesting different sources for cast information being used), but I think another Plugin is doing that so will need to hunt it down.

Found the culprit, the Complementary Metadata Tools plugin was the offending plugin. Disabled for now. Edit to add: Reported in the CMT thread over in the customization forums.... If anyone is maintaining it at this point.

[Opus4]

I think people are talking about modifying the merit value from the source setup screen, where the list of configured tuners is listed, but merit values are stored per-capture device, while a capture device can have multiple inputs... and the list of configured tuners is actually a list of configured inputs... meaning the same capture device could be listed there more than once.

I'm betting that for a lot of people (most?), there is only 1 input configured per capture device, so the merit really only applies to 1 source in the list.

Anyway... I can currently get & set the merits and sort the parallel schedule tuner list by tuner priority. I'm just trying to decide how to handle merit editing.

Andy

[Monedeath]

I just envisioned a numeric entry field on the tuner setup page where the guide and whatnot is configured.

[Fuzzy]

I think the simplest would be on the Source Details screen, on the right hand side, a numeric entry for it.

More advanced, would be on the Source Wizard Summary screen, to the left of each entry have a numeric display with + and - buttons. This would require proper sorting to work (sort by merit, then by name), but when the encoder merit was changed for one of multiple inputs on a given device, it's going to end up changing the value for all of them. Just after each change, the list needs to be resorted, which is going to naturally keep the inputs on the same device grouped together.

[Monedeath]

And now, probably one of the most technically complex and difficult things to fix:

Detailed Setup -> Customize

[Opus4]

Originally Posted by Monedeath

And now, probably one of the most technically complex and difficult things to fix:

Detailed Setup -> Customize

What's the prolem?Is there somthing wron?

Andy

[Monedeath]

It's hard to try seleing just one thing.

[Opus4]

Yes, I know.. that's why I left out some more letters inn my reply. And the rest of that help sentence made little sense anyway. my latest keyboard keeps skipping letters and putting words in the places wrong. Appparently, it adds some letters & skips captilaization too.

Andy

[Monedeath]

Just so long as you don't try programming from a smartphone. They do a good enough jod of making salad of more normal expressions. (And a fair bit of my posting here is done that way, so I'll blame auto-correct)

[Opus4]

OK, that all works.

Now you can edit the merit value on the Source Details menu. I don't feel like taking the needed time to add fancy up/down editing on the Source Wizard Summary menu, since I don't expect merits to be something edited that often. But, they are displayed on the summary menu, so you can easily see if there is one you want to change. And, yes, the configured sources are sorted by priority/name/etc on the summary menu and the parallel schedule.

One thing though... I'm thinking something other than the term "merit" would be better & am open to suggestions.

Andy