STV UI Feedback 9.0.0.x

[Monedeath]

For Opus.

Went a step further than just updating the sage.jar in my last update to the server. replaced the STV folder as well with the updated files from Opus.

One minor complaint, as a user of the SageTV EPG data, which means I don't get pictures of cast members. It creates a lot of white space in the detail view(presumably, for pictures), hopefully there is a means to not generate that whitespace when no picture is available.

And I guess while I have this open I'll throw this long standing question/minor complaint/feature request into the mix:

When in the Parallel Recording view, is there in any particular rationale behind the order in which the various tuners are displayed or is that determined by something else?
Even on a HDTV set, once you start dealing in more than 8 tuners, it starts getting mildly annoying when Tuner 0 on Device 1 is in Column 1, while tuner 1 on Device 1 is off in column 10 and cannot be seen on the same screen(and have intelligible information displayed). Some way to group/sort the columns by device or merit would be awesome.

[dvd_maniac]

There is a plug-in called "Encoder Names" that allow you to name them. Perhaps that will help with all the tuners you have?

[Monedeath]

Originally Posted by dvd_maniac

There is a plug-in called "Encoder Names" that allow you to name them. Perhaps that will help with all the tuners you have?

That helps keep track of them, but does nothing for where they end up in that view.

Looking through the api, I'm not seeing any way to poll for tuner merit (or otherwise change it aside from editing the sage.properties file) so it looks to a bit more than a simple UI tweak. Even device ID paired with tuner id looks to be a bit dodgy to obtain, although that one might be possible under the current api if you jump through the right hoops.

[Opus4]

Originally Posted by Monedeath

One minor complaint, as a user of the SageTV EPG data, which means I don't get pictures of cast members. It creates a lot of white space in the detail view(presumably, for pictures), hopefully there is a means to not generate that whitespace when no picture is available.

I updated it to not leave that vertical space now.

When in the Parallel Recording view, is there in any particular rationale behind the order in which the various tuners are displayed or is that determined by something else?
Even on a HDTV set, once you start dealing in more than 8 tuners, it starts getting mildly annoying when Tuner 0 on Device 1 is in Column 1, while tuner 1 on Device 1 is off in column 10 and cannot be seen on the same screen(and have intelligible information displayed). Some way to group/sort the columns by device or merit would be awesome.

The tuner names are sorted alphabetically now. I have no idea why that wasn't done before...

Andy

[Monedeath]

That was fast. Will check it out in the morning. Thank you.

[Fuzzy]

Originally Posted by Opus4

The tuner names are sorted alphabetically now. I have no idea why that wasn't done before...

Andy

Alphabetical is good, though I think sorting by Merit might be better, at least as an option.

[Monedeath]

Originally Posted by Opus4

I updated it to not leave that vertical space now.

The tuner names are sorted alphabetically now. I have no idea why that wasn't done before...

Andy

Originally Posted by Fuzzy

Alphabetical is good, though I think sorting by Merit might be better, at least as an option.

Alphabetical could be quickly implemented, it appears at first glance that it took ~4 lines of code in one file for the two changes that are already implemented.

Tuner Merit is going to be a much more involved change, I'd suspect that it won't be a simple addition of comparable difficulty. Probably be doing good to end up with only 4 altered files before all is said and done.

[Fuzzy]

It actually may not be that tough. It is already being sorted by SortLexical, just with no sortby parameter, which means it sorts the input objects by their string conversion, in the case of capture devices, the name. However, SortLexical can sort the objects by calling a method on the object, and sorting by the results. So, the line for sorting them is currently this:

EncoderList = SortLexical( EncoderList, false, null )

which converts each object to a string, and sorts alphabetically, ascending. If it was changed to this:

EncoderList = SortLexical( EncoderList, true, "getMerit" )

, it would call getMerit on each Capture Device in EncoderList, and then sort the list by the merit values, descending.

I'm writing this from work, so I haven't tested it, but as far as I understand, it should function as I describe.

[Opus4]

I already thought of encoder merit last night & I too thought it might be a great option.

But all I have in the STV is a list of the capture device names, not a list of java CaptureDevice objects. So sorting alphabetically is the quick and easy solution.

Andy

[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.

The SageTV PC Client only has a single listing, so I'm very comfortable in saying the default STVi isn't doing it. Very happy with the encoder list being sorted.

[Monedeath]

Originally Posted by Fuzzy

It actually may not be that tough. It is already being sorted by SortLexical, just with no sortby parameter, which means it sorts the input objects by their string conversion, in the case of capture devices, the name. However, SortLexical can sort the objects by calling a method on the object, and sorting by the results.

But first you need to get that information to where the STV user interface can make use of it.

Also, once you do have that information available, it introduces the possibility of introducing a further UI change: Choosing how you want the tuners to be sorted. Unless you decide to give the user no choice in the matter, which after all, would be status-quo for that ui element.

A tertiary item on the list also happens to be that if encoder merit is going to be exposed enough to be used to sort them in a recording view, it probably wouldn't be too much more trouble to add it as an advanced tuner setup option from within the STV UI itself at that point.

[Fuzzy]

Originally Posted by Opus4

I already thought of encoder merit last night & I too thought it might be a great option.

But all I have in the STV is a list of the capture device names, not a list of java CaptureDevice objects. So sorting alphabetically is the quick and easy solution.

Andy

Y'know, I've been digging though the java code so much in the last month or so, that I've forgotten about the STV's limits. I had seen the GetActiveCaptureDevices call in the STV and just made the assumption that it was returning an array of CaptureDevice objects. So what we need is a new API call that either returns an array of CaptureDevice objects [GetActiveCaptureDeviceObjects()], or a function that returns the merit of a capture device when given the name of that capture device [GetCaptureDeviceMerit(String CaptureDeviceName)]. both seem clunky, and I wish the API would simply return objects when it has actual objects to return. If all you want is the string from those objects, just use [object].toString (which in this case, would return the name).

[Opus4]

I would vote to at least add get/set merit calls. Being able to set merits in the UI was something I wanted/tried to do long ago, but at the time I had to edit the property value and that was only read at start-up and probably wasn't saved at shutdown. (In fact, there is still hidden code in the STV from when I looked into it.)

The schedule would sort by merit & alphabetically; no further option really needed. If someone didn't adjust merits, the sort would be simple alphabetical. If merits have been edited, it would end up ordering them by merit & by alpha when merits are equal (and thus by alpha when all merits are equal).

Andy

[wayner]

It would be nice if encoder merit could be changed in settings in a more intuitive fashion - like being able to move an encoder up, just like you change priority of Favorites. Is this doable?

It would be great if more of the sage.properties parameters could be changed in the UI or via a web UI and not require a service restart.

[BobPhoenix]

Personally I would like to see the tuners as rows and the times as columns in the parallel schedule. The show text reads better that way.

[Tiki]

I know this is probably asking too much, but I would really like to see the axes swapped on the grid for this view. So, the tuner names would be on the vertical axis and the time slots would be along the horizontal axis (like they are in the EPG grid).

My reason for this is that tuner names can be fairly long and if you have a lot of tuners, it has to really squeeze the column widths down to fit them all (and then you can't read the tuner names). If you listed the tuners vertically, the name column could be a little wider and still have everything be legible.

[Monedeath]

Originally Posted by wayner

It would be nice if encoder merit could be changed in settings in a more intuitive fashion - like being able to move an encoder up, just like you change priority of Favorites. Is this doable?

It would be great if more of the sage.properties parameters could be changed in the UI or via a web UI and not require a service restart.

I would say yes, but you're then looking at some follow on effects. Currently more than one tuner(not to be confused with device) can share a merit ranking. Going with a favorites type approach creates a graphical issue on presentation of equally ranked tuners. In the case of favorites it is a simple ranking so it presents easily for that use.

Now you could make the tuners behave that way, and nothing prevents you from doing so currently. But when it comes to scheduled recordings and viewing of live TV for example, you will likely be back to Sage wanting to use the same tuner you are using to watch live TV on, even though other tuners could record that program Sage will try to avoid them because of their lower merit. Of course I could be misunderstanding the logic put in place to handle the live TV scenario, as that discussion was in the context of similar tuner merit.

Which isn't to mention that for me personally it doesn't make much sense why on my Ceton tuner, that tuner 1 on my M-Card decoder would have to be given a different merit than tuner 5 on the same physical piece of hardware for example.

[Monedeath]

Originally Posted by Tiki

I know this is probably asking too much, but I would really like to see the axes swapped on the grid for this view. So, the tuner names would be on the vertical axis and the time slots would be along the horizontal axis (like they are in the EPG grid).

My reason for this is that tuner names can be fairly long and if you have a lot of tuners, it has to really squeeze the column widths down to fit them all (and then you can't read the tuner names). If you listed the tuners vertically, the name column could be a little wider and still have everything be legible.

Now let's not get crazy here. J/K

Good suggestion.

It should be noted that there is a plugin that lets you name individual tuners. Sadly while those aliased names do still present in the latest STVi. The STVi sorts by the default tuner name, but that is a plug-in issue, not a stock UI concern.

[Fuzzy]

Originally Posted by Monedeath

I would say yes, but you're then looking at some follow on effects. Currently more than one tuner(not to be confused with device) can share a merit ranking. Going with a favorites type approach creates a graphical issue on presentation of equally ranked tuners. In the case of favorites it is a simple ranking so it presents easily for that use.

Now you could make the tuners behave that way, and nothing prevents you from doing so currently. But when it comes to scheduled recordings and viewing of live TV for example, you will likely be back to Sage wanting to use the same tuner you are using to watch live TV on, even though other tuners could record that program Sage will try to avoid them because of their lower merit. Of course I could be misunderstanding the logic put in place to handle the live TV scenario, as that discussion was in the context of similar tuner merit.

Which isn't to mention that for me personally it doesn't make much sense why on my Ceton tuner, that tuner 1 on my M-Card decoder would have to be given a different merit than tuner 5 on the same physical piece of hardware for example.

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.

So what needs to be done, Andy? I'm guessing a setMerit call needs to be added to CaptureDevice.java, and have that 'dirty' the prefs and write them out to the properties, as well as kick off the scheduler? then API calls added to be able to handle this from the STV? Then of course, edit the Capture Device screen to enable up and down movement of them similar to the favorites manager?

[BobPhoenix]

Originally Posted by Tiki

I know this is probably asking too much, but I would really like to see the axes swapped on the grid for this view. So, the tuner names would be on the vertical axis and the time slots would be along the horizontal axis (like they are in the EPG grid).

My reason for this is that tuner names can be fairly long and if you have a lot of tuners, it has to really squeeze the column widths down to fit them all (and then you can't read the tuner names). If you listed the tuners vertically, the name column could be a little wider and still have everything be legible.

What I was saying just not as well done.