1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

pyTivo - Transcoding server

Discussion in 'TiVo Home Media Features & TiVoToGo' started by armooo, Nov 25, 2006.

  1. lrhorer

    lrhorer New Member

    You've got to be kidding me. You *REALLY* prefer black on white to TiVoWebPlus' color scheme? De gustibus non est disputandum, I suppose.

    OK, I picked up the latest pyTivo tarball and installed it. I don't know very much about style sheets more than what they are and roughly speaking what they can do. I've played around with the variables defined by default in main.css, but I don't know how to change the text color for the folder links. I also would prefer the comments text to start to the right of the title text. That's a lot of wasted screen real estate on the title line. Also, is it possible for the comments text to have a different color than the title text? Finally, is it possible to insert a 1 pixel line between each program entry? This is much easier to read and less distracting than shading the background of each program field slightly differently. In short, as I said, I would prefer a layout and color scheme closer to the TiVoWebPlus NPL shown below. What .css parameters could I embed into the file to get a close as possible?

    Edit: I figured out the link colors.

    Link to TiVoWebPlus image
  2. wmcbrine

    wmcbrine Ziphead

    Aug 2, 2003
    Please size that pic down, or make it a link or something. It makes the whole page too wide.
  3. lrhorer

    lrhorer New Member

    It is sized down. It's only 1402 x 1187 pixels, which is less than 75% of the minimum screen resolution I employ. Nonetheless, I've made it a link.
  4. wmcbrine

    wmcbrine Ziphead

    Aug 2, 2003
    And yet, it's still almost 40% wider than the most common screen/browser window size.

    Thank you.

    Yes, really. By a lot. And I have issues with that screen shot beyond the color scheme.

    There are many places to learn about CSS, and if you want to make pyTivo look more like TWP (which also uses CSS), then that's what you should do.

    I assume you mean the description. You only perceive this as "wasted space" because of your very wide screen. Anyway, to change this, you'll have to take out a <br/> tag from plugins/video/content/container.xsl.

    Yes, certainly, those things are possible. I'm not planning to do them, but you're welcome to.

    I disagree. The alternating backgrounds help you keep track of your place in the list, which the grid doesn't do at all. (Of course you could have both.)
  5. jcthorne

    jcthorne Active Member

    Jan 28, 2002
    I also think the tivoweb screen shot is more difficult to read and runs off the end of the page. The icons are cute perhaps but otherwise the pytivo screen presents an easier to reference list with proper word wrap etc.

    Yes, black on white text is easier to read than white on black.
  6. lrhorer

    lrhorer New Member

    Such as? It is efficient and compact.

    Reading up on style sheets won't necessarily tell me what I need to know. Indeed, from what I have been able to determine, they're pretty trivial, but triviality of the form doesn't mean it will tell me what I need to know about the system in question.

    It's not a matter of perception. It is a matter of objective fact. With the TiVoWebPlus format, I get on average about 29+ programs listed per page. With the default pyTivo format, I get about 16. That's almost a factor of two. I also find it much more difficult to home in reliably on the titles. My brother complained rather forcefully of the same thing without any prompting from me when I showed him the screen yesterday.

    See my point about the style sheets above. Nowhere would learning about style sheets give me the info about which file to edit, which is what is required. The only problem I have with this is with further development of pyTivo, I'll have to re-edit the .xsl file if / when it ever changes. Copying over the old file is of course simple, but then I would lose any new functionality deriving from that file, or possibly even break something.

    Thank you, though.

    They're closer to being camouflage. It's even worse when the window is narrow. I found myself searching for the titles, rather than seeing them instantly. Ignoring the description is much easier if the description text is a different color. I'm not entirely certain what you mean by "keep track of your place in the list". I don't really need to keep track of my place in the list, per se. After all, for the most part all one wants to do is read the title and then go one to the next title. Finding that next title is much more difficult when the screen is both filled with additional lines and alternating colors. I find it takes me easily three times as long to scan the page for titles, and because my eyes have to jump around a lot, it even gives me a bit of a headache.
  7. lrhorer

    lrhorer New Member

    Nothing runs off the end of any page. Both utilities are HTML based, and the fields in question are simple text, and so both behave identically as far as formatting is concerned.

    Word wrapping is the same on both.

    If one is speaking of flat text, then this is true. We're not talking about flat text, though. We're talking about differentiated text. It's vastly easier to categorically visually ignore a particular information type if the text for the type is a different color. Since far more that 90&#37; of the text in this case is constituted by usually irrelevant* descriptions, making it easy to ignore is paramount. One could do this by making the text background different, but that would really be visually confusing. Barring this, it effectively means the background needs to be dark and the foreground light colors.

    * - I'm not saying having the description text available isn't handy or desirable. Indeed, it is essential. Having to drill into each listing of interest to see what it might be is dreadful. It's just that most of the time it isn't of interest, and needs to be easily ignored. When it is of interest, it needs to be there without user intervention.
  8. lrhorer

    lrhorer New Member

    But demonstrating some of my points calls for it to be closer to my screen sizes. I don't have any monitors capable of less than 1920 pixels horizontal resolution, and both of my TV displays are 1080i.
  9. reneg

    reneg Member

    Jun 19, 2002
    Given N number of people, there will be at least N+1 opinions on what makes a UI good.

    The source code is available so those that want to customize it can do so. Don't expect the primary caretaker of the code to accept your change requests based on your opinion. If you want to get changes worked back into the mainline codebase, make the effort and try to understand the underlying code. Propose constructively and try to work cooperatively.

    For instance, what is the minimum display resolution that should be required for a UI to operate efficiently? Remember that not everyone has a massive desktop work area. Is 1024x768 enough or does it have to be bigger?
  10. Rdian06

    Rdian06 New Member

    Apr 12, 2008
    lrhorer, we respect your opinion, but realize you are in the minority when it comes to browser display size. Here are the w3schools stats (based on people who visit their site):



    The stats show that the sweet spot is between 1024 and 1280 horizontal.

    My primary computer displays are 1920x1080 or 1920x1200. However, I rarely allow my web browser to take up the full screen. Normally, I've got one open to half the horizontal screen size.

    Some layouts lend themselves better to dealing with resizing, but creating these aren't easy and normally involve annoying trade-offs.

    We remind you again that pyTivo is free. If you want things your way and the devs don't feel it's a priority, then as reneg said, dig in and figure out how to do it. Or sponsor someone to do it.
  11. lrhorer

    lrhorer New Member

    That doesn't make much sense. Someone has to vote twice in order for it to be true. It's also an exaggeration in any case. There will tend to be groups of people who like certain things a certain way. Nevertheless, regardless of how many of these groups there may be, the more flexible - which is usually to say, "User configurable" an interface is, the better.

    Perhaps more fundamentally, however, an opinion is just that, an opinion, and often it is a personally based one. What's important (not only in this forum) is that people express those opinions and defend them - one would hope effectively. I have expressed my opinion and its related desires, along with the justification for same. 'Not that you or anyone else is required to express their opinions, and no offense intended, but I have to wonder why you decided to lecture me on the nature of opinions instead of posting your own opinion and defending it.

    Yes, and I already have. Based on William's input, I have edited the files to more closely approximate the desired target result. The main point is, unless some provisions are made in the primary code to make these changes a user configurable option, then every time I download a new version of the software, I will have to go back and modify the code once again. Code modifications grow cold on one, especially when one isn't the primary maintainer and doesn't modify the code but once every few months or so. Of course I can do so, and if I have to I will, keeping a small changelog on my system so I don't have to spend as much time searching for the files and the code segments which need to be changed.

    Oh, that's nonsense! All feature requests are nothing more or less than a request for a code change based upon the opinion of the user making the request. It's ultimately the developer's decision whether or not to honor that request, but nothing more than a desire on the part of the user is required to make a feature request reasonable.

    'And that's just ridiculous. In my case, I don't mind doing just that, but then I am an engineer. Expecting the average pyTivo user to undertake that sort of burden is patently absurd.

    I'm afraid I quite fail to see how I have done anything else. I have neither sought to insult or belittle anyone (certainly not William), nor have I made any unreasonable demands of anyone, nor have I refused to offer any additional information or undertake any specific tasks - not that anyone has asked.

    That's more or less an irrelevant question given the nature of HTML paragraph structure. Ideally, the code should work effectively with any display resolution. For it to work more poorly with greater resolutions is not the best solution, but the current solution also works more poorly with narrow screens. The fact placing the text on one line and the description on the other results in less of an impact on efficiency with narrower windows doesn't mean it is not impacted at all even with narrower windows. With narrow windows (depending on the actual length of the descriptions), the difference may be an average of, say, four lines per program entry instead of three. With a wider display, the average falls toward one line per program entry if the text is all placed as a single paragraph, whereas the absolute minimum for formatting it as two paragraphs is two lines. In the limit of descriptions shorter than the available line length after the title is displayed, it represents a factor of two to one.

    That's completely irrelevant. Putting all the text in a single paragraph, rather than two, results in greater efficiency even for the very narrowest windows. It's just the difference between one paragraph and two is not as great for a narrow screen as it is for a wide screen. What's more, the desktop work area doesn't necessarily limit the size of the window.

    Some applications, like calculators or terminal emulators, can't benefit from an expandable window. Such applications don't need to worry about the maximum window size, only the minimum window size. Some can even effectively employ a fixed window. This is not one such application. When I am using a Linux workstation, I may expand the window to 3000 pixels or more. Of course, being the goofy OS that it is, Windows doesn't allow this, but I avoid Windows as much as possible.
  12. reneg

    reneg Member

    Jun 19, 2002
    lrhorer, you win.
  13. lrhorer

    lrhorer New Member

    Well, first of all, not all that much. By the stats you posted, more than 22&#37; of users have screen resolutions of 1440 pixels or greater. That's a very significant minority. More to the point, however, we're not talking about a request which works better at high resolutions and poorly at low resolutions. We are talking about a request that works significantly better at low resolutions and much better at high resolutions. That means everyone benefits by my suggestion, not just the 20+% who have large windows.

    You may want to argue that my criteria for "better" are different than yours or the average users, but as of yet I haven't seen anyone else offer a competing criteria for "better". My suggestion puts up as much as twice the amount of information on the screen as the default with no negative impact to read-ability, and by my criteria a considerable positive impact to same. (The coloration is a different issue.)

    Why anyone would do that is beyond me. At best, you're just wasting a good chunk of the money you spent on the monitor while simultaneously limiting the amount of information available to you without intervention. You are free, however, to handle your apps any way you like. I am only asking for the same privilege, or are only people who work like you do to be considered? In this specific instance, however, I am asking for something which would benefit YOU as well. 'Not as much as it benefits, me, perhaps, but really, what's the down side to making this work for everyone?

    This is one which most readily does so. Other than changing the style sheet in plugins/video/content, all I had to do was remove one line in the code and make tiny changes to two others. Making it user configurable will only require a few additional lines of code.

    As I mentioned, I already did so. It took less time than posting in this forum, and most of that was due to my unfamiliarity with style sheets and my very modest capability with HTML. The point is, it won't stick unless the main code is changed.

    I have no problem with donating a few dollars, although funds are tight for me right now. That said, it is not appropriate that non-configurable changes be made on my behalf just because I have more money than someone else. Making them configurable, or making them because a very large majority of users feel them to be useful, is appropriate, IMO. Either way, the donation is appropriate, but I don't want William to go about making unpopular absolute changes just because I fork over some cash.
  14. lrhorer

    lrhorer New Member

    I hope not because you feel dispirited about continuing a debate, but because I have convinced you of the merit of my position. It's your absolute right to bow out for whatever reason, of course, and your motivation for doing should not be criticized by me or anyone else.
  15. wmcbrine

    wmcbrine Ziphead

    Aug 2, 2003
    Frankly, I think it's hideous. Very busy, and poorly laid out.

    If there's a visual model for the Push and ToGo screens, it's the TiVo's built-in web server, not TiVoWebPlus.

    No sir. "Wasted" is a subjective judgment. Some people actually value well-placed white space over maximum information density.

    The titles are in boldface, and in a larger font than the description. They should stand out dramatically. Are you really not seeing this? Maybe I need a pyTivo screen shot from your system as well...
  16. Rdian06

    Rdian06 New Member

    Apr 12, 2008
    Some of us prefer NOT to be overloaded with that much information on one page. Your opinion of read-ability does not match mine. Nor does it appear to match the others who have commented.

    First of all, I multi-task so my web browser is NOT the only window I have open at a given time. Sometimes I have two browser windows open so I can cross reference data. Other times I have other apps open filling the rest of the space. Not to mention that most of the sites I visit purposely choose to eat up the extra space with empty borders on the left and right - maintaining the proportions of the center area where the text is. If a line goes on too long before wrapping, I find it fatiguing to read because my eyes lose their place when they finally reach the end of the line and have to find the beginning of the next. Maybe it's a consequence of all the portrait oriented text I've been accustomed to in my life, but that's how I'm wired now. And I suspect many would agree with me wrt line length.

    "what's the down side to making this work for everyone?" Opportunity cost. Developer resources are finite and are prioritized how the developer sees fit for an open source project. Even small changes have consequences. Either someone will come to depend on the functionality and complain if it later gets broken, or it could constrain other uses or evolution of that code that you may not be thinking about. I'm not saying your changes will have these consequences, but I'm just saying there may be other factors you're not considering that the dev has.

    I'm happy you figured out how to make the changes you wanted yourself. Now if you are inclined to make it configurable, you can either ask wmcbrine to include it or you can post it to the pyTivo forum under Hacks. Personally, I don't need or want this so I could care less.

    I never said that you could pay to have the changes foisted onto the majority. What I was trying to express was that if you didn't have the expertise or the time to do it yourself, you could sponsor someone to do it for your use. If those sponsored changes were or weren't accepted by the pyTivo developers, then that is a different issue.

    Now I'm done procrastinating what I'm supposed to be doing, so I'll shut up and let this die.
  17. wmcbrine

    wmcbrine Ziphead

    Aug 2, 2003
    I've done a little bit more with moving style elements into CSS, and I think lrhorer should be able to do everything he wants via content/main.css now (although I haven't tried to replicate his preferences). These were changes I needed to make anyway (well, I probably wouldn't have done the one that will let him move up the description, but I'm fine with it); I've been working towards themability for a while, but it wasn't quite ready yet. It's still not, really, but whatever.

    The changes are only on my netbook right now, and will be uploaded to my repo later tonight.
  18. lrhorer

    lrhorer New Member

    Well, I disagree. That said, it's a personal preference.

    That's horrible in the extreme to my eye. So, for that matter is TiVo Desktop, yet there are plenty of people out there who - quite inexplicably to me - prefer it to pyTivo.

    All judgments are to one extent or other subjective. What is not subjective at all is that scanning from the beginning to the end of the NPL can take twice as many keystrokes and considerably more time at 16 programs per page than at 29, even if everything else were equal. When 3 to 6 people (occasionally more) are reading the list, top to bottom, trying to decide what to watch tonight, the difference is significant.

    Let me ask this: Do you actually read, in the ordinary sense, the page? I do not. All my family and I do is scan quickly the titles, pausing only to read (independently) a synopsis here or there. When 3 to 6 people are reading the list, it is important the screen hold as much information as possible, or else it quickly becomes quite tedious. With the TiVo NPL, it's often difficult to get beyond the "F"s before people start to get frustrated. Using the default pyTivo list, it's difficult to get beyond the "C"s before people begin to fidget. Last night, using the default pyTivo scheme, we couldn't make it beyond the "B"s. With the TWP screen, at least we can usually get to the "J"s or the "K"s before the sighing and moaning starts. If I stretch the window beyond the screen borders, we get even further, although then, of course, reading any description becomes much more tedious, so it's not the best trade-off imaginable.

    In the best of worlds, wouldn't it be that both camps can choose according to their desires?

    They are.

    Not so much, especially when there are many lines of description text and doubly so if one is not sitting directly in front of the TV, especially when they are projection sets, which mine are.

    I see there is a difference between the two texts, yes, of course. Merely being a different font does not, however, make it easier to accurately jump from one title to the next in a fraction of a second, all the way down the screen. I have to search to find the next title. Yes, it only takes a half second or so, but do it 4000 times, and it adds up in a hurry. If almost all the programs only take up one line and the titles are by and large the only thing on the left side of the screen, it just makes it much easier on the eyes and the brain. When there is only very occasionally any text or variable space vertically between the sets of titles, it's easier still.

    It's very hard to discern emotional context in a forum like this, so at this point I want to emphasize that I am not saying your choices for your application are in any sense "wrong". For your purposes, they may suit the application better than my requested options. What's more, as the developer, it's entirely your right to decide for or against any options you wish. It's also not as if I cannot edit the style sheets to better suit my own purposes every time I download a new version, or that I won't do so. If I have to, I most certainly will. Nor will it lessen my opinion of you as a developer, a forum participant, or a human being if you decide unilaterally against any support whatsoever for my request.

    OK. Of course, it's variable depending on what window size and text magnification I choose (the living room screen is both much smaller and further away from the viewers than the screen in the theater). Note also the degree of difficulty in distinguishing the two fonts varies with the text magnification. It's much more difficult in the living room than in the theater.

    Here is a sample of the default config.

    Here is a sample of the config I created this morning.

    Both of these are at font magnifications I might use in the livingroom.

    Here is an example of a text magnification I might use in the theater. Note it is much easier to differentiate the two fonts - even given the different colors, but the description text would be too small for many people to comfortably read in the living room.

    Note with the default scheme at the same magnifaction shown here, it's much easier than with the very first image above, but still more difficult than with the image just previous.
  19. wmcbrine

    wmcbrine Ziphead

    Aug 2, 2003
    You're displaying it on a TV, and going over it with your family? That's strange to me. Why not just view it from the TiVo, then?

    The web interface is not designed with TV viewing in mind, no.
  20. PaulS

    PaulS New Member

    Sep 16, 2002
    Southern NH

    Geez, man, give it a break. :confused:

    It's quite apparent that you're the only one who wants this change.
    If you feel like making the change to your local setup, feel free.
    That's what open source is all about.

    However, continually harping about this change with your multi-thousand word dissertations isn't doing anything but polluting this thread. Can you please take it off-line ?

Share This Page